An assistant that can read your mail, create mailboxes, and fix DNS is genuinely useful. It's also, on a bad day, an assistant that deletes a mailbox because it misread which one you meant.
The interesting question about an MCP server for email is therefore not what the agent can do. It's what happens when the agent is wrong — and that's determined entirely by the permission model you put around the MCP server, not by the model's intelligence.
This covers what an MCP server is, what an agent can actually do with a mail platform, and the four mechanisms that make it safe to leave running: split tokens, narrow scopes, two-step destructive operations, and a log of everything.
What an MCP Server Is
The Model Context Protocol is a standard way for an AI client to discover and call tools on an external system. An MCP server publishes a list of tools — each with a name, a description and a typed schema for its arguments — and the client presents them to the model. When the model decides to use one, the client makes the call and feeds the result back.The value is that it's client-agnostic. One MCP server implementation works with Claude Desktop, Claude Code, Cursor, Windsurf and anything else that speaks the protocol, without a per-client integration. The alternative — every assistant vendor building bespoke connectors for every service — is the reason integrations were historically so thin.
For a mail platform this maps cleanly, because the operations were always API calls. An MCP server is a well-described envelope around the REST API that already existed, which is also why the safety properties below aren't agent-specific: they're API properties the agent inherits.
What an Agent Can Do Through the MCP Server
The MCP server publishes over 200 tools, in roughly these groups:
| Area | Examples |
|---|---|
| Domains and DNS | Add domains, read required records, trigger DNS checks, apply Cloudflare DNS, retry DKIM |
| Mailboxes | Create, list, update, pause, change passwords, manage aliases and forwarding, restore from the recycle bin |
| Messages | Read, search, send, reply, forward, draft, schedule, move, flag, report spam or ham |
| Folders and rules | Create and rename folders, manage filters, upload raw Sieve, set auto-reply |
| Contacts and calendar | Create and update contacts and groups, import and export, create and update events |
| Drive | Browse, upload, move, share, bulk operations, sync-device passwords |
| Migration | Test connections, start imports, monitor per-folder progress, cancel, retry |
| Deliverability | Sent and delivered rollups, per-recipient bounces with the receiver's SMTP response |
| Branding | Per-domain white-label configuration, CNAMEs to create, DNS verification |
| Support and billing | Tickets, invoices, plan status |
Two conveniences in the MCP server exist specifically to avoid handing secrets to a model. Mail-client setup can be retrieved as structured data — the servers, ports, and usernames someone needs to configure Outlook — without the mailbox password. Apple Mail configuration profiles can be generated the same way. An agent can walk a new employee through setting up their mail and never see a credential.
Two Kinds of Token, on Purpose
The single most important design decision here is that infrastructure access and mail-content access are different tokens.
Ops token (tm_live_) | Message token (tm_msg_) | |
|---|---|---|
| Reaches | Domains, mailboxes, DNS, forwarding, billing, migrations | Message contents, folders, attachments, contacts, calendar |
| Can't | Read a single message body | Create a mailbox or touch DNS |
| Typical holder | A provisioning script or an ops assistant | An assistant that triages your inbox |
The reason the MCP server splits them is blast radius. An automation that creates mailboxes when someone joins the company has no business reading anyone's mail, and an assistant that drafts replies has no business deleting a domain. One combined credential means a mistake anywhere is a mistake everywhere.
It also means an ops token leaking is a bad day rather than a catastrophe: it can't read a single message.
Scopes: Coarse Outside, Fine Inside
Within each token type, scopes narrow further. The MCP server exposes two layers, and the split solves a real tension.
When you connect through an OAuth client, the consent screen shows five coarse scopes — mail:read, mail:write, mail:admin, messages:read, messages:send. That's deliberate. A consent screen listing sixty granular permissions is a consent screen nobody reads, and an unread consent screen isn't consent.
Behind them, the API enforces fine-grained internal scopes per endpoint — separate permissions for reading forwarding versus writing it, and so on. Coarse enough to understand at the moment of granting; precise enough to enforce meaningfully afterwards.
Scopes are also gated by plan. Nano reaches the verifier only; Starter is read-only plus verifier; Pro and Agency get the full surface. A token can't be created with a scope your plan doesn't include, so the boundary isn't something an agent can talk its way around.
The practical advice: issue one token per automation, with the narrowest scope set that automation needs, and never reuse a token across purposes. A single token shared by four scripts has the union of four scripts' permissions and the accountability of none of them. Details in API scopes and permissions.
Destructive Operations Take Two Steps
Language models are confident. Confidence plus a delete endpoint is how you lose a mailbox.
So deleting a mailbox or a domain isn't one call. The first call creates a delete intent, which deletes nothing and returns a description of what would happen — including risk flags for forwarding rules, aliases, and active migrations that would be affected. The intent expires after ten minutes.
The second call confirms it, and requires an explicit confirmation header. Two round trips with a described consequence in between is a meaningful obstacle to a model that has misunderstood which mailbox you meant, and no obstacle at all to a script that means it.
Mailbox deletion also lands in a recycle bin rather than destroying anything: the mailbox is retired, held for a retention window, and restorable by a single call. Confirming a delete intent is recoverable. Domain and account deletion aren't — they remove their mailboxes permanently and skip the recycle bin, which is worth knowing before you let an agent near either.
Sending and migrations have their own gates. Full detail in safety rails and delete intents.
Idempotency, Because Agents Retry
An agent that gets a timeout does what any reasonable client does: it retries. If the original request actually succeeded and only the response was lost, a naive retry creates the thing twice.
Mutating requests accept an idempotency key. Send the same key twice and the second call returns the first call's result instead of doing the work again. This is standard practice for payment APIs and it matters just as much here, because "create a mailbox" executed twice is a mess and "send this message" executed twice is embarrassing in front of a customer.
Rate limits are per token, with Retry-After on rejection so a well-behaved client backs off correctly. Destructive operations are rate-limited more tightly than reads — a loop that deletes things is stopped early rather than allowed to run to completion.
The Audit Log Is the Point
Every API action is recorded and visible in the dashboard for 90 days: which token, which operation, what it touched, when.
That isn't a compliance checkbox. It's the mechanism that makes an autonomous MCP server acceptable at all. You can't supervise an agent in real time — that would defeat the purpose — so the alternative is being able to reconstruct what it did afterwards. When someone asks "why does this mailbox have forwarding to an address nobody recognises", the log answers it in a minute rather than a week.
It's also how you notice a token doing something it shouldn't: an ops token suddenly making calls at three in the morning is visible, and revoking a single token stops that automation without disturbing anything else.
Automations Worth Building
The genuinely valuable ones are unglamorous.
Onboarding and offboarding. A new starter needs a mailbox, aliases, group membership, and setup instructions. A leaver needs their mail forwarded, their access removed, and their mailbox archived. Both are checklists that humans perform inconsistently and an agent performs the same way every time.
Domain provisioning for an agency. Add the domain, apply DNS, create the mailboxes, verify, report. The tedium of client onboarding is exactly the shape of work worth automating.
Deliverability monitoring. Pull bounce data with the receiving server's SMTP response, group by cause, and surface the ones that indicate a configuration problem rather than a bad address. A weekly summary catches a broken SPF record long before someone notices mail going missing.
Migration supervision. Start a batch, watch per-folder progress, retry failures, and report the completeness audit — see bulk migration.
Inbox triage with a read-only token. Summarise, categorise, and flag. Genuinely useful and, with a read-only message token, incapable of sending anything on your behalf.
What Not to Do
Don't give one token every scope because it's easier during setup. That token will still exist in two years.
Don't let an agent send unattended to external recipients until you've watched it draft for a while. Drafting and sending are separate permissions precisely so you can grant the first without the second.
Don't put tokens in a repository. Environment variables, a secrets manager, anywhere but a file that gets committed.
Don't skip the audit log. Look at it in the first week. It will tell you whether the agent is doing what you think it's doing, which is frequently not the case at the start.
Don't automate domain deletion. There's no recycle bin for domains. Some operations should require a human who can be asked "are you sure".
Frequently Asked Questions
Which AI clients work with the MCP server?
Anything that speaks MCP — Claude Desktop, Claude Code, Cursor, Windsurf, and others. The protocol is the integration, so no client-specific work is needed.
Can the agent read my email?
Only with a message token carrying a read scope. An ops token can't read a single message body no matter what the model asks it to do.
What stops an agent deleting something important?
Destructive operations are two-step: an intent that describes the consequences and expires after ten minutes, then a confirmation with an explicit header. Deleted mailboxes go to a recycle bin and can be restored. Domain deletion can't, which is why it shouldn't be automated.
Does the MCP server send my mail to an AI provider?
Whatever the agent reads goes to whichever model you're running — that's inherent to using an assistant, not specific to this integration. Control it with scopes: a token that can't read your inbox can't send your inbox anywhere.
Do I need a separate token for message operations?
Yes. Infrastructure and message access are deliberately separate token types so that one leaking doesn't expose the other.
What happens if an agent hits a rate limit?
The request is rejected with a Retry-After header and the client backs off. Destructive operations are limited more tightly than reads, so a runaway loop stops early.
Can I see what an agent did last week?
Yes — every API action is in the dashboard audit log for 90 days, with the token, the operation, and the affected resource.
Does MCP server access cost extra?
API and MCP server access is part of the plan; the scopes available depend on which one. Nano reaches the verifier only, Starter is read-only plus verifier, and Pro and Agency have the full surface.
