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

2026-04-07

Molted Email is now available as a Model Context Protocol server. If you use Claude Desktop, 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.

npx -y @molted/mcp

That's the runtime. Point it at 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 Desktop 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 package

The @molted/mcp package ships 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 package. They're pre-built message sequences that guide an agent through chaining multiple tools together for a specific workflow.

Five prompts ship with the package:

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

Claude Desktop

Add this to claude_desktop_config.json:

{
  "mcpServers": {
    "molted": {
      "command": "npx",
      "args": ["-y", "@molted/mcp"],
      "env": {
        "MOLTED_API_KEY": "mm_live_..."
      }
    }
  }
}

Cursor

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

{
  "mcpServers": {
    "molted": {
      "command": "npx",
      "args": ["-y", "@molted/mcp"],
      "env": {
        "MOLTED_API_KEY": "mm_live_..."
      }
    }
  }
}

VS Code Copilot and Windsurf follow the same pattern with their respective config files. Full setup instructions are in the MCP server docs.

HTTP transport

For server-side agents or cloud deployments, run in HTTP mode:

MOLTED_API_KEY=mm_live_... molted-mcp --transport http --port 3100

The HTTP transport is stateless - each request creates a fresh session. This works in serverless environments and behind load balancers.

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 Desktop, 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 config block 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.