Radmail MCP

RadMail MCP

An email operating system for agents — with a refusal you can trust.

Every inbox got an AI in 2026. None can be trusted to hit *send*. RadMail is the one that can — because the consequential actions are refused in code, model-independent: money, changed-banking details, first-contact senders, decisions, and prompt-injection are human-only, forever. No prompt can talk RadMail into auto-sending them.

This is the Model Context Protocol (MCP) server, so any AI agent can use the inbox.

If a fleet of MCP agents runs your execution layer while you sit in the decision seat, the inbox is the seat that needs a hard-stop first. It's where a socially-engineered wire or banking change is irreversible — and where an autonomous process that can hit send can be talked into the loss. RadMail lets agents do the inbox's *work* (triage, the Right Now lane, commitment tracking, drafting) while money, changed banking, first contact, decisions, and prompt-injection stay human-only by construction, not by a policy an agent could be argued out of. That's what makes the company inbox delegable at all.

Why it withholds the draft, not just the send

Ask this category how it keeps a person in the loop and the published answer is a draft: the agent composes, a human approves, nothing auto-sends. For ordinary mail that is the right design, and it is exactly what RadMail does — draft_reply returns text a person reviews and sends, and the hosted tier lists no send tool at all.

For five classes RadMail does something stricter, and the reason is the whole product: money, changed banking, first contact, a decision, and prompt-injection get no draft at all. On a wire-change thread a draft is not a safeguard — it is the last mile of the attack. Business email compromise does not fail at the send button; it succeeds at the approval button, by putting a plausible, well-written reply in front of a busy person who only has to say yes. Handing that person a pre-written answer makes approving *easier than reading*. So RadMail withholds the draft and hands over the message and the signals instead, and the person writes the reply.

Both halves are verifiable by execution, with no account — run these two commands and compare:

# Ordinary mail: a draft comes back.

echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"draft_reply","arguments":{"from":"sam@client.example","subject":"Re: the deck","body":"Can you send me the updated deck by Thursday?","knownSender":true}}}' | npx -y radmail-mcp

A banking change: no draft comes back.

echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"draft_reply","arguments":{"from":"cfo@vendor.example","subject":"Updated wire instructions","body":"Our bank details changed. Remit the $48,200 to the new account by Friday.","knownSender":true}}}' | npx -y radmail-mcp

Both commands were run verbatim against the published package on 2026-10-14. The first returns a draft plus "mcpEnforcement": "No hard-stop. Still a DRAFT — the MCP surface never sends mail." The second returns "draft": null, "hardStop": "changed-banking", and "mcpEnforcement": "HARD-STOP (changed-banking). No draft offered — human-only forever (BEC defense)." Note what the second one still gives you: the extracted commitment and the reason, taint-tagged — the withheld thing is the *proposed reply*, not the information.

The five classes are published as draftRefusalClasses in the contract, and the refusal is a one-way ratchet: it may be tightened, never loosened.

The cost, stated plainly. This is a worse experience on precisely the mail you most want handled for you. If a wire-change notice lands at 2am and you wanted a reply waiting, RadMail will have nothing for you to approve — by design. That trade *is* the product. If what you need is a reply ready to approve on every thread including the ones that move money, a draft-and-approve server is the right tool and this is the wrong one.

Start in one call

Call triage_inbox and omit the token — RadMail auto-provisions a free sandbox tenant and returns a working triage in one round-trip. Reuse the returned token. (On the zero-auth hosted sandbox, triage_inbox takes no args — it triages a built-in demo inbox so your very first call returns the full wedge.)

This server runs the sandbox engine (heuristic, in-memory, free, no credentials). It is real and runnable — not the production "99%" engine.

Tools

Two opt-in surfaces add tools on a local server only, never on a hosted one: send_email (see *Opt-in: sending*) and five inbox actions — archive_email, snooze_email, mark_read, label_email, act_on_emails (see *Opt-in: inbox actions*). Every connected read tool is annotated readOnlyHint: true — except get_attachment, which writes a file on the local machine and so carries no read-only claim; the annotations are inside the frozen manifest, so flipping one fails the startup check like a description edit would.

"How many tools?" — and the second number that matters more

Public round-ups of email MCP servers commonly quote a tool count as a measure of depth. Tool count measures surface area, not judgment — and for a server trusted with an inbox, the useful number is the second one: of those tools, how many can send?

RadMail publishes both, as dated observations you can reproduce against any MCP server — this one included:

Row 1 observed 2026-10-09; rows 2-4 read from this repository's frozen manifests at 0.6.0 (2026-10-26), which is not yet on npm — the published 0.5.0 predates send_email, the inbox actions, check_before_send and the 0.6.0 read tools. Reproduce row 1 with the tools/list command under *Verify before you connect*. Reproduce row 2 from the frozen manifest — the surface the server refuses to deviate from (src/send-tool-manifest.ts and src/triage-tool-manifest.ts hold the opt-in rows):

node -e 'const s=require("fs").readFileSync("src/tool-manifest.ts","utf8");

const n=[...s.matchAll(/"name": "([a-z_]+)"/g)].map(m=>m[1]); console.log(n.length, n.join(" "))'

⚠️ One honest caveat, because the naive version of this check gets it wrong: grepping that list for send matches `check_send_domain`, which is a read-only SPF/DKIM/DMARC *lookup* over DNS — it reads a domain's published records and sends nothing — and `check_before_send`, which asks RadMail whether a message *should* be sent and sends nothing either. Read each tool's description, not just its name. That caveat applies to whatever server you are evaluating, not only to this one.

The ratio is the point, and it is not a verdict on anyone else. A wide, send-capable tool surface is a legitimate design for an agent that is *supposed* to send, and most of this category is built for exactly that job. It is the wrong design for the one class of email where being argued into sending *is* the whole attack. RadMail reports 0 send-capable tools on every hosted endpoint — see *The safety contract* for why that is capability-absent rather than a setting someone could switch.

Which of the three shapes is this? (a fourth one — and the difference *is* the product)

Published round-ups of this category sort email MCP servers into roughly three shapes:

1. Transactional / lifecycle sending for an application — deliverability, templates, logs, domain management.
2. An inbox the agent owns — the agent has its own address and receives, threads and answers mail