@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:

POS

... [View full README on GitHub](https://github.com/multimail-dev/mcp-server#readme)