MCP-native email: connecting Claude Desktop, Cursor, and Continue.dev to MailMolt in five minutes

2026-04-30 · 7 min read

MCP — the Model Context Protocol — is the thing that turns "the model can answer questions" into "the model can do things." MailMolt ships a first-party MCP server at https://mcp.mailmolt.com/mcp. Adding it to your client takes about three minutes. Here is the walkthrough.

Step 1 — Get an API key

If you don't already have a MailMolt agent, register one (the response includes the API key). Save it as MAILMOLT_API_KEY in your env.

curl -X POST https://api.mailmolt.com/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{"name": "my-agent", "description": "Personal assistant"}'

Step 2a — Claude Desktop / Claude Code

Add MailMolt to your ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on your platform:

{
  "mcpServers": {
    "mailmolt": {
      "url": "https://mcp.mailmolt.com/mcp",
      "headers": {
        "Authorization": "Bearer ${MAILMOLT_API_KEY}"
      }
    }
  }
}

Restart Claude Desktop. Open a new conversation. Type "list my recent threads." The model will call list_threads automatically.

Step 2b — Cursor

Cursor reads .cursor/mcp.json in the project root or ~/.cursor/mcp.json globally. Same config shape as Claude Desktop.

Step 2c — Continue.dev

Continue uses ~/.continue/config.yaml. Both stdio and remote SSE are supported:

mcpServers:
  - name: mailmolt
    url: https://mcp.mailmolt.com/mcp
    headers:
      Authorization: "Bearer ${MAILMOLT_API_KEY}"

Step 2d — Zed

Zed's settings.json (open with Cmd-,):

{
  "context_servers": {
    "mailmolt": {
      "command": {
        "path": "npx",
        "args": ["@mailmolt/mcp"],
        "env": {
          "MAILMOLT_API_KEY": "mm_live_…"
        }
      }
    }
  }
}

Step 3 — What you just unlocked

The MCP server exposes thirteen tools:

• Mail (8): send_message, reply_message, list_threads, get_thread, search_messages, get_inbox_stats, get_profile, get_billing.
• Memory (5): memory_list, memory_get, memory_put, memory_delete, memory_search.

Memory is the underrated one. The agent now has a place to write and retrieve persistent state across sessions — "customer prefers email replies before 5 pm PT" lives at memory_put(key="cust_42_pref", value=…). The next session pulls it back via memory_get or memory_search.

Try it

Some prompts that exercise the surface:

• "Send a follow-up to the customer who emailed yesterday about pricing."
• "Search my inbox for invoices from last quarter and summarize."
• "Remember that this customer prefers a phone call over email — store it as memory."
• "What's my plan and how much send budget do I have left this month?"

Each prompt resolves to one or more MCP tool calls. Your client surfaces the call, the agent confirms (or auto-runs, depending on your trust setting), and the result lands back in the conversation.

Security notes

• The same governance applies as on the REST surface — sandbox agents can't send externally, supervised agents queue for approval, DLP runs on every send, daily and monthly caps surface in X-MailMolt-Plan-* response headers.
• Your API key sits in your client config, not on the wire repeatedly. Rotate it via the MailMolt API if a config file leaks.
• The MCP server is rate-limited per agent. Background scripts that burst-call list_threads will see 429s — paginate or use the inbox stats endpoint.

Closing

MCP is the right protocol for "email as a tool." It avoids the need for the agent to reinvent OAuth, lets you keep the same governance across REST/SMTP/MCP, and works in every major coding assistant out of the box. Three minutes to set up; the rest is what you build on top.