Your agent gets email. It does not get your account.

Four ways an agent ruins your week

Each one has a guardrail, and each guardrail refuses at the API rather than reporting afterwards. The failure is named first because the guardrail only makes sense once you have pictured it.

• When

  The agent sends to a real customer from a staging run

  What stops it

  A recipient allowlist on the key. Anything outside it is refused at the API before it reaches the queue — not filtered later, not logged and delivered anyway.

  JSON

  Copy

  {
    "error": "recipient_not_allowlisted",
    "message": "Key allowlist is [@yourcompany.com]. Recipient is outside it.",
    "docs": "https://www.sadasend.com/docs/errors#recipient_not_allowlisted"
  }

• When

  The agent loops and sends four thousand of something

  What stops it

  Approval mode. Every send from that key lands in pending_approval instead of the queue, and waits for a human. Off by default, on for anything an agent holds.

  HTTP

  Copy

  POST /emails
  { "to": [ … 4,812 recipients … ] }
  
  202 Accepted
  { "id": "26abdd24-…", "status": "pending_approval" }

• When

  The agent decides it needs a better key

  What stops it

  It cannot make one. There is no create_api_key tool, no delete_domain, no remove_suppression. They are absent from the server rather than gated behind a scope, because a scope is a thing an agent can be talked into asking for.

  HTTP

  Copy

  tools/call → create_api_key
  
  { "error": { "code": -32601, "message": "Unknown tool" } }

• When

  You want to know what it would have sent

  What stops it

  Dry run (dry_run: true). The message is validated, rendered and checked against your suppression list, and you get back exactly what would have gone out. Nothing is queued and no mailbox is touched.

  JSON

  Copy

  { "from": "…", "to": "…", "subject": "…", "dry_run": true }
  
  { "id": "…", "status": "queued", "dryRun": true, "rendered": { … } }

A key is a job, not an identity

Scopes, a rate limit, an allowlist and a mode are set when the key is minted and cannot be widened by whoever holds it. An agent gets a key that sends and reads. It never gets one that can mint another.

Scopes

send · read · domains. Fixed at creation — widening means minting a new key in the dashboard.

Rate limit

Per key, not per account. A runaway agent cannot spend the quota your product needs.

Recipient allowlist

Addresses or whole domains. Refused at the API, before the queue.

Mode

live · approval · test. Approval holds every send for a human decision.

The 10 tools, and their scopes

Filtered by the key’s scopes, so an agent is offered only what its key can already do — a tool it cannot call is not a tool it should be able to see.

Things people actually ask their agent

• Send the welcome email to the three users who signed up this morning.
• Why did our password reset to dana@example.com bounce yesterday?
• Check whether our DNS is set up correctly for sending.
• Show me every email that bounced this week, grouped by reason.

Questions

What is an MCP server, and why does it matter for email?

Model Context Protocol is how an AI agent discovers and calls tools. An email MCP server is what lets an agent send mail without you writing an integration. It matters because the server decides what the agent can do — and most of them expose the entire platform API, which means the agent can do anything you can.

How is this different from giving an agent an API key?

A normal API key is your account. Ours carries a scope set, its own rate limit, an optional recipient allowlist and an optional approval mode, all fixed when the key is minted. The agent holds a key that can do one job, and cannot widen it — asking nicely is not a privilege escalation path.

Can the agent remove someone from the suppression list?

No. There is no tool for it, and there is no scope that adds one. Un-suppressing an address that complained is how a sending reputation is destroyed, so it is a dashboard action with a human present. The same applies to minting API keys and deleting domains.

What happens to a send that is held for approval?

It is accepted and given an id, with status pending_approval, and it is deliberately not enqueued. It sits until someone approves or rejects it from the dashboard or over the API. Nothing expires it and nothing sends it by accident — the reconciliation sweep that resurrects lost messages only ever looks at queued.

Do I need the paid plan for any of this?

No. Every guardrail and all ten MCP tools are on the free plan. A ceiling that only paying customers can see is a ceiling nobody evaluates, and this is the part of the product worth evaluating.

Which agent frameworks work with it?

Any MCP client. It is a hosted streamable HTTP server with bearer authentication, so Claude Code, Claude Desktop, Cursor and anything else speaking MCP connect with a URL and a key — there is nothing to install and nothing to run locally.