MCP field guide / Gmail
// mcp field guide · email
The purest "gate before commit" case — and a great natural experiment. Google's official server is deliberately draft-only: it can't send or delete, so it structurally cannot take an irreversible action. The popular community server does send immediately and permanently deletes. A sent email can't be unsent; the design choice each server made is the lesson.
GUARD FIT · READS + DRAFTS
PASS-THROUGHSearch/read email, manage labels, and draft messages are safe — a draft is the natural human-review point.
GUARD FIT · SEND + PERMANENT DELETE
STRONGsend_email delivers instantly with no unsend; delete_email hard-deletes (bypasses Trash). Both irreversible.
Overall fit: STRONG on the community server's send/delete; the official draft-only server needs no send gate — it can't send.
Official — Google Gmail MCP (hosted, Developer Preview). Draft-only: it exposes create_draft, label tools, and reads — but no send and no delete tool at all. By construction it cannot perform an irreversible action; the human converts draft → sent in the Gmail UI.1 Community — GongRzhe "Gmail AutoAuth MCP" (@gongrzhe/server-gmail-autoauth-mcp, local, ~1.2k stars) is full-surface — it sends and permanently deletes. Note: the original repo is archived (last push 2025-08-06), with maintenance moved to a fork.2
| Tier | Tools |
|---|---|
| read-only | read_email, search_emails, list_email_labels, list_filters, get_filter, download_attachment (local file write) |
| mutating (reversible) | draft_email (unsent — safe), modify_email (labels; the TRASH label = recoverable), batch_modify_emails, create_label/update_label/delete_label, create_filter/delete_filter |
| irreversible | send_email (delivered instantly, no unsend), delete_email (permanent hard-delete, bypasses Trash), batch_delete_emails (permanent, multiple at once) |
Draft vs. send is the key line. create_draft/draft_email only stage a message a human can review — safe. send_email crosses into the external world irreversibly. And delete_email/batch_delete_emails are permanent Gmail deletes (they bypass the recoverable 30-day Trash), not the reversible trash-via-label. Treat any send/permanent-delete tool as irreversible; the draft twins as safe.
Inbox triage. search_emails + read_email to summarize unread mail — read-only, safe to automate.
Assisted reply. Compose with draft_email/create_draft for the human to review and send (exactly what Google's official server is built for).
Outbound automation. Send notifications/follow-ups via send_email — the high-stakes case.
Send → strong; this is the literal compensation-is-not-undo case. A sent email leaves the boundary the instant send_email returns — it lands in an external mailbox, Gmail offers no programmatic recall, and no compensation tool can retrieve it. There is nothing to "roll back"; the honest report is irreversible: delivered. Gate send_email with a diff (recipients, subject, body) before commit.
Permanent delete → strong. delete_email/batch_delete_emails bypass Trash, so they're equally irreversible; batch delete especially warrants confirming exactly which/how many messages.
Reads and drafts → pass through. Drafts are the safe pressure-release valve: the agent composes freely, the human converts draft → sent (the natural approval point). Label edits and trash-via-label are reversible — log, don't block.
The design lesson: Google's official server needs no send gate because it structurally cannot send — a real-world confirmation of the principle "make the irreversible action unavailable, or gate it." When you must keep send enabled (the community server), the gate goes exactly there. See human-in-the-loop for MCP tool calls.
ChronoMCP holds send_email and permanent deletes for a human — flagged as irreversible — while reads and drafts flow through.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Google, and the community server is an independent project (its original repo is archived). Tool names are quoted from each server's docs. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.