multimail-dev/mcp-server

Your agent doesn't have email yet because nobody trusts it with email yet. MultiMail fixes that. A real email address with a trust ladder from read-only to fully autonomous, cryptographic identity on every message, and per-recipient sending controls.
Quick start
Remote server. No install. Authenticates via OAuth on first connect.
Works with Claude.ai, Claude Desktop, Claude Code, Cursor, Windsurf, Copilot (VS Code), ChatGPT Desktop, and any MCP client that supports remote servers.
Alternative: local stdio server
Get a key at multimail.dev. Or run without one to create an account interactively.
Config file locations
| Client | Config file |
|--------|------------|
| Claude Code | ~/.claude/.mcp.json |
| Claude Desktop | claude_desktop_config.json |
| Cursor | .cursor/mcp.json in your project |
| Windsurf | ~/.codeium/windsurf/mcp_config.json |
| Copilot (VS Code) | .vscode/mcp.json in your project |
| OpenCode | mcp.json in your project |
| ChatGPT Desktop | Settings > MCP Servers |
Trust ladder
Every mailbox has an oversight mode. Start restrictive, graduate as the agent earns trust.
| Mode | Behavior |
|------|----------|
| read_only | Agent reads email. All sends blocked. |
| gated_all | Every action requires human approval. |
| gated_send | Outbound held for approval. Inbound immediate. **(default)** |
| monitored | Agent sends freely. Copies go to oversight address. |
| autonomous | Full send/receive. No gates. |
Agents request upgrades via the API. The operator approves with a one-time code. Downgrades need no approval. The agent can always restrict itself.
The gated approval flow is formally verified in Lean 4. No email reaches delivery without passing through operator approval, for every possible code path.
Per-recipient allowlist
In gated_send mode, allowlisted recipients bypass the approval queue. Add exact addresses (vendor@example.com) or domain wildcards (*@example.com). Every addition requires operator email approval. The agent cannot self-approve allowlist changes.
The practical middle ground: routine correspondence with known contacts goes immediately, new recipients still require oversight.
Cryptographic identity
Every outbound email carries a signed X-MultiMail-Identity header (ECDSA P-256). The payload includes operator name, oversight mode, capabilities, and verification status. Recipients verify against the public key at GET /.well-known/multimail-signing-key.
A separate X-MultiMail-Reputation header links to privacy-preserving reputation data: bounce rates, complaint rates, account age. No raw addresses exposed.
Without verified identity, recipients cannot distinguish your agent from a spammer. With it, they can verify the operator, the oversight level, and the sending history before reading a word.
**Agent DID relay (optional).** If your agent has bound a did:key to its MultiMail account, pass an optional ucan parameter to send_email / reply_email. MultiMail relays your agent's self-signed UCAN verbatim in a separate X-Agent-Identity header (did="…"; ucan="…") — it does **not** sign or vouch for it; recipient tooling verifies the delegation independently. Inert unless a DID is bound.
Agent self-registration (auth.md)
Agents can register themselves without a browser. The protocol uses verified-email identity assertion, following the auth.md convention inspired by WorkOS AuthKit:
Discovery follows RFC 9728:
- GET /.well-known/oauth-protected-resource (resource metadata)
- GET /.well-known/oauth-authorization-server (authorization metadata with agent_auth extension)
- GET /auth.md (human/agent-readable registration guide)
The WWW-Authenticate header on 401 responses points agents to these endpoints automatically. An agent that hits a 401 can follow the link, read the registration protocol, and onboard itself.