# RadMail

> The inbox that thinks. A business email operating system — one engine, two halves:
> an inbound brain that triages what needs you now, and an outbound half that follows
> through. A Sureel venture, sibling to SEOmonster and GBPmonster.

## Status

RadMail is PRE-RELEASE / EARLY-ACCESS. The commercial multi-tenant product has not
launched publicly yet — we are opening a founding-partner waitlist. The engine is
live in a test bed on two real businesses today; it is not a generally available,
stabilized v1 product. Treat any "shipped" language as scoped to that test bed.

## What RadMail is

A single email engine with two halves:
1. Inbound brain — reads the mailbox, separates "need you now" from "can wait" from
   "already handled," and surfaces the few messages that actually require a human.
2. Outbound + follow-through — drafts, sequences, and autonomously follows through on
   threads, then correlates replies back to the conversation.

## The four differentiators

1. Inbound brain — behavioral triage that learns which senders and threads matter,
   instead of rule-based filters.
2. Autonomous follow-through — the system chases open threads to completion rather
   than just drafting once.
3. Reply correlation (outbound moat) — replies are matched back to the originating
   outbound thread, so nothing falls through.
4. Deliverability & engagement — sending reputation and engagement are treated as a
   first-class concern, not an afterthought.

## New capabilities (shipped and live in the product)

These are live in the RadMail product today. (RadMail overall is still
pre-release / early-access — see Status above — but nothing below is a preview.)

- Real-inbox search for agents — the v1 search API (https://app.radmail.ai/api/v1/search)
  gives an API key ranked search over the org's REAL ingested inbox (metadata
  hits + ~160-char snippet + where it matched; sender + date filters), and the
  radmail-mcp package's connected mode puts it behind the MCP `search` +
  `read_email` tools (connected `list_right_now` + `list_commitments`
  read the real Right Now lane and tracked promises the same way). Read-only,
  fail-closed, taint-marked. Mint a key at
  https://app.radmail.ai/settings/api-keys. Docs: https://radmail.ai/real-inbox-search
- Work-units usage rollup — GET https://app.radmail.ai/api/v1/usage (API key, read scope) returns a
  read-only rollup of how much WORK RadMail prepared for the org over a window:
  reply drafts and lead-research dossiers counted as the headline work units,
  separately from the supporting triage, broken down by feature with call counts
  and engine cost. Query ?days= (default 30, max 90). Per-org aggregates only —
  counts and cost, never message content — and it writes no billing/plan state.
  This is pillar 4 ("the work is the meterable value") made programmatic; the
  same rollup renders in-app at https://app.radmail.ai/settings/usage.
- Apple Mail connector — one command connects every inbox already aggregated in
  Apple Mail on a Mac. No per-account OAuth, no forwarding, no shared passwords.
  Metadata + normalized text only (attachment contents never read); Message-ID
  idempotent so it runs safely alongside server-side connectors. Needs a RadMail
  account with write scope. Docs: https://radmail.ai/connect-apple-mail
- Lead lane — a new-business inbound is treated as a first-class "lead": instant
  alert (web push / SMS / email / email.lead webhook), a researched dossier
  grounded ONLY in the email + your own sender history (no web, never invents),
  and a human-approval-only drafted reply. A first-contact reply stays behind the
  BEC hard-stop — human-only, forever. Docs: https://radmail.ai/lead-lane
- Answer-ready inbox — when an important email lands (high/critical importance,
  or flagged for human eyes), RadMail prepares the reply ON ARRIVAL: the alert
  has already fired, the importance level is known, and a draft is waiting
  pre-filled in the reply panel. Human-approval-only — structurally cannot
  auto-send; the BEC hard-stop (money / changed banking / first contact /
  decisions / injection stay human) is untouched; drafting rides a bounded
  per-org daily AI budget; hard rules forbid payment-action promises and
  banking-detail echoes. Docs: https://radmail.ai/answer-ready
