Purpose
MultiMail's MCP server provides email capabilities for AI agents. As its official description states: agents currently do not have email inboxes because no one has yet dared to trust them with email. MultiMail solves this problem by assigning real email addresses to agents, introducing a trust ladder mechanism, attaching a cryptographic identity to every email, and controlling sending permissions per recipient.
Key Capabilities
Oversight Mode Every mailbox has an oversight mode, which can start as read-only and be progressively upgraded as the agent gains trust. Agents can request an upgrade via API, and the operator approves it with a one-time verification code; downgrades require no approval, and the agent can also self-limit at any time. The gated approval process is formally verified in Lean 4, ensuring that under any code path, email must pass operator approval before delivery.
Per-Recipient Allowlist In gated_send mode, allowlisted recipients can bypass the approval queue. Exact addresses (such as vendor@example.com) or domain wildcards (such as *@example.com) are supported. Each addition requires operator email approval, and the agent cannot approve allowlist changes on its own. This is a practical compromise: routine communication with known contacts is sent immediately, while new recipients still require oversight.
Cryptographic Identity Every outgoing email carries a signed X-MultiMail-Identity header (ECDSA P-256), whose payload includes the operator name, oversight mode, capabilities, and verification status. Recipients can verify it using the public key at GET /.well-known/multimail-signing-key. There is also an X-MultiMail-Reputation header linking to privacy-preserving reputation data: bounce rate, complaint rate, and account age, without exposing the original address.
Agent DID Relay (Optional) If an agent has already bound a did:key to its MultiMail account, it can pass an optional ucan parameter in send_email / reply_email. MultiMail relays the agent's self-signed UCAN verbatim in a separate X-Agent-Identity header, without signing or endorsing it; the recipient's tooling independently verifies the delegation. This feature does not take effect when no DID is bound.
Agent Self-Registration (auth.md) Agents can register themselves without a browser. The protocol uses a verifiedemail identity assertion, following the auth.md convention inspired by WorkOS AuthKit. The discovery flow follows RFC 9728: GET /.well-known/oauth-protected-resource (resource metadata), GET /.well-known/oauth-authorization-server (authorization metadata with the agent_auth extension), GET /auth.md (human/agent-readable registration guide). The WWW-Authenticate header in 401 responses automatically points agents to these endpoints.
Content Scanning Every outgoing email is scanned before delivery, entering a pending_scan state and then transitioning to delivery or pending_send_approval (in gated mode). Inbound email goes through the same pipeline. Phishing, malware, and prompt injection patterns are flagged before reaching the agent's inbox.
Email Formatting and Threading Email bodies are input in Markdown and output as formatted HTML. Inbound HTML arrives as clean Markdown (15 times fewer tokens than raw MIME). Threading is handled automatically, and headers are set correctly when replying to emails.
How to Use
Remote Server (Recommended): No installation required; authenticate via OAuth on first connection. Works with Claude.ai, Claude Desktop, Claude Code, Cursor, Windsurf, Copilot (VS Code), ChatGPT Desktop, and any MCP client that supports remote servers.
Local stdio Server: As an alternative. You can obtain a key at multimail.dev, or run it without a key to create an account interactively.
Other Access Methods:
- REST API:https://api.multimail.dev（提供 OpenAPI specification)
- CLI: npx -y @mvanhorn/printing-press install multimail (turns every API endpoint into a shell command)
- SDK: Python, Vercel AI SDK, LangChain, LlamaIndex, CrewAI, AutoGen
Use cases
Scenarios where an AI agent needs to send and receive email on behalf of an operator, especially where identity trustworthiness, sending permission control, and human oversight are required. Suitable for agent applications that want to gradually transition from read-only to autonomous sending and that need recipients to be able to verify the sender's identity.
Limitations
- After sending, a pending_scan status is returned, indicating a scan is in progress; the gated mailbox then changes to pending_send_approval awaiting human review, and at this point it should not be retried.
- Whitelist changes must be approved by the operator via email; the agent cannot approve them on its own.
- The DID relay feature only takes effect when the agent is already bound to a did:key.
- Use constitutes agreement to its terms of service and acceptable use policy.
(Note: The materials do not provide specific fees, pricing, platform coverage, or performance data, so none is provided for now.)
