csitte/mailwarden

A reliable, **native** Gmail MCP server — full mailbox triage for AI assistants, with the feature no other Gmail MCP server ships: **mailbox-side snooze**.
Highlights
- **Snooze — the only *mailbox-side* snooze in a Gmail MCP server.** Archive a thread now, have it
resurface in the inbox on a date. Built on dated labels + a sweep, so it works from any client,
is visible in Gmail itself, and survives restarts. (Where another server offers a "snooze", it is
a local reminder list — the mail never leaves or re-enters the inbox.)
- **Search you can trust.** Gmail's threads.list — the call any thread search goes through — can
answer is:unread from a **stale thread-level read state**: measured in one real mailbox, **86% of
the threads it returned held no unread message at all**; in a second mailbox, no drift whatsoever.
You cannot tell which mailbox you are in without looking, so search re-verifies every hit against
its live labels. Paginated via pageToken/nextPageToken. (the measurements)
- **Sender authentication, not sender spelling.** get_thread reports the SPF/DKIM/DMARC results
the receiving server recorded, so "is this really from my bank?" is answered from the message's
own headers instead of from how the domain looks. It reads Gmail's own report only — the one
written under the id mx.google.com; a message can carry forged ones of its own — says whether a passing
DKIM signature belongs to the From domain, and says unchecked when nobody checked, because a
missing check is not a passing one.
- **Bulk operations that scale.** bulk_modify archives/labels everything matching a query at
1000 messages per API request — with per-chunk partial-success reporting instead of
all-or-nothing. The snooze sweep uses the same batch path.
- **Structured outputs.** Every tool declares an outputSchema and returns validated
structuredContent alongside fenced JSON text — no parsing guesswork for clients. Failures are
structured as well: a code and a retryable flag, so a client can tell "try again later" from
"re-authorize" without reading prose.
- **Small attack surface.** No send tools (no exfiltration path for prompt-injected mail),
optional read-only mode, no telemetry, no open ports by default, symlink-safe download fencing,
injection-fenced output. And no code path that *could* send: every Gmail request passes an egress
checkpoint that refuses messages.send, every draft endpoint, permanent deletion and forwarding
settings, whatever a compromised or careless caller asks for. **One deliberate exception:**
unsubscribe / bulk_unsubscribe (manage tier) contact the opt-out endpoint named in a message's
own header — the only non-Google host mailwarden ever reaches, and a read-tier deployment makes
no outbound request at all. Details under
Security & privacy and
Unsubscribing.
- **Correct with real-world mail.** RFC 2047 headers decoded (=?UTF-8?B?…?= → readable text),
bodies decoded in their *declared* charset (no mojibake for ISO-8859-1/Shift_JIS mail),
429/5xx retried with exponential backoff.
Why
Connectors that sync or cache your mailbox can lag behind it — and even Gmail's own search index is sometimes loose (see below). mailwarden talks straight to the live Gmail API (no cached snapshot) and re-verifies what the index returns, so what you see is what's actually there. It's a generic Gmail capability layer — keep your own rules/logic in your AI client, not in the server.
search goes one step further than the raw API: Gmail's threads.list index can answer read-state operators from a **stale copy** of that state, so is:unread returns threads you finished reading weeks ago — in one measured mailbox, the large majority of what came back. Since every hit is fetched live anyway, search re-checks the unambiguous predicates (is:unread/is:read/is:starred/in:inbox/category:…, with negation) against each thread's true labels and drops the index's false positives.
Compared to other Gmail MCP servers
Most Gmail MCP servers cover the same read/label/send surface. Two capabilities are still unique to mailwarden as far as we have looked (mailbox-side snooze, search re-verification), and one deliberate omission is a security feature, not a gap. A third, sender authentication, was unique when it shipped and no longer is: @agentcomms/gmail-mcp has read Authentication-Results since 18 September 2026, trusting only the report whose authserv-id is mx.google.com. It has its own column below since 13 October 2026. Google's own server is also narrower than it looks: draft-only, and no trash, filters or unsubscribe.