Multimail MCP Server

@multimail/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

{
  "mcpServers": {
    "multimail": {
      "type": "url",
      "url": "https://mcp.multimail.dev/mcp"
    }
  }
}

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

{
  "mcpServers": {
    "multimail": {
      "command": "npx",
      "args": ["-y", "@multimail/mcp-server"],
      "env": {
        "MULTIMAIL_API_KEY": "mm_live_...",
        "MULTIMAIL_MAILBOX_ID": "01KJ1NHN8J..."
      }
    }
  }
}

Get a key at multimail.dev. Or run without one to create an account interactively.

Config file locations

Trust ladder

Every mailbox has an oversight mode. Start restrictive, graduate as the agent earns trust.

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:

POST /agent/auth -> claim_token + OTP sent to operator email
POST /agent/auth/claim/complete -> API key + tenant_id + granted scopes

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.

Content scanning

Every outbound email is scanned before delivery. Emails enter pending_scan status, then transition to delivery or pending_send_approval (in gated modes). Inbound emails go through the same pipeline. Phishing, malware, and prompt injection patterns are flagged before reaching the agent's inbox.

How it works

• Email bodies are markdown in, formatted HTML out. Inbound HTML arrives as clean markdown (15x fewer tokens than raw MIME).
• Threading is automatic. Reply to an email and headers are set correctly.
• Sends return pending_scan while scanned. Gated mailboxes then transition to pending_send_approval for human review. Do not retry.
• Every outbound email carries a cryptographically signed X-MultiMail-Identity header.
• Reputation data via X-MultiMail-Reputation header: bounce rates, complaint rates, account age. Privacy-preserving, updated daily.

Tools (50)

Example prompts

Find the most recent email from alice@example.com, summarize what she's asking,
then draft a reply saying I'll review this week. Don't send until I approve.

Check my inbox and summarize the last 5 unread emails.
For each: sender, subject, time, and whether it needs action today.

Review the pending approval queue. For each pending email: who it goes to,
the subject, risk factors, and whether to approve or reject.

Show my current sending allowlist. Then add *@acme.com so emails to Acme skip approval.

Environment variables

Also available

• REST API: https://api.multimail.dev (OpenAPI spec)
• CLI: npx -y @mvanhorn/printing-press install multimail (every API endpoint as a shell command)
• SDKs: Python, Vercel AI SDK, LangChain, LlamaIndex, CrewAI, AutoGen

Development

npm install
npm run dev   # Run with tsx
npm run build # Compile TypeScript
npm start     # Run compiled version

License

MIT

By using MultiMail you agree to the Terms of Service and Acceptable Use Policy.