Give an agent an inbox, safely

01The nine tools an agent gets

Nine tools is a decision, not an accident. An MCP server that mirrors every REST endpoint hands a model a hundred near-identical choices and it picks wrong; these are the nine things an assistant actually needs to do with a mail account, and each one is a whole job rather than a step in one.

That asymmetry is what the gate exists for — not a general nervousness about agents. “Write” is doing two different jobs in that column, and only one of them is worth interrupting a person for.

02The two tools that need a human

Call send_email and nothing is sent. What comes back is not an error, not a refusal, and not a permission problem — it is a confirmation_required result, which is a perfectly normal outcome of a successful tool call.

That the first call is a success is load-bearing. If it returned an error, a capable agent would do what capable agents do with errors: adjust something and retry, possibly in a loop, possibly with increasingly creative arguments. Returning a success whose content is “here is the confirmation you now need” tells the agent the call worked and the next step belongs to somebody else.

{
  "status": "confirmation_required",
  "confirmation": {
    "token": "cnf_…",                    // single-use, bound to this exact call
    "approved": false,
    "expires_at": "2026-09-11T14:22:31Z",   // ten minutes by default
    "approval_channel": "https://…/app/approvals",
    "summary": { /* from, to, cc, subject, preview, attachments */ }
  }
}

The text half of the result is written for the model to relay, and it says plainly: this call did not send anything, a person must approve it, you cannot approve it yourself, and repeating this call will not send it. The structured half carries the full summary — sender, recipients, subject, body preview, attachment count, schedule — so the person deciding sees the actual message rather than a tool name and a shrug.

The ten-minute expiry is deliberately short, and the API says why when you try to use a stale one: a stale approval is an approval for a message nobody remembers. Approving something at nine in the morning and having it go out at four in the afternoon is not consent, it is a delayed surprise. The token's nonce is also the idempotency key for the send itself, so a spent token cannot become a second message.

03Why an agent cannot approve its own send

Here is the claim worth being precise about. An agent cannot approve its own send. Not because it lacks a permission, and not because a check rejects it — because the operation is not in the protocol it is speaking.

And tools/call is not a way in, because the nine tools are the nine listed above and none of them decides a confirmation. The object that can mark a confirmation approved is reachable only by the process that constructed the server: the dashboard route, behind a session, behind a role check. Nothing on the JSON-RPC surface can address it.

This is the only useful way to think about prompt injection: not as something to be filtered out of the input, which is an arms race against natural language, but as something that must be unable to cause the action you care about even when it works. Persuading the model is the easy part. Persuading a protocol to grow a method is not a thing that persuasion does.

The system prompt the server hands every client says the same thing in the model's own register: the two sending tools never send on their first call, there is no tool, method or argument that approves a confirmation, so do not look for one and do not retry in a loop — report the pending confirmation and wait. That instruction exists to save the agent from wasting its turn, not to keep it honest. The keeping-honest is done by the method table.

04Connecting an agent

Your instance exposes MCP at /mcp. The credential is an ordinary API key in an Authorization header, which means everything from the keys guide applies unchanged — including which permission you hand over.

{
  "mcpServers": {
    "mailysend": {
      "url": "https://your-instance.example.com/mcp",
      "headers": { "Authorization": "Bearer ms_live_…" }
    }
  }
}

05Running an agent inbox in production

The technical half of this is done. What is left is the operational half, and it is where agent inboxes actually go wrong — not with a dramatic breach, but with a queue nobody reads and a habit of clicking approve.

The failure mode to name out loud is the rubber stamp. Twenty confirmations a day, all of them fine, and by the second week approving is muscle memory. The twenty-first is the one that matters and it looks exactly like the others in the list — which is why it matters that the summary shows the recipients and the body rather than “send_email (1)”. If your queue has become too long to read properly, the honest fix is to give the agent less to do, or to move a genuinely routine category behind a template it cannot vary, rather than to keep approving faster.

Finally, the thing to review monthly rather than never: whether the agent still needs full_access. Most agents are given it during setup because the read tools need it, and most never have their scope narrowed afterwards. If yours has settled into only replying to threads, a sending_access key does that job. The keys guide has the rotation order for swapping one credential for the other without a gap.

Common questions