Email MCP servers: what an AI agent should and should not be able to do

What MCP is, briefly

The Model Context Protocol is an open-source standard for connecting AI applications to external systems: data sources, tools, and workflows. Its documentation compares it to a USB-C port for AI applications, one standard way for clients such as Claude or ChatGPT to reach many services. [1]

In MCP terms, a host application runs clients that connect to servers, and servers offer resources, prompts, and tools. Tools are functions the model can call. The specification describes them as model-controlled: the language model can discover and invoke tools based on its understanding of the context and the user’s prompts. [2][3]

What an email MCP server typically exposes

An email MCP server wraps a mailbox or sending service in tools. The obvious set is search messages, read a thread, create a draft, and send a message, sometimes with labeling, archiving, or deletion. Each tool is a named function with a JSON Schema for its inputs, which makes it easy for a model to call, and easy to call in ways its author did not anticipate. [3]

Read tools and send tools carry very different risks. Reading pulls text written by strangers into the model’s context. Sending turns the model’s output into a message from a real person’s address that cannot be recalled. Put both in the same server behind the same credential and the agent can do both in a single turn.

Four risks specific to email

Indirect prompt injection. OWASP describes indirect prompt injection as input from external sources, such as websites or files, that alters the model’s behavior. An inbox is an external source by definition. OWASP’s entry on excessive agency uses email as its example: a maliciously crafted incoming message tricks an assistant into scanning the user’s inbox for sensitive information and forwarding it to the attacker. [4][5]

Over-broad credentials. A token that can read every message, send as the user, and delete mail turns any successful manipulation into a full compromise. MCP’s security guidance warns against wildcard and omnibus scopes and recommends a progressive, least-privilege scope model. It also forbids token passthrough, in which a server forwards a client’s token to a downstream API without validating that the token was issued for that server. [6]

Missing confirmation. The specification says that for trust and safety there should always be a human in the loop with the ability to deny tool invocations, and that clients should prompt for confirmation on sensitive operations. But the protocol does not mandate a particular interaction model, so whether a confirmation actually appears depends on the client and its settings. A send tool that relies on the client to ask first is an unreviewed campaign waiting to happen. [3]

Duplicate and runaway actions. Agents retry. A timeout after a successful send can produce a second send, and a loop can produce a hundred. The specification requires servers to validate inputs, implement access controls, and rate-limit tool invocations, and tells clients to log tool usage, but sending exactly once is the server author’s problem to solve. [3]

A design checklist if you build or buy one

The controls below belong in the server and the systems behind it, not in the prompt. An instruction that says “always ask before sending” is a preference; a send tool that cannot run without a recorded approval is a control. OWASP’s mitigations point the same way: limit extensions and their functions to the minimum necessary, and require a person to approve high-impact actions. [5]

• Separate read, draft, and send into different tools, and ship draft-only by default.
• Scope credentials to one mailbox and the minimum operations; never reuse a person’s full account token.
• Require a confirmation that shows the exact recipients, sender, subject, and body before any send.
• Cap recipients per call and messages per hour on the server, not in the prompt.
• Make sending idempotent with a caller-supplied key so a retry cannot deliver twice.
• Mark inbound message content as untrusted and never let it change what tools may do.
• Log every call with its inputs, outcome, and approving person.
• Enforce opt-outs, bounces, and complaints inside the send path rather than as advice to the model.
• Keep an operator kill switch outside the agent’s credentials.

Why cold outreach raises the stakes

For a personal inbox assistant, a bad send is embarrassing. For outbound email, it is a deliverability and legal event. Messages to people who never asked to hear from you need honest headers, a postal address, a working opt-out, and suppression that holds across every tool and every retry, and mailbox providers watch complaint rates across all of it. [7][8]

That is why a general-purpose send tool is a poor fit for prospecting even when it is well built. The unit that needs approval is not one message but a campaign: audience, sender identity, sequence, volume, and budget, reviewed together and enforced by deterministic code.

Why Actually Agentic ships no MCP server

Actually Agentic deliberately has no MCP server, no agent-facing API, and no embedded AI chat. The customer’s own agent does the research and planning with a published prompt and returns a readable snapshot plus one bounded handoff. A person pastes the full reply into an authenticated browser session, reviews the calculated scale, budget, domains, and sequence, and explicitly approves them. The paste flow never issues an agent token. [9]

The trade-off is real. No agent can launch, pause, or edit a campaign on its own, and some teams want exactly that; for them, an outbound platform with a carefully scoped agent integration may be the better fit. The benefit is that the agent can be as capable as the customer likes, because it holds no credential that could send, spend, or change the program.

After approval, sending runs through deterministic gates, including domain aging, ramping, bounce and complaint pauses, and durable suppression, that no model can bypass. Actually Agentic is prelaunch, and none of those gates guarantees inbox placement or replies. [10]