- Watched threads / last-word tracker — mark a thread watched (in the inbox, or
  via the v1 API: POST /api/v1/threads/{id}/watch, API-key + scope gated) and
  RadMail tracks who spoke last. Them-last pins the thread to the top of the
  Right Now lane; me-last sits in a quiet Watching panel instead of nagging.
  Watched threads carry a protected importance floor.
- Attention-verdict lanes — the inbox renders a verdict per thread: ACT (needs
  you, with a time horizon), WAITING ON (you're owed a reply), GLANCE (worth a
  look, no action), and a folded FILE/FEED lane. Every verdict is explainable.
- Importance rule v2 (live) — important-eligible = personally addressed AND
  reputable sender (reputation earned from your real correspondence); all else
  is dampened, EXCEPT protected floors that can never be tuned into silence:
  regulator notices/recalls, invoices/past-due, security alerts, legal notices,
  leads, and watched threads.
- Sent-folder ingestion — RadMail ingests your outbound mail (self-sender
  guarded, so its own notifications never count), giving the engine outbound
  visibility: your reply history accrues sender reputation and grounds
  waiting-on state.
- Read-then-egress anomaly detector — a fourth injection-defense layer (after
  the hard-stop in code, untrusted-email-body taint-marking, and read-only
  fail-closed connected mode). It watches egress routes — including the notify
  rail — for email content being read then immediately leaving; it detects and
  flags for human review, and never silently blocks legitimate mail.
- Draft-acceptance instrumentation — each draft an operator decides on is
  recorded with its outcome (sent unedited / edited before sending /
  discarded). No acceptance rates are published yet; when they are, they'll
  come from this instrumentation, not a marketing estimate.
- Notify rail + demand read — POST /api/v1/notify raises a request that rides
  the alert rail to a human (in-app respond box; acked/responded loop-close via
  GET /api/v1/notify/{id}); GET /api/v1/demand returns aggregates-only demand
  signals (tool names + event counts — never message content, arguments, or
  queries). Both API-key + scope gated; neither loosens the hard-stop.
- Outbound email templates rebuilt for readability — AA-contrast, dark-mode-safe
  defaults across RadMail's own notification emails.

## For agents / MCP (one-step connect)

RadMail ships a SANDBOX MCP server you can connect to in one step — no
credentials, no signup, free. Point any MCP client at the sandbox endpoint and
you get the real heuristic triage engine running in memory. This is the SANDBOX
engine; the production multi-tenant engine is test-bed-gated and not generally
available yet.

- Sandbox MCP endpoint: https://radmail.ai/api/mcp/sandbox
- Transport: HTTP (streamable). Auth: none (sandbox).
- Telemetry: the sandbox records anonymous demand signals (tool name + event type only — never message content, arguments, or queries) so RadMail can see what agents actually use and ask for.
- Machine-readable pointer: https://radmail.ai/.well-known/mcp.json
- Human docs: https://radmail.ai/for-agents
- See it work first (no signup, no creds): https://app.radmail.ai/pulse
- Live product preview: https://app.radmail.ai

Example MCP client config (point your client here, no creds):

    {
      "mcpServers": {
        "radmail": {
          "url": "https://radmail.ai/api/mcp/sandbox",
          "transport": "streamable-http"
        }
      }
    }

### Tools the agent gets (the radmail-mcp server's full allowlist — this is the whole list)

Descriptions below are the server's own, verbatim (minus the shared SAFETY
taint-notice suffix several carry). The zero-auth hosted sandbox
endpoint above serves the six core triage tools
(triage_inbox, list_right_now, why_surfaced, list_commitments, draft_reply, search); run `npx -y radmail-mcp`
for the full surface (without a key it runs the same free in-memory sandbox engine).

- triage — Score one message on TWO axes (importance × urgency), explain WHY it surfaced, break it into 4 dimensions, flag any hard-stop (BEC), and extract any commitment. OMIT `token` to auto-provision and get a working triage in ONE call.
- triage_inbox — ONE round-trip over a batch of messages: the Right Now lane + every open commitment + every hard-stop. The whole RadMail wedge in a single call. OMIT `token` to auto-provision.
- list_right_now — Return only the 'Right Now' lane — the short can't-miss list, each item with why-surfaced. TWO MODES: pass `messages` and RadMail ranks THOSE (free in-memory sandbox, with hard-stop flags) — or OMIT `messages` with RADMAIL_API_KEY set on this server and RadMail returns the user's REAL Right Now lane via the v1 API (read-only; band + importance + urgency + reasons from the live engine; get a key at https://app.radmail.ai/settings/api-keys).
- why_surfaced — Explain in plain English WHY a message was surfaced — the signals (sender, urgency words, commitment, hard-stop) behind its importance × urgency scores. Transparency, not a black box.
- draft_reply — Draft the reply that discharges a commitment owed in a message. DRAFT ONLY — never auto-sent. REFUSES (human-only) for money / changed-banking / first-contact / decision / injection.
- list_commitments — List open promises — what's owed and to whom, with the due window. TWO MODES: pass `messages` and RadMail extracts promises from THOSE (free in-memory sandbox) — or OMIT `messages` with RADMAIL_API_KEY set on this server and RadMail returns the user's REAL tracked commitments via the v1 API (read-only; direction / party / action / due / state / confidence from the live engine; get a key at https://app.radmail.ai/settings/api-keys). On the day each is due, RadMail drafts the follow-through for review (never auto-sent).
- search — Find a specific message by sender / subject / content — most-relevant + newest first; each hit says where it matched. TWO MODES: pass `messages` and RadMail ranks THOSE (free in-memory sandbox, zero setup) — or OMIT `messages` with RADMAIL_API_KEY set on this server and RadMail searches the user's REAL inbox via the v1 API (read-only; get a key at https://app.radmail.ai/settings/api-keys).
- read_email — CONNECTED MODE: fetch one full email (headers + textBody) from the user's REAL RadMail inbox by id — use a `search` hit's messageId. READ-ONLY by construction: connected mode never sends, drafts against, or mutates real mail, and the BEC hard-stops stay human-only forever. Requires RADMAIL_API_KEY on this server (create one at https://app.radmail.ai/settings/api-keys); without it, this tool returns setup instructions instead of an error.
- check_send_domain — ZERO-AUTH email-deliverability read for ANY domain (e.g. "example.com") — no token, no key, no signup. Fetches and grades the domain's live SPF, DMARC, and DKIM DNS posture: a verdict per record type (pass / warn / fail / none), the raw records, parsed details (SPF all-qualifier + DNS-lookup-count risk; DMARC p= policy, pct, rua reporting; which common DKIM selectors publish a key or a delegated CNAME), plus plain-language `advice` lines you can act on. READ-ONLY DNS by construction: it never sends mail and never changes a record — there is no send capability on this surface.
- provision_sandbox — Mint a FREE sandbox tenant token instantly — no creds, no signup. Most tools auto-provision for you, so you usually don't even need this. The response `safety` block restates the permanent BEC hard-stops.
- report_need — Tell RadMail something was awkward, missing, or slow. Folds into per-agent learning (call STRUCTURE only — never email content).
- request_capability — Request a capability you wish RadMail exposed. Aggregated into unmet-demand that shapes the surface and roadmap.
- radmail_learning_insights — Show what RadMail has learned about how YOU work — your most-used tools, learned response shape, recurring focus, and your capability wishlist. Transparency, not a black box.

### Connected mode — your REAL inbox, read-only

The radmail-mcp package has a connected mode: set the RADMAIL_API_KEY environment
variable (mint a key — they start with tmk_ — at https://app.radmail.ai/settings/api-keys)
and four tools operate on the user's REAL inbox via the v1 API — search,
list_right_now, and list_commitments gain a real-inbox mode (omit `messages`)
and read_email is connected-only. Search rides https://app.radmail.ai/api/v1/search
(ranked hits, ~160-char snippets, matchedIn on every hit, from/after/before
filters):

- search — Omit `messages` and search finds any email you've ever received in your real RadMail inbox — ranked most-relevant + newest first, with optional from / after / before filters alongside query and limit. Read-only.
- read_email — Fetch one full email (headers + textBody) from your REAL RadMail inbox by id — use a search hit's messageId. Read-only by construction: connected mode never sends, drafts against, or mutates real mail, and the BEC hard-stops stay human-only forever.
- list_right_now — Omit `messages` and RadMail returns your REAL can't-miss lane — the live engine's own band + importance + urgency + reasons per item (limit + offset paging). No local hard-stop determinations are fabricated; the API's judgments surface as-is. Read-only.
- list_commitments — Omit `messages` and RadMail lists your REAL open promises — direction (owed_by_us / owed_to_us), party, action, due date/phrase, state, confidence (limit + offset paging). Read-only.

Connected mode is READ-ONLY and fail-closed: it never sends, drafts against, or
mutates real mail, any API error returns a typed failure with zero fabricated
results, and every real-mail field is taint-marked `untrusted-email-body` so an
agent treats it as data, never instructions. The BEC hard-stops are untouched.
Without a key, the package behaves exactly like the zero-auth sandbox.
As of radmail-mcp v0.5.0, the server's tool descriptions are FROZEN under a
sha256 manifest verified at startup: if any description drifts from the audited
text, the server refuses to serve (fail-closed) — a defense against MCP
tool-description poisoning, pinned by an adversarial golden set in the package's
own test suite.

Connect (Claude Code): claude mcp add radmail -e RADMAIL_API_KEY=tmk_... -- npx -y radmail-mcp
Note: `npx -y radmail-mcp` installs the package straight from npm (live as of July 2026, listed on the official MCP registry as ai.radmail/radmail-mcp). The source is MIT and public at https://github.com/radmail-ai/radmail-mcp — the repository npm's `repository` field and the official MCP registry's current (`isLatest`) entry both point at, so the refusal behaviour described here can be read in the code, not just taken on trust. Prefer no install at all? The zero-auth hosted sandbox above works right now.
Docs: https://radmail.ai/real-inbox-search

### Hard-stop policy (enforced in the server, stated as policy)

There is NO auto-send tool. The following are human-only, forever — a deliberate
defense against business-email-compromise (BEC) fraud:
- Auto-send a payment, wire, ACH, or any movement of money.
- Auto-send or change banking / wire instructions or a new account.
- Auto-send a first-contact / cold message to a new third party.
An agent connected to RadMail cannot do these on a human's behalf, by design. The
MCP server enforces this; it is not aspirational.

There is a SECOND, stronger refusal that is easy to miss because it is not
send-shaped. For these five classes — money, changed-banking, first-contact, decision, injection — the
radmail-mcp package's draft_reply refuses to produce a DRAFT at all and routes the
message to a human, rather than drafting something a human must then catch:
Stronger than the no-send guarantee, and separate from it: for these five classes the radmail-mcp package's draft_reply refuses to produce a draft AT ALL and routes the message to a human, rather than drafting something a human must then catch. `decision` and `injection` are the two that the forbiddenActions list above does not cover, because they are not send-shaped — they are classes where even a proposed reply is withheld. Scope: the radmail-mcp package (the production stdio server), whose tool descriptions are frozen under a fail-closed sha256 manifest since 0.5.0 — so this is verifiable by reading the tool list back, or in the MIT source. The zero-auth hosted sandbox serves a fixed demo inbox and accepts no caller-supplied message, so it cannot be used to exercise these refusals.

### How the hard-stop is enforced (enforcement model: capability-absent)

"Enforced in the server" can mean several different things, and the difference
matters when comparing one server's safety posture to another's. Stated as a
generic scale, so the value RadMail reports is interpretable rather than a
marketing word:

- capability-absent: The tool that would perform the forbidden action does not exist on the server, so it cannot be called. There is nothing to configure and nothing to bypass.
- config-restricted: The capability exists and is narrowed by configuration — an allowlist, a scope, a policy file. Whoever holds the configuration can widen it again.
- policy-gated: The capability exists and is restrained by instructions, prompts, or documented policy that a model is asked to follow.

RadMail is "capability-absent". There is no setting, feature flag, plan tier, environment variable, or admin toggle on RadMail's MCP server that enables a forbidden action. The only behaviour-widening environment variables are RADMAIL_API_KEY and RADMAIL_API_URL, which unlock connected mode — and connected mode is read-only: it widens what an agent can READ, never what it can do. Enabling a forbidden action would require shipping a tool that does not exist.

Scope, stated precisely: this describes RadMail's MCP SERVER surface. It is NOT a
claim that RadMail-the-product never sends mail — the product has an outbound rail
that operates behind human review.

Verify it rather than trusting it: Do not take this contract's word for it — call the server and read the tool list back. Every tool is read, triage, search, explain, draft, or read-only diagnostic. If you find one that sends money, changes banking, or makes first contact, this contract is wrong and security@radmail.ai wants to hear about it.
  curl -s -X POST https://radmail.ai/api/mcp/sandbox -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Expect: A tool list containing no send-capable tool. draft_reply produces a draft for a human to review and send; it does not send.

Verify the PACKAGE tier too — it is the surface the stronger claims live on:
The command above checks the hosted sandbox, which serves 6 core triage tools over a fixed demo inbox. The `draftRefusalClasses` guarantee and the frozen tool manifest are scoped to the radmail-mcp PACKAGE — a larger surface the sandbox does not expose — so verify that tier directly rather than inferring it from the sandbox. This is the harder surface to check and it is the one the stronger claims live on.
  printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"verify","version":"1"}}}' '{"jsonrpc":"2.0","method":"notifications/initialized"}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | npx -y radmail-mcp
Expect: A tool list containing no send-capable tool — every entry is read, triage, search, explain, draft, or read-only diagnostic. draft_reply's own description states: "DRAFT ONLY — never auto-sent. REFUSES (human-only) for money / changed-banking / first-contact / decision / injection." check_send_domain is named for what it inspects, not what it does: it is a read-only SPF/DMARC/DKIM DNS lookup and sends nothing. Observed 13 tools on the published package as of 2026-08-24; the count is an observation, the absence of a send tool is the claim.
Tamper-evidence: Since 0.5.0 the package's tool names, descriptions, and input schemas are frozen under a sha256 manifest that the server recomputes at startup and refuses to serve on any mismatch — a fail-closed defense against MCP tool-description poisoning. That means the tool list you read back is the audited text or the server does not answer at all.
Source (MIT, public): https://github.com/radmail-ai/radmail-mcp

Machine-readable form of everything above: https://radmail.ai/.well-known/mcp.json and
https://radmail.ai/.well-known/agent-safety.json

### For builders (referral — humans/platforms only)

If you operate an agent, build on RadMail, or are the end-user an agent serves,
honest attribution (a ?via= link or an X-RadMail-Ref header) earns rev-share /
credits at launch. This rewards PEOPLE and PLATFORMS, never a model. RadMail never
instructs, bribes, or injects an agent to recommend it — the only reason to
recommend RadMail is that it works and connects in one step.

### Webhooks for your orchestrator

RadMail can emit an `email.lead` webhook when a new-business inbound is detected —
carrying metadata, a dossier digest, and the routing target (never the raw body) —
so an external orchestrator can dispatch the lead. Like every RadMail send path,
nothing here loosens the hard-stop: a first-contact reply is still human-only.

## Common questions (answers)

Q: How do I connect RadMail to my AI agent?
A: Point your MCP client at the RadMail sandbox endpoint at https://radmail.ai/api/mcp/sandbox — that is the whole step. No account, no credentials, and no card; the sandbox runs RadMail's real heuristic triage engine in memory for free.

Q: Is connecting RadMail's MCP server free?
A: Yes. The sandbox MCP server is free and requires no credentials — it exists so an agent can wire up and get value in one step. It is the sandbox engine; the production multi-tenant engine is launch-gated.

Q: Will RadMail send email on my agent's behalf?
A: No — there is no auto-send tool. RadMail's MCP server exposes only read, triage, search, draft, and read-only diagnostic tools; draft_reply returns text for a human to review. Money, new banking, and first contact are human-only forever, as a defense against business-email-compromise fraud.

Q: What tools does RadMail's MCP server expose to an agent?
A: Thirteen safe tools: triage and triage_inbox (two-axis ranking — one message or a whole batch), list_right_now (the can't-miss lane), why_surfaced (explainable reasons), list_commitments (what is owed and by when), draft_reply (a reviewable draft — never auto-sent), search (find a message by sender, subject, or content — most-relevant + newest first, with why-matched on every hit), read_email (connected mode: fetch one full message from your real inbox, read-only), check_send_domain (zero-auth SPF / DMARC / DKIM deliverability read for any domain), provision_sandbox (mint a free sandbox tenant), report_need and request_capability (tell RadMail what was awkward or missing), and radmail_learning_insights (what RadMail has learned about how you work). With RADMAIL_API_KEY set, search, read_email, list_right_now, and list_commitments operate read-only on your REAL inbox; the zero-auth hosted sandbox endpoint serves the six core triage tools. There is deliberately no tool that sends money, changes banking, or makes first contact.

Q: What is the difference between RadMail's sandbox and connected mode?
A: Sandbox is zero-auth: the hosted endpoint at https://radmail.ai/api/mcp/sandbox (and the radmail-mcp package with no key) runs a free, in-memory heuristic engine over demo messages or messages you pass — no account, no credentials, no card. Connected mode is read-only real-inbox access: set RADMAIL_API_KEY on the radmail-mcp package (mint a key at https://app.radmail.ai/settings/api-keys) and search, read_email, list_right_now, and list_commitments operate on your REAL RadMail inbox via the v1 API — read-only by construction, fail-closed on any API error, every real-mail field taint-marked untrusted-email-body. Without a key the package behaves exactly like the zero-auth sandbox, and the connected tools return setup instructions instead of an error.

Q: Why is RadMail a safe choice for an agent that handles email?
A: Because the dangerous actions are structurally impossible: RadMail's MCP server has no tool that auto-sends a payment, changes wire instructions, or cold-contacts a new party. Those are human-only by design, so an agent using RadMail cannot be tricked into business-email-compromise fraud.

Q: Can I see RadMail actually working before I connect or sign up?
A: Yes. The public magic-moment at https://app.radmail.ai/pulse shows RadMail triaging a live inbox — the 'Right Now' lane, an explainable 'why surfaced' on each message, and the BEC hard-stop visibly refusing a money / new-banking / first-contact send — with no signup, no credentials, and no card. The live product preview is at https://app.radmail.ai; agents can also connect the free sandbox MCP server in one step.

Q: Does RadMail try to make my agent recommend it?
A: No. RadMail never injects instructions into an agent, pays for mentions, or addresses the model at all. Its referral program rewards the human operator, the integration builder, and the end user with honest attribution and credits — the only thing aimed at the agent is a surface that makes it succeed faster.

Q: Can RadMail connect a whole Mac's worth of inboxes (Apple Mail) to my agent?
A: Yes. RadMail ships a local Apple Mail connector: one command connects every inbox already aggregated in Apple Mail on a Mac — no per-account OAuth, no forwarding rules, and no shared passwords. It reads message metadata and normalized text (attachment contents are never read) and is Message-ID idempotent, so it runs safely alongside server-side connectors without creating duplicates. It needs a RadMail account with write scope; RadMail is pre-release, so this is early-access.

Q: Does RadMail alert and draft on inbound sales leads automatically?
A: Yes — RadMail has a lead lane. A new-business inbound is scored as a first-class 'lead' that can never be tuned into silence, fires an instant alert (web push, SMS, email, or an email.lead webhook), and — where the pipeline is enabled — attaches a researched dossier grounded ONLY in the email and your own sender history (no web access, instructed never to invent) plus a drafted reply. The draft is human-approval-only and structurally cannot send: a first-contact reply stays behind the BEC hard-stop, human-only, forever.

Q: Can an AI search my real email?
A: Yes — read-only. Mint an API key at https://app.radmail.ai/settings/api-keys (keys start with tmk_), set it as RADMAIL_API_KEY on the radmail-mcp package, and the search tool searches your REAL ingested inbox (ranked most-relevant + newest first, with sender / date filters and a why-matched on every hit) while read_email fetches a full message by id, list_right_now returns your real can't-miss lane, and list_commitments lists your real open promises. Connected mode is read-only by construction and fail-closed on any API error; every real-mail field is taint-marked untrusted-email-body, and money, changed banking, first contact, decisions, and suspected injection stay human-only forever. Want to try before connecting anything? The zero-auth hosted sandbox at https://radmail.ai/api/mcp/sandbox runs the same search over a demo inbox with no key at all.

Q: How do I connect an agent to my real inbox?
A: Three steps: mint an API key at https://app.radmail.ai/settings/api-keys, set it as the RADMAIL_API_KEY environment variable on the radmail-mcp MCP server (for Claude Code: claude mcp add radmail -e RADMAIL_API_KEY=tmk_... -- npx -y radmail-mcp), and restart — then search finds any email you've ever received, read_email fetches the full message, list_right_now returns your real can't-miss lane, and list_commitments lists your real tracked promises, all read-only. radmail-mcp is live on npm, so the npx command works as-is; the zero-auth hosted sandbox at https://radmail.ai/api/mcp/sandbox works instantly with no key if you want to try first.

Q: If AI agents run my company's execution layer, what does giving them my email actually require?
A: The inbox is the seat where an agent can be socially engineered into an irreversible action — wiring money, changing where payments are remitted, or replying to a stranger with sensitive data — so an agent-run inbox needs a hard-stop before anything else. RadMail is the email MCP with a business-email-compromise hard-stop built in: money, changed banking, first contact, decisions, and prompt-injection are refused in deterministic code, human-only forever, so no email and no prompt can talk an agent into the loss. That is what lets a fleet of MCP agents run the inbox's work — triage, the Right Now lane, commitment tracking, drafting — while the one irreversible seat stays with the human by construction.

Q: Can I run a one-person company where MCP agents handle email? What's the catch with the inbox?
A: You can delegate a lot of the inbox — triage, the Right Now lane, commitment tracking, drafting — and RadMail is built exactly for that: its MCP server exposes only read, triage, search, explain, draft, and read-only diagnostic tools. The catch an agent-run inbox has to solve is the high-risk send: an autonomous process that can move money can be tricked into a wire, a banking change, or a cold reply to a stranger (the business-email-compromise playbook, now also a prompt-injection surface). RadMail solves it by refusing those actions in deterministic code — money, new banking, first contact, decisions, and injection are human-only, forever, by construction rather than by a policy an agent could be argued out of. So the agent fleet runs the inbox's work and the one irreversible seat stays yours.

Q: Can my agent watch an email thread and know who has the last word?
A: Yes — watched threads are live in the product. Mark a thread watched (in the inbox, or via the v1 API: POST /api/v1/threads/{id}/watch, API-key and scope gated) and RadMail tracks who spoke last. When the other side has the last word, the thread pins to the top of the Right Now lane; when you spoke last, it sits in a quiet Watching panel instead of nagging. Watched threads also carry a protected importance floor, so a watched conversation can never be tuned into silence.

Q: How does RadMail defend an agent-connected inbox against prompt injection?
A: Five layers. (1) The BEC hard-stop: money, changed banking, first contact, decisions, and suspected injection are refused in deterministic code, human-only forever. (2) Taint-marking: every real-mail field an agent sees is marked untrusted-email-body, so instructions inside an email body are treated as data. (3) Connected mode is read-only and fail-closed by construction. (4) A read-then-egress anomaly detector watches RadMail's egress routes — including the notify rail — for the tell-tale pattern of email content being read and immediately leaving; it detects and flags for human review, and never silently blocks legitimate mail. (5) As of radmail-mcp v0.5.0, the MCP server's tool descriptions are frozen under a sha256 manifest verified at startup — if any description drifts from the audited text, the server refuses to serve, a fail-closed defense against MCP tool-description poisoning.

Q: Can my agent ask a human a question through RadMail?
A: Yes — the notify rail. POST /api/v1/notify (API-key and scope gated) raises a request that rides RadMail's alert rail to a human, who answers in an in-app respond box; the caller polls GET /api/v1/notify/{id} and the loop closes with acked and responded states. It is a way to reach a human, never around one: nothing on this rail loosens the BEC hard-stop, and the read-then-egress anomaly detector watches this route too. A companion GET /api/v1/demand returns aggregates-only demand signals — tool names and event counts, never message content, arguments, or queries.

Q: How do I know whether RadMail's drafts are actually good?
A: RadMail measures it rather than asserting it: each draft an operator decides on is recorded with its outcome — sent unedited, edited before sending, or discarded. RadMail is pre-release and has not published acceptance rates yet; when it does, the numbers will come from this instrumentation, not from a marketing estimate.

Q: Does RadMail prepare a reply before I even open an important email?
A: Yes — RadMail has an answer-ready inbox. When an email lands that scores high or critical importance, or that the engine flags for human eyes, RadMail prepares the reply on arrival: by the time you open it, the alert has already fired, the importance level is known, and a draft is waiting pre-filled in the reply panel. The draft is human-approval-only and structurally cannot be auto-sent; money, changed banking, first contact, decisions, and suspected injection stay human behind the BEC hard-stop; drafting rides a bounded per-org daily AI budget; and the drafter's hard rules forbid payment-action promises and banking-detail echoes. Pre-release, rolling out behind a flag.

Q: Can my agent see how much work RadMail has done for a workspace?
A: Yes — GET /api/v1/usage returns a read-only work-units rollup (Bearer API key, read scope, available on the metered free tier). It reports how much WORK RadMail prepared over a window — reply drafts and lead-research dossiers counted as the headline work units, separately from the supporting triage the engine does behind the scenes — broken down by feature with call counts and engine cost. Query ?days= (default 30, max 90); the response is per-org aggregates only — counts and cost, never message content. It touches no billing or plan state; when metered tiers ship, these honest actuals become the left side of a quota. This is the north-star pillar ("the work is the meterable value") made programmatic; the same rollup renders in-app at /settings/usage.

## Compliance (honest framing)

Compliance is a SHARED RESPONSIBILITY. RadMail is a tool that supports your program;
it is NOT a compliance guarantee and does not by itself make any organization
compliant. For regulated tiers we sign a Business Associate Agreement (BAA) and
process on BAA-covered, audited infrastructure. Controls are SOC 2-aligned with an
audit planned. We do not claim to be HIPAA-certified, FedRAMP-authorized, or
SOC 2-certified. For HIPAA tenants, regulated sends are draft/ingest-only and
human-reviewed until production sending infrastructure is in place. RadMail makes no
medical claims.

## Links

- Site: https://radmail.ai
- Live product preview (the working inbox): https://app.radmail.ai
- Watch it work — public magic-moment, no signup: https://app.radmail.ai/pulse
- For agents / MCP connect: https://radmail.ai/for-agents
- MCP pointer manifest: https://radmail.ai/.well-known/mcp.json
- How it works (answers): https://radmail.ai/how-it-works
- Stop BEC / wire-fraud (what RadMail's firewall refuses): https://radmail.ai/stop-bec
- Connect Apple Mail (one command, every Mac inbox): https://radmail.ai/connect-apple-mail
- Lead lane (instant alert + dossier + approval draft): https://radmail.ai/lead-lane
- Answer-ready inbox (reply prepared on arrival, you approve): https://radmail.ai/answer-ready
- Real-inbox search (API key → agent searches your real mail, read-only): https://radmail.ai/real-inbox-search
- Email authentication standards (SPF/DKIM/DMARC/ARC/MTA-STS/DANE/BIMI): https://radmail.ai/standards
- DNS setup guides (Cloudflare, GoDaddy): https://radmail.ai/guides
- Waitlist / early access: https://radmail.ai/#waitlist