Molted is Now an MCP Server: Give Your Agent a Policy-Enforced Mailbox in One Line

2026-04-07

Update (September 2026): the MCP server is now hosted at https://mcp.molted.email/mcp, and the @molted/mcp npm package is deprecated. Clients connect by URL with your API key, so new tools reach you without a package update. The server has also grown to 46 tools. The setup below reflects the hosted endpoint; see the MCP server docs for the current tool reference.

Molted Email is now available as a Model Context Protocol server. If you use Claude Code, Cursor, VS Code Copilot, or Windsurf, you can give your AI assistant a fully policy-enforced mailbox with one configuration block and no code to write.

claude mcp add --transport http molted https://mcp.molted.email/mcp \
  --header "Authorization: Bearer mm_live_..."

That's the whole setup: a URL and your API key, and any MCP-compatible agent gets 25 tools, 8 resources, and 5 pre-built email workflows.

Why MCP matters here

MCP is the protocol that lets AI agents discover and use external tools without custom integrations. When you add an MCP server to Claude Code or Cursor, the agent can see what the server offers and call those tools in response to natural language prompts.

For email, this matters for a specific reason: agents that can compose and send email directly are useful, but without policy enforcement between the model and the wire, they're also dangerous. The MCP server doesn't change Molted's enforcement model. Every tool call still runs through the full policy engine - deduplication, cooldown windows, suppression lists, consent checks, rate limits. The agent gets a natural interface to your mailbox, and the guardrails stay where they belong: at the infrastructure layer.

What's in the server

The server launched with 25 tools across four groups, plus resources and prompts.

Inbox and thread tools

Six tools for managing your mailbox inbox:

read_inbox - list threads with filters (mailbox, status, limit)
get_thread - fetch a full thread with all messages and intent classification
reply - reply to a thread (plain text, HTML, or template)
archive - move a resolved thread out of the active inbox
update_thread - change status, metadata, or assignment
approve - approve a pending send from the approval queue

The reply tool supports two modes. Shorthand: provide a body or html string and it wraps it in the _default template automatically. Template mode: provide a template_id and payload for full control. Both modes go through policy enforcement.

Send and compose tools

Five tools for outbound email:

send_email - send a policy-checked email (shorthand or template mode)
draft_email - AI-assisted composition with a pre-check policy preview
dry_run - simulate a send without dispatching, preview the policy decision
batch_send - send to up to 500 recipients with per-recipient policy evaluation
schedule_followup - schedule a delayed follow-up that auto-cancels on reply

The dry_run tool is worth calling out. Before sending anything significant, an agent can call dry_run to see whether the policy engine would allow the send, and why. If the contact is suppressed, if you're over your rate limit, or if there's a cooldown in effect - dry_run tells you before you commit. Agents that check before acting are less likely to burn your sending reputation.

Policy blocks from send_email and batch_send are returned as successful tool results with the block reason - not as errors. This lets the agent reason about what to do next ("this contact is suppressed, I should stop the sequence") rather than treating a block as a crash.

Intelligence tools

Five tools for understanding inbound email:

classify_inbound - classify an email's intent (interested, objection, support, legal, out_of_office, and more)
next_best_action - get a recommendation for what to do next with a contact
get_context - fetch a contact's full timeline: sends, replies, journeys, suppression status
batch_classify - classify multiple inbound emails in one call
batch_next_action - get next-best-action recommendations for multiple contacts

The next_best_action tool returns one of five recommendations: reply, wait, nudge, stop, or escalate. It factors in send fatigue, engagement history, and intent signals from previous replies. An agent that uses this before sending a follow-up is less likely to over-contact a contact who already signaled disinterest.

Governance and outcomes tools

Eight tools for compliance and attribution:

add_suppression / check_suppression / remove_suppression - manage suppression lists
check_consent / record_consent - GDPR/CCPA compliance
record_outcome - log a business outcome (activation, trial conversion, deal closed, upsell)
outcome_dashboard - get a revenue attribution summary
journey_impact - which journeys drove the most outcomes

The consent and suppression tools are particularly useful in agentic contexts. An agent that manages its own contact acquisition can record consent at the point of capture and check it before sending, all through the same tool interface it uses for everything else.

Resources: read-only context for agents

Resources are different from tools. They're static (or near-static) data that agents can pull into working memory without making an API call that modifies state.

The MCP server exposes eight resources:

URI	What it gives the agent
`molted://mailboxes`	All mailboxes with addresses, reputation, autonomy level, and send limits
`molted://mailboxes/{id}/config`	Full mailbox config: rules, SLA settings, alerts, autonomy
`molted://templates`	Available templates with their variable schemas
`molted://templates/{id}`	A specific template with version history
`molted://segments`	Audience segments with filter definitions
`molted://journeys`	Active journeys with step definitions
`molted://policy-rules`	Current policy rules and thresholds
`molted://domains`	Verified domains with DNS and warmup status

An agent that reads molted://policy-rules before deciding how many follow-ups to schedule is making a better-informed decision than one that finds out from a policy block after the fact. Resources shift that discovery earlier.

Prompts: pre-built multi-step workflows

Prompts are the most opinionated part of the server. They're pre-built message sequences that guide an agent through chaining multiple tools together for a specific workflow.

Five prompts ship with the server:

draft-followup - Given a thread ID, reads the conversation, checks your budget, and drafts a contextually appropriate reply. Useful for agents that need to compose follow-ups that match the tone of an existing conversation.

triage-inbox - Reads unread threads, classifies intent on each, recommends an action, and auto-archives resolved, spam, and out-of-office threads. This is the "clear my inbox" workflow.

pre-send-check - Before sending, verify suppression status, consent, and remaining budget for a contact. Returns a GO / NO-GO recommendation. An agent that runs this before any significant outbound is less likely to send to someone who shouldn't receive it.

investigate-bounce - Given a bounced thread, investigates why it bounced and recommends corrective action. Hard bounces are automatically suppressed.

campaign-readiness - Given a segment, checks whether conditions are right to send: budget capacity, template readiness, domain health, and negative-signal budget. Returns a readiness assessment before you commit to sending.

These prompts don't replace your code. They're starting points for agents that need a structured workflow without you writing every tool call sequence from scratch.

Setup

The server is hosted at https://mcp.molted.email/mcp and speaks Streamable HTTP. Every client needs the URL and an Authorization: Bearer mm_live_... header carrying your API key.

Claude Code

claude mcp add --transport http molted https://mcp.molted.email/mcp \
  --header "Authorization: Bearer mm_live_..."

Cursor

Add this to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "molted": {
      "url": "https://mcp.molted.email/mcp",
      "headers": {
        "Authorization": "Bearer ${env:MOLTED_API_KEY}"
      }
    }
  }
}

VS Code Copilot

Add this to .vscode/mcp.json. VS Code needs "type": "http", and the inputs entry prompts for the key once so it never lands in the file:

{
  "inputs": [
    { "type": "promptString", "id": "molted-api-key", "description": "Molted API key", "password": true }
  ],
  "servers": {
    "molted": {
      "type": "http",
      "url": "https://mcp.molted.email/mcp",
      "headers": { "Authorization": "Bearer ${input:molted-api-key}" }
    }
  }
}

Windsurf

Windsurf uses serverUrl instead of url; see the Windsurf setup in the MCP server docs. Full setup instructions for every client are in the MCP server docs. Claude Desktop and claude.ai custom connectors need OAuth sign-in, which is coming.

Stateless and per-request

The hosted server is stateless: each request creates a fresh session and authenticates with its own bearer key, so nothing is shared between requests or tenants. There is nothing to install or upgrade on your side.

Scoped keys

If you're running a multi-tenant setup where each agent should only access its own mailbox, generate a scoped API key (scoped to a specific mailbox ID). The MCP server will automatically restrict all tool calls to that mailbox's context. No extra configuration required.

What this doesn't change

Adding MCP doesn't bypass anything. The same policy engine that runs on every CLI send and every API call runs on every MCP tool call. Rate limits, suppression checks, deduplication, consent validation - all of it still runs.

If you've configured your mailbox to require human approval for certain send conditions, that still applies when an agent calls send_email through MCP. The tool returns pending_approval and the send sits in the approval queue until a human approves it. The interface changed; the governance didn't.

This is worth stating clearly because MCP makes it easier for agents to send email. That's the point. But "easier to send" and "easier to send without guardrails" are different things. The enforcement is at the infrastructure layer, not in the tool definition, which means you can't accidentally write a prompt that bypasses it.

If you're building agents in Claude Code, Cursor, or any other MCP-compatible runtime and you want them to have a proper managed mailbox - with policy enforcement, inbound handling, and decision traces - this is the setup.

Get your API key from the Molted portal, add the command or config above, and the tools appear in your runtime automatically.

Full tool reference, resource schemas, and prompt documentation: MCP Server docs.

For background on how the underlying policy engine works across all of these tool calls, The Policy Rules That Protect Your Sender Reputation covers what's being enforced on every send.