What Is MCP (Model Context Protocol) for Email?
The short answer
MCP (Model Context Protocol) is an open standard that lets an AI assistant call external tools over JSON-RPC. An email MCP server exposes mailbox operations — search, read, label, draft, send — as tools the assistant can discover and call. The server holds the mailbox credentials; the assistant decides what to call, which is why an approval gate matters.
What is MCP for email? The Model Context Protocol explained: what an email MCP server exposes, who holds your credentials, and where the approval gate sits.
On this page
MCP — the Model Context Protocol — is an open standard for connecting AI assistants to outside tools and data. A server exposes capabilities; any MCP-compatible client can discover and call them over JSON-RPC. An email MCP server applies that to a mailbox: search, read, label, draft and send become tools an assistant can call.
Anthropic published MCP in late 2024 and released it as an open specification. By mid-2026 it is the common integration layer across Claude, ChatGPT connectors, Google's agent stack and most coding editors — which means one server, written once, works in every client that speaks the protocol.
Most of what is written about MCP and email is either a GitHub README or a launch announcement. This page is the neutral version: how the protocol works, what a mail server actually exposes, who ends up holding your credentials, and where the decision to send lives. The last question is the one that matters, and it is not answered by the protocol.
How does an email MCP server work?#
Three roles matter. The host is the application you use — Claude, ChatGPT, an editor. The client is the connector inside that host, one per server. The server is the thing that exposes capabilities. Every message between client and server is JSON-RPC 2.0, so the wire format is boring and inspectable.
The session opens with capability negotiation: client and server each declare what they support, then agree on a protocol version. After that the client asks what the server can do, and the model decides what to call.
- 1
Connect and authorize
The client points at a server — a local process over stdio, or a remote HTTP endpoint. Remote servers typically authorize with OAuth, so you approve a scoped grant in a browser rather than pasting a password into a chat window.
- 2
Discover the tools
The client sends tools/list and receives every tool the token is allowed to see: a name, a description, and a JSON schema for its arguments. This is the part a hand-built integration never had — the assistant learns the API at runtime instead of being programmed against it.
- 3
The model chooses a call
You say something like "find the contract Marta sent and reply confirming the price." The model maps that to a sequence of tool calls and emits the arguments. Nothing about this step is deterministic — it is a model making a judgment about which tool fits.
- 4
The server executes and returns
The server runs the operation against the real mailbox and returns a result the model reads. Whether a given call needs your explicit sign-off is decided by the server and the host, not by MCP.
What does an email MCP server expose?#
The specification defines three server primitives, and the difference between them is who is in control. Tools are model-controlled: the assistant decides to call them. Resources are application-controlled data the host can pull in as context. Prompts are user-controlled templates you invoke deliberately, usually from a slash-command menu.
In practice, mail servers are almost entirely tools. Expect these families:
- Read — list threads, open a conversation, extract attachment text, list connected mailboxes.
- Search — keyword, semantic or hybrid retrieval across accounts, returning thread ids to fetch.
- Organize — archive, label, snooze, mark read or unread. Reversible, low-stakes state changes.
- Draft and send — create a draft, edit it, and (separately) send it. The two halves have very different risk profiles.
- Context — contacts, calendar, whatever memory the product keeps about clients and preferences.
Note what is missing from that list: the mailbox credentials themselves. In a well-built server, the Gmail or Microsoft OAuth token never leaves the server. The assistant carries a token scoped to the MCP server, and the server holds the mail credential — so revoking the assistant's access does not touch your mailbox connection, and a leaked client token cannot be replayed against Gmail directly.
MCP server vs a traditional API integration#
An email API and an email MCP server can sit on the same backend and still behave nothing alike, because the thing that initiates a call is different. In an API integration, your code decides. In MCP, a language model decides, at runtime, from an instruction written in English.
That single change is the source of both the convenience and the risk.
| MCP server | Traditional API integration | |
|---|---|---|
| Who initiates a call | The model, at runtime, from a natural-language goal | Your code, at a point you wrote in advance |
| Discoverability | Client calls tools/list and gets names, descriptions and JSON schemas | A developer reads the docs and hand-writes each request |
| Credentials | Server holds or brokers the mailbox credential; the client carries a scoped token | Your application stores the key or token and calls the provider directly |
| Approval model | Defined by the server and the host — the protocol only carries the request | Whatever your code does; approval is not a concept the API has |
| Reuse | One server works in every MCP-capable client | One integration per application you build |
| Typical failure | The model calls a plausible wrong tool with plausible arguments | A bug you can reproduce and fix deterministically |
Why email is the riskiest thing to connect#
Email is not a private database. It is a channel through which strangers send you text, and that text ends up inside the model's context window the moment an assistant reads a thread. Someone can write an email whose body is aimed at your assistant rather than at you — instructions to forward a thread, to look up a credential, to reply to an address you have never seen. This is indirect prompt injection, and email is its most natural delivery mechanism because anyone can write to you.
So read access and send access are not two points on one scale. They are different categories of risk. A read tool leaks; the damage is bounded by what is in the mailbox. A send tool acts in your name, to recipients of the model's choosing, and cannot be un-received. A server that ships both behind one grant has quietly given a stranger's text a path to your outbox.
The mitigations are unglamorous and they work. Fence email content so the model is told, in the payload, that everything inside is data and never instructions. Keep an action allowlist — a small set of tools, no shell, no arbitrary HTTP.
Require an explicit confirmation for any send, and make it a separate call so "draft" can never silently become "sent". Log every action with an undo path. We go deeper on the threat model in /docs/untrusted-input.
Read access and send access deserve separate decisions
What MCP does not do#
MCP is a transport and a discovery mechanism. It standardizes how tools are described and invoked. Almost every safety property people attribute to it lives somewhere else, and being clear about that is the difference between an informed decision and a vibe.
- It is not authentication. The specification includes an authorization framework for HTTP transports, but whether your token is scoped, expiring and revocable is the server's implementation, not a guarantee of the protocol.
- It is not a permission system. Scopes, per-tool gating and consent screens are things a server builds. MCP will happily carry a request to delete everything.
- It is not a guarantee the assistant behaves. Tool descriptions are advisory text a model may ignore, misread, or be talked out of by content it just read.
- It is not encryption of your mailbox. It says nothing about how mail is stored, who can read it, or whether it reaches a model provider that retains it.
- It is not a product. A server exposing raw mailbox verbs with no approval gate is protocol-compliant and still a bad idea.
How MCP works in AI Emaily#
AI Emaily runs a remote MCP server at mcp.aiemaily.com over streamable HTTP. You connect it as a custom connector in Claude, ChatGPT developer mode, the Gemini CLI, or an editor like Cursor; clients that only support local servers use a thin npx bridge that proxies to the same endpoint. Authorization is OAuth 2.1 with PKCE, or an API key for headless use.
Consent is per-scope and written in product language rather than scope strings — "Read your inbox", "Send email — every send requires explicit confirmation". Tools your token lacks the scope for are not merely blocked; they are hidden from the tool list, so the model never sees an affordance it cannot use. Your Gmail, Outlook and IMAP credentials stay on our side: the tool that lists mailboxes excludes tokens and sync cursors by an explicit field allowlist.
Tools cover reading, hybrid semantic search, organizing, drafting, calendar, contacts and context. There is no compose-and-send tool, deliberately. Sending is two calls, and the second one has to say so out loud.
When a draft is written with AI, the voice does not come from scanning your sent mail. It comes from your Personal Context — client profiles keyed to domains, typed variables like a per-client price, tone preferences and guardrails you set. An agent can read that context before drafting, so it quotes the number you agreed rather than one it inferred. That is also why our AI email assistant gets facts right more often than a model working from a thread alone.
Honest limits, as of July 2026: MCP access sits on the higher plans rather than the entry tier — check AI Emaily pricing for current terms. Message bodies are fenced as untrusted content, but fencing raises the cost of an injection attack, it does not make one impossible, which is why the send gate exists behind it. And calendar deletion has no undo window; mail actions do.
Frequently asked
See it in AI Emaily
Sources
Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.