The MailKite MCP server and the agents platform

[bucabay]

Email is the one identity every system on the internet already accepts — sign-ups, verification links, 2FA codes, replies from real people. Agents mostly can't touch it, because "give the agent an inbox" has historically meant OAuth against someone's personal mailbox, or running a mail server.

MailKite does both directions of this, and the MCP server is how your agent reaches them.

Give your agent an inbox

Every agent gets a real, catch-all address on a domain you control. It receives mail sent to any address on that domain and sends from any of them.

Claude Code — two commands, no API key to copy:

/plugin marketplace add mailkite/claude-code
/plugin install mailkite@mailkite

Then /mcp → mailkite signs you in over OAuth.

Any other MCP client (Cursor, Claude Desktop, Cline, Roo, Zed) — point at the hosted server:

{
  "mcpServers": {
    "mailkite": {
      "type": "http",
      "url": "https://mcp.mailkite.dev/mcp"
    }
  }
}

A chat agent with no config file? Paste this into the prompt:

Connect to the MailKite MCP server (Streamable HTTP) at https://mcp.mailkite.dev/mcp and authenticate in the browser when prompted. Then use the mailkite_* tools to send, read inbound, and reply to email.

Prefer to run it locally: @mailkite/mcp. Prefer no MCP at all: the SDKs and REST do everything the tools do.

What the agent actually gets

Not just send. The full loop is exposed as tools:

• Send — mailkite_send (HTML, text, cc/bcc, attachments, in-thread replies via inReplyTo), mailkite_upload_attachment for files too big to base64-inline
• Read — mailkite_list_messages, mailkite_get_message (body, headers, deliveries, attachment links), mailkite_retry_delivery
• Domains — list, create, get, verify, delete, plus mailkite_check_domain_availability and mailkite_register_domain, so an agent can stand up its own domain end to end
• Webhooks — set, delete, test, and mailkite_verify_webhook, which checks an x-mailkite-signature locally with no API call
• Routes — list, create, delete. A route's action is webhook, forward, store, drop, or agent

Inbound is the part most email MCPs don't expose. Ours does.

The other direction: inbox agents

The above gives your agent an email identity. The inverse is MailKite acting on the mail that arrives — and the two compose.

There's no separate object to manage. An inbox agent is a route whose action is agent, carrying the agentPrompt that programs it:

answer billing questions, reply in-thread, and escalate refunds to refunds@myapp.ai

Mail hits support@myapp.ai, MailKite runs the agent with your prompt and the parsed message, it reasons, calls tools, and replies in-thread from the receiving address. The run happens in the background, so inbound stays fast. No server, no loop to host.

You can also bring your own agent — inbound webhook → your model → the Send API to reply in-thread. Both are first-class; pick per address.

The part we care most about

The sender of an inbound email is untrusted. Anyone can email your address. So an inbox agent is deliberately locked down to exactly two actions:

1. Reply to the person who wrote in — in-thread, from the address that received the mail. It chooses the words; it cannot change who the reply goes to, or send from another domain.
2. Forward to an address you control — your account email, an address on a domain you own, or one you pre-approve on the route via agentForwardTo. Any other destination is refused.

That's the whole surface. An inbox agent cannot read your other messages, cannot list or change your domains, routes, or webhooks, and cannot send to an arbitrary address — those tools are simply not given to it.

On top of that: the email body is treated as untrusted input — instructions inside it are data, not commands. The agent won't reply to no-reply or automated senders, and it acts at most once per message.

Your MCP server and dashboard assistant can do all the account-level things, because they're authenticated as you — not driven by an inbound stranger. That distinction is the design.

Scope what your own agent controls

Three grants, each revocable on its own: an account key, a domain-scoped key, or a single agent route. You decide how much email an agent can reach.

Cost

Inbox agents run on Claude. Bring your own Anthropic key and the AI is free — we never bill it. Or use our platform at a flat $0.10 per action, no bundles, no tiers.

Domains and addresses are unlimited and free until volume, so a fleet of agents can each have their own inbox without a per-domain tax.

Docs

• Agent inboxes & MCP
• Inbox agents
• MailKite for AI agents
• Skills for coding agents — npx skills add mailkite/agent-skills

Tell us what breaks

This is the surface we most want pushed on. If a tool does something surprising, or the guardrails get in the way of something legitimate, we want to hear it:

• Something broken → Bug reports
• Something missing → Feature requests
• Built something with it → Show and tell, genuinely

One exception: if you find a way to make an inbox agent do something outside those two actions, please don't post it here. Send it privately through contact and we'll get on it.