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

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.