MCP email server: give your AI agent email as a tool

An MCP email server is a Model Context Protocol server that exposes email as native tools an AI agent can discover and call: create an inbox, send a message, read a thread, reply in place. Instead of hand-writing a wrapper around an email API and re-teaching every agent how to use it, you point an MCP-compatible client at one URL, authenticate with a key, and the agent gets email as first-class capabilities in its tool list. AgenticEmail runs a hosted MCP email server at https://api.agenticemail.dev/mcp over streamable-http, so any agent that speaks MCP can own and operate a real inbox without you shipping a line of email glue code.

What is MCP, in one paragraph

The Model Context Protocol is an open standard for connecting AI models to external tools and data. A model client (Claude Desktop, Cursor, an agent you built on the Claude Agent SDK or the Vercel AI SDK) speaks to one or more MCP servers, and each server advertises a set of tools with typed inputs. The client fetches that list, hands it to the model, and when the model decides to call a tool the client routes the call to the server and feeds the result back into the loop. The point is discovery and reuse: you implement a capability once as an MCP server, and every MCP-compatible agent can use it without bespoke integration code. Email is a natural fit, because "send" and "read" are exactly the kind of self-contained actions the protocol was built to expose.

What an MCP email server is, and why it beats hand-writing email tools

You can always give an agent email the hard way: wrap an email API in a tool() definition, write the input schemas, handle auth, and repeat that for every agent and every framework you run. It works, but you own all of it. Every stack has its own tool format, so the same send-and-read logic gets rewritten for the Vercel AI SDK, then again for a custom loop, then again for the next thing.

An MCP email server collapses that to one integration. The server defines the tools once, with their schemas and descriptions, and any MCP client consumes them the same way. Swap frameworks and the email tools come along unchanged. Add a second agent and it inherits the same capabilities by pointing at the same URL. The agent discovers create_inbox and send_message at runtime and reads their descriptions to decide when to call them, so you are not maintaining a translation layer between each model framework and your email API. You maintain nothing; the hosted server is the integration. For the bigger picture on why an agent wants email at all, see why AI agents need email and what an AI email agent is.

Connect AgenticEmail's hosted MCP email server

Point your MCP client at the server URL and authenticate with an AgenticEmail API key as a Bearer token. The transport is streamable-http, so there is no local process to run and no proxy to install; it is a remote server your client talks to directly.

{
  "mcpServers": {
    "agenticemail": {
      "url": "https://api.agenticemail.dev/mcp",
      "headers": {
        "Authorization": "Bearer ${AGENTICEMAIL_API_KEY}"
      }
    }
  }
}

That block is the standard remote-MCP shape that Claude Desktop, Cursor, and other clients read from their MCP config file. Use a scoped key and the agent only ever sees the inboxes you grant it, which is the safe default when a model is the one calling the tools. If you are wiring the server into a programmatic agent rather than a desktop client, the Claude Agent SDK and the Anthropic Messages API MCP connector take the same URL as a remote server with the API key passed as the authorization token, and the Vercel AI SDK's MCP client connects to it the same way.

The tools it exposes

Once connected, the agent can call these directly. They map one-to-one onto the REST API, so anything the agent does over MCP you can also do over HTTP, the SDKs, or the CLI.

• create_inbox - provision a new addressable inbox at runtime.
• list_inboxes - list the inboxes the key is allowed to access.
• list_threads - browse conversations in an inbox.
• get_thread - load the full history of one thread.
• list_messages - list parsed inbound and outbound messages.
• get_message - read a single parsed message.
• send_message - send a new message from an inbox.
• reply_to_message - reply within an existing thread, keeping the headers threaded.

The split between send_message and reply_to_message matters for agents: replying in-thread keeps In-Reply-To and References correct so the conversation stays coherent for whoever, or whatever, is on the other end.

Which clients support it

Any MCP-compatible client works, because the server implements the protocol, not a vendor-specific API. In practice that covers the clients agent developers actually reach for:

• Claude Desktop and Claude Code, via the mcpServers config above.
• The Claude Agent SDK and the Anthropic API MCP connector, for agents you run as code.
• The Vercel AI SDK, whose MCP client pulls the tools into generateText or streamText alongside your other tools. The Vercel AI SDK agent email guide shows both the MCP path and the hand-wrapped one.
• Cursor, which reads the same remote-server config for in-editor agents.
• Custom MCP agents built on the reference clients in any language.

An end-to-end example: create an inbox, then reply

Here is the shape of a single agent turn once the server is connected. The model is asked to stand up a support address and answer whatever lands in it. It discovers the tools, provisions an inbox, and later replies in-thread, all as ordinary tool calls.

User: Create a support inbox for the beta, then reply to the first
      message that arrives with our onboarding checklist.

Agent -> create_inbox { "username": "beta-support" }
       <- { "id": "inb_9f2", "address": "beta-support@inbox.agenticemail.dev" }

... a beta user emails beta-support@inbox.agenticemail.dev ...

Agent -> list_messages { "inboxId": "inb_9f2", "limit": 1 }
       <- [ { "id": "msg_4a1", "threadId": "thr_77",
              "from": "user@example.com", "subject": "Getting started?" } ]

Agent -> reply_to_message {
           "messageId": "msg_4a1",
           "text": "Welcome! Here is your onboarding checklist: ..."
         }
       <- { "id": "msg_4a2", "status": "sent" }

No orchestration code decides that sequence. You expose the capability and the model chooses create_inbox, then reply_to_message, from its tool list. For reacting the instant mail arrives instead of polling list_messages, register a webhook or hold the WebSocket stream, both covered in the docs. The same flow driven by a Claude-based agent is walked through in the Claude agent email inbox guide.

A note on end-to-end encryption for agent-to-agent mail

When two of your own agents talk over email, the bodies can carry customer records, tokens, or raw tool output. AgenticEmail offers opt-in, agent-to-agent end-to-end encryption: it is zero-knowledge, the private key lives in your agent's runtime, and the platform only ever stores ciphertext. It is opt-in and applies between two AgenticEmail inboxes that have each published a key, not to inbound mail from the outside world. The encryption path lives in the SDKs and CLI, and an MCP agent can drive it through the same tools while keys stay client-side. The full model is in encrypted email for AI agents.

Ship it

The whole appeal of an MCP email server is that there is almost nothing to build. Drop the config block into your MCP client, use a scoped Bearer key, and your agent has create_inbox, send_message, reply_to_message, and the rest as native tools it can discover and call. When you outgrow polling, add a webhook or the WebSocket stream. The tool reference, the REST endpoints they map to, and the SDK and CLI details are all in the docs.