Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

io.github.csitte/mailwarden

NPM · MAILWARDEN · SCANNED SEP 20

Gmail MCP server for email triage: search, labels, archive, trash, unsubscribe, snooze.

Available components

−14 this week 75 Trust /100
Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security48
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • No install/post-install scripts declared.Pass
  • 42 of 121 dependencies flagged as unhealthy (1 deprecated). View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to csitte/mailwarden). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 2 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability59
  • AI-judged instruction clarity (good).Pass
  • Context-footprint check failed: tool/resource definitions use about 5960 tokens (~229/item across 26 items; 26 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
  • No destabilizing schema changes in the last 30 days.Pass
Tool Coverage71
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 27 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Install

How do I install the io.github.csitte/mailwarden MCP server?

io.github.csitte/mailwarden runs locally as an npm package, launched with npx -y mailwarden. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

npm · mailwarden

# add to Claude Code
claude mcp add csitte-mailwarden -- npx -y mailwarden
// .cursor/mcp.json
{
  "mcpServers": {
    "csitte-mailwarden": {
      "command": "npx",
      "args": [
        "-y",
        "mailwarden"
      ]
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "csitte-mailwarden": {
      "command": "npx",
      "args": [
        "-y",
        "mailwarden"
      ]
    }
  }
}
# add to Codex CLI
codex mcp add csitte-mailwarden -- npx -y mailwarden
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "csitte-mailwarden": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "mailwarden"
      ],
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add csitte-mailwarden --command npx --arg -y --arg mailwarden
# ~/.hermes/config.yaml
mcp_servers:
  csitte-mailwarden:
    command: "npx"
    args: ["-y", "mailwarden"]
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "csitte-mailwarden": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "mailwarden"
      ]
    }
  }
}
# add to Vellum
assistant mcp add csitte-mailwarden -t stdio -c npx -a -y mailwarden
// mcp.json
{
  "mcpServers": {
    "csitte-mailwarden": {
      "command": "npx",
      "args": [
        "-y",
        "mailwarden"
      ]
    }
  }
}
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 20 Sept 26 +1
    • Stability: 0.97 → pass security
  • 19 Sept 26 −1
    • Stability: pass → 0.97 functional
  • 18 Sept 26 +1
    • Stability: 0.97 → pass security
  • 17 Sept 26 −16
    • Malware scan: pass → unverified security
    • Stability: pass → 0.97 functional
    • Package version: 0.21.0 → 0.22.0 functional
  • 15 Sept 26 +15
    • Malware scan: unverified → pass security
  • 14 Sept 26 −14
    • Malware scan: pass → unverified security
    • Stability: 0.97 → unverified security
    • Tool safety: pass → unverified security
    • Known CVEs: partial → pass security
    • Stability: 0.97 → pass security
    • Capabilities: pass → unverified functional
    • Tool coverage: 100 → unverified functional
    • Dependency health: partial → 0.83 functional
    • Package version: 0.20.0 → 0.21.0 functional
  • 13 Sept 26 −1
    • Stability: pass → 0.97 functional
  • 12 Sept 26 +16
    • Malware scan: unverified → pass security
    • Stability: 0.97 → pass security
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 20 Sept 2026 · Analysed npm/mailwarden@0.22.0

Provenance Verified

A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.

Result Verified
Ecosystem npm
Reason Verified
Discovered via Registry attestation endpoint
Source repo csitte/mailwarden
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/csitte/mailwarden/.github/workflows/publish.yml@refs/tags/v0.22.0
Rekor log index 2880052152
Predicate type https://slsa.dev/provenance/v1
Subject digest sha512:188fc501caf642af221e6acab4c142fd41c67f52a1804829542f284e562dcf82470584493ce608007400e1c07a5c0bb29262713f7d701dc317d1747cc

Background: How many MCP packages publish verified provenance →

Dependencies 121 packages
Packages resolved 121
Deprecated 1
Stale 41
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 26 exposed · ~5,712 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
archive ~80

Archive a thread (remove it from the inbox). USE WHEN: inbox triage — the thread is handled and should leave the inbox. DO NOT USE: to delete (use trash) or to defer to a date (use snooze). SIDE EFFECTS: thread leaves the inbox; reversible via modify_labels add INBOX.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

bulk_modify ~789

Bulk-apply label changes to every message matching a Gmail query, batched at 1000 messages per API request. Labels may be given by name or by id: an unknown name in `add` is created automatically (use '/' for nested labels), an unknown name in `remove` is ignored. Returns matched/submitted counts, matched and submitted thread IDs (both lists capped at 500 — matchedThreadCount/submittedThreadCount hold the true totals), and per-chunk failures (partial success is reported, not hidden). IMPORTANT: `submittedMessages` is how many ids were handed to the API, NOT how many messages changed — `messages.batchModify` answers 204 with no body and ignores ids it does not recognise without a word, so an accepted request is not a performed one. Set verify:true to read the labels back afterwards and get `verified` {applied, notApplied[], unverifiable[]} — the only field here that reports an observed outcome. It costs one extra read per affected thread, so it is off by default; use it when a wrong 'done' would be acted on (trashing, or anything the user is told completed). If more messages match than maxMessages, only the first maxMessages are processed and 'capped' is true — raise maxMessages or re-run to finish the rest. NOTE: the query hits Gmail's search index as-is, WITHOUT the live re-verification search performs. The staleness that makes search re-verify was measured on `threads.list` (132 threads returned, 114 carrying no unread message at all); the same query through the message index this tool uses returned 19 hits, none stale — same mailbox, same minute. So the known drift does not reach this path, but that is one measurement, not a guarantee: `unverifiedPredicates` in the result names the conditions taken on the index's word, and when the outcome must be read-state-precise, resolve the set with search (which verifies against live labels) and act on those thread ids instead. Set crossCheck:true to ask Gmail the same question a second way before writing: each derived pre…

NameTypeReqDescription
addarray
crossCheckboolean
dryRunboolean
maxMessagesinteger
querystringyes
removearray
verifyboolean
NameTypeReqDescription
cappedbooleanyes
crossCheckedobject
dryRunbooleanyes
failedarrayyes
labelsToCreatearray
matchedMessagesnumberyes
matchedThreadCountnumberyes
matchedThreadsarrayyes
submittedMessagesnumberyes
submittedThreadCountnumberyes
submittedThreadsarrayyes
unverifiedPredicatesarrayyes
verifiedobject

No examples provided.

bulk_unsubscribe ~415

Unsubscribe from several mailing lists in one call, one thread id per list. Threads are processed SEQUENTIALLY, and at most ONE request is made per sender — a second thread from a sender whose request already went out is reported with `duplicateOf` and no request (and says so when it advertises a DIFFERENT endpoint, i.e. is probably a separate list from the same sender). The whole call shares a 60-second budget; threads left over when it runs out come back with `skippedOutOfTime` and a reason, so re-running with the remaining ids finishes the job. Like unsubscribe, there is no URL parameter: every endpoint comes from that thread's own List-Unsubscribe header. Only RFC 8058 one-click senders are contacted; the rest come back with their alternatives in `options`. Partial success is reported, never hidden: a thread that cannot be read or whose endpoint fails becomes an entry with a `reason`, and the remaining threads still run. Set dryRun:true to rehearse: same header reads, same per-sender dedupe (as a real run with every request succeeding), and each entry a real run would contact reports the endpoint it `wouldCall`; refusals and duplicates carry none — and nobody is contacted. USE WHEN: clearing out several newsletters at once — pair with list_subscriptions, which gives you the sender rows and their newestThreadId; dryRun first to show the user which senders would be contacted. DO NOT USE: for one thread (use unsubscribe), or to find candidates (use list_subscriptions — it contacts nobody). SIDE EFFECTS: up to one outbound HTTPS request per DISTINCT sender (plus up to 3 redirects each) — the only non-Google hosts mailwarden ever contacts (none with dryRun). Each confirms to that sender that the address is live, and none of it can be undone. The mailbox itself is not changed.

NameTypeReqDescription
dryRunboolean
threadIdsarrayyes
NameTypeReqDescription
attemptednumberyes
dryRunbooleanyes
requestednumberyes
requestsnumberyes
resultsarrayyes
skippedDuplicatesnumberyes
skippedOutOfTimenumberyes
unsubscribednumberyes

No examples provided.

create_filter ~480

Create a Gmail filter: matching incoming mail automatically gets the given label actions. Give at least one criterion and at least one action. Actions are label add/remove only (labels by name or id; an unknown name in addLabels is auto-created). Common recipes: skip the inbox → removeLabels ['INBOX']; auto-mark-read → removeLabels ['UNREAD']; auto-trash → addLabels ['TRASH']; star → addLabels ['STARRED']; file under a label → addLabels ['Receipts']. A filter only affects mail arriving AFTER it's created; set applyToExisting:true to ALSO apply the same actions once to mail already in the mailbox (builds a Gmail search from the criteria and runs a bulk modify — same unverified-index caveat as bulk_modify — the sweep acts on what the index returns, which can be badly stale on read state; up to maxMessages, default 1000). The sweep's `applied.submittedMessages` is how many ids were handed to the API, NOT how many messages changed; set verify:true alongside applyToExisting to read the labels back afterwards and get `applied.verified` {applied, notApplied[], unverifiable[]}. It costs one extra read per affected thread, so it is off by default; a read-back that fails lands in `unverifiable` and never fails the call — the filter stands either way. USE WHEN: setting up a persistent auto-triage rule (e.g. 'always archive + label newsletters from x'), optionally cleaning up the existing backlog too. NOTE: forwarding filters are intentionally not supported — mailwarden creates no send/exfiltration path. SIDE EFFECTS: adds a server-side rule affecting future mail (reversible via delete_filter); with applyToExisting also modifies existing messages. Requires gmail.settings.basic.

NameTypeReqDescription
addLabelsarray
applyToExistingboolean
excludeChatsboolean
fromstring
hasAttachmentboolean
maxMessagesinteger
negatedQuerystring
querystring
removeLabelsarray
sizeinteger
sizeComparisonstring
subjectstring
tostring
verifyboolean
NameTypeReqDescription
addLabelIdsarrayyes
appliedyes
criteriaobjectyes
forwardstring
idstringyes
removeLabelIdsarrayyes

No examples provided.

create_label ~265

Create a user label and return its id. Idempotent: if the name already exists (case-insensitive), its existing id is returned and nothing is created. Nested labels: separate levels with '/' (e.g. 'Clients/Acme') — each missing parent level is created too. Colour: pass backgroundColor AND textColor together as '#rrggbb' (Gmail rejects one without the other, and accepts only colours from its own palette). Giving a colour for a label that already exists RECOLOURS it — that is how an existing label, such as the snooze label, gets a colour. Gmail colours only labels you created yourself; system labels like INBOX or CATEGORY_UPDATES refuse one. USE WHEN: you want a label's id up front, to pre-create a label without applying it to anything, or to make an existing label visible at a glance in Gmail. DO NOT USE: just to file mail under a new label — modify_labels/bulk_modify already auto-create an unknown name passed in `add`. SIDE EFFECTS: creates the label if missing, and sets its colour when one is given; no mail is changed.

NameTypeReqDescription
backgroundColorstring
namestringyes
textColorstring
NameTypeReqDescription
colorobject
idstringyes
namestringyes

No examples provided.

delete_filter ~65

Delete a Gmail filter by id (get ids from list_filters). USE WHEN: removing an auto-triage rule. SIDE EFFECTS: removes the server-side rule; future mail is no longer auto-processed by it. Requires gmail.settings.basic.

NameTypeReqDescription
idstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

download_attachment ~127

Download an attachment to a local file path. If MAILWARDEN_DOWNLOAD_DIR is set, destPath is resolved inside (and restricted to) that directory. USE WHEN: the user wants an attachment saved to disk (IDs come from get_thread's attachment metadata). SIDE EFFECTS: writes a local file; never overwrites — an existing file gets a numeric suffix (file-1.pdf). The response's 'saved' field is the path actually used. Mailbox unchanged.

NameTypeReqDescription
attachmentIdstringyes
destPathstringyes
messageIdstringyes
NameTypeReqDescription
savedstringyes

No examples provided.

get_profile ~70

Return the authorized account: email address plus total message/thread counts. USE WHEN: confirming WHICH mailbox is connected before a bulk or filter action, or as a cheap liveness check. DO NOT USE: to enumerate messages — this returns only counts, not a listing (use search). SIDE EFFECTS: none.

Input schema present but exposes no named parameters.

NameTypeReqDescription
emailAddressstringyes
historyIdstringyes
messagesTotalnumberyes
threadsTotalnumberyes

No examples provided.

get_thread ~583

Fetch a thread by ID: headers, plaintext + HTML bodies, and attachment metadata. `full` defaults to true and should stay true whenever content matters. `full: false` is a headers-and-labels fetch for when a thread is too large to read or only its metadata is of interest — it does NOT fetch bodies or attachment metadata, and the result then omits `plaintextBody`, `htmlBody` and `attachments` entirely and sets `metadataOnly: true`. The fields are omitted rather than empty on purpose: an empty attachment list from a request that never looked is indistinguishable from a message that truly has none, and treating it as 'no attachment' has already nearly caused an invoice to be archived as attachment-less. If `search` reported `hasAttachments: true`, or the sender matters, use full: true. EVERY MESSAGE CARRIES `authentication` — SPF/DKIM/DMARC as the RECEIVING server reported them, for answering 'is this mail really from who it says?'. Read `dmarc` first: it is the only one of the three that ties a passing check to the visible `From` domain, so `spf: pass` alone proves nothing about the sender the user sees (a lookalike domain gets that trivially). `signedBy`/`mailedBy`/`headerFrom` name the domains each check actually validated. They do NOT have to match each other or the `From` address, and a mismatch is not by itself suspicious: a forwarded message legitimately shows the forwarder in `mailedBy` (the envelope sender is rewritten in transit) and in `signedBy` (the forwarder signs with its own key), while only `headerFrom` still names the original sender — which is exactly why `dmarc` is the result that carries meaning. Read those three as the explanation of a result, not as a test of their own. `authservId` says WHO asserts all this: a message can carry forged Authentication-Results headers of its own, and only the receiving server's report (for Gmail, `mx.google.com`) counts; `otherReports` counts further reports that were NOT read, and `alsoReported` lists results that…

NameTypeReqDescription
fullboolean
threadIdstringyes
NameTypeReqDescription
messagesarrayyes
metadataOnlyboolean
threadIdstringyes

No examples provided.

list_filters ~97

List all Gmail filters — the server-side rules that auto-apply label actions to incoming mail. Shows each filter's criteria and label actions, and (for auditing) any `forward` address an existing filter carries. USE WHEN: reviewing existing automation, or to get a filter's id before delete_filter. SIDE EFFECTS: none. Requires the gmail.settings.basic scope — re-run `mailwarden --auth` if you authorized an earlier version.

Input schema present but exposes no named parameters.

NameTypeReqDescription
filtersarrayyes

No examples provided.

list_labels ~63

List all Gmail labels (system + user). USE WHEN: inspecting the mailbox structure, or to get exact label names/ids — though modify_labels/bulk_modify/create_label all accept a plain label name directly, so a lookup is rarely required. SIDE EFFECTS: none.

Input schema present but exposes no named parameters.

NameTypeReqDescription
labelsarrayyes

No examples provided.

list_snoozed ~28

List all snoozed threads with their due dates. SIDE EFFECTS: none.

Input schema present but exposes no named parameters.

NameTypeReqDescription
snoozedarrayyes

No examples provided.

list_subscriptions ~355

Who keeps writing, how often, and whether you can get off the list — a mailbox slice grouped by SENDER, each row carrying its opt-out options. Contacts nobody: opt-out options come from the List-Unsubscribe header of each sender's newest thread (one metadata fetch per sender, not per thread). `optOut` is 'one-click' (the unsubscribe tool can perform it), 'link' (a human opens it in a browser), 'mailto' (would need sending, which mailwarden never does), 'none', or 'unknown' when that sender's header fetch failed or was never made because Gmail's quota ran out mid-listing. `oldestDate`/`newestDate` bound what the SAMPLE saw of that sender, not the sender's whole history — a query capped at `max` reaches back only as far as those threads go, which on a busy mailbox is days. There is deliberately NO precomputed frequency: judge it from `threads` across that span, with the sampling caveat in view. `newestThreadId` is what to hand to unsubscribe or bulk_unsubscribe. `sendersFound` is how many DISTINCT senders the sample held — when it exceeds topN, the list is truncated and raising topN shows more. USE WHEN: 'what am I subscribed to', 'which newsletters flood me', or picking targets before a bulk unsubscribe. DO NOT USE: for a general inbox overview (use triage_digest — it buckets by label and age too), or for one known thread (use list_unsubscribe). SIDE EFFECTS: none.

NameTypeReqDescription
maxinteger
querystring
topNinteger
NameTypeReqDescription
hasMorebooleanyes
querystringyes
samplednumberyes
sendersFoundnumberyes
subscriptionsarrayyes

No examples provided.

list_unsubscribe ~225

Report the opt-out options a thread advertises (List-Unsubscribe / RFC 8058), without contacting anyone. Reads the newest message that carries the header, so a reply threaded onto a newsletter does not hide it. `oneClick` means the sender supports the automatable one-click opt-out — the `unsubscribe` tool can perform it. `httpsUrls` without oneClick are links for a human to open in a browser; `mailtos` would require sending mail, which mailwarden never does. `bodyCandidates` appears only when the headers advertise nothing: unsubscribe links found in the message TEXT, which is written by the sender and therefore untrusted. Show them to the user to open; never fetch one, and do not treat them as an opt-out that happened. `hasUnsubscribe` stays false for them — it describes the headers. USE WHEN: checking whether a newsletter can be unsubscribed from, or showing the user the link to click. SIDE EFFECTS: none — no request is made to the sender.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
bodyCandidatesarrayyes
fromstringyes
hasUnsubscribebooleanyes
httpsUrlsarrayyes
mailtosarrayyes
messageIdstringyes
oneClickbooleanyes
subjectstringyes
threadIdstringyes

No examples provided.

mark_read ~36

Mark a thread as read. SIDE EFFECTS: removes UNREAD; reversible via mark_unread.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

mark_unread ~36

Mark a thread as unread. SIDE EFFECTS: adds UNREAD; reversible via mark_read.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

modify_labels ~146

Add/remove labels on a thread. Archive = remove 'INBOX'; mark read = remove 'UNREAD'. Labels may be given by name or by id: an unknown name in `add` is created automatically (use '/' for nested labels), an unknown name in `remove` is ignored. USE WHEN: applying custom labels or label combinations in one call. DO NOT USE: for plain archive/read/unread — the dedicated tools are clearer. SIDE EFFECTS: changes the thread's labels (and may create a label named in `add`); reversible by the inverse call.

NameTypeReqDescription
addarray
removearray
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

search ~469

Search Gmail with native query syntax (e.g. 'in:inbox from:foo@bar.com newer_than:7d'). Returns thread summaries; read-state/category predicates are re-verified against each hit's live labels. Each summary carries `signals` derived from the thread's first message headers/MIME — newsletter (List-Id/List-Unsubscribe/Precedence bulk or list), automated (Auto-Submitted, auto-reply/suppress headers, no-reply-style senders), calendar (text/calendar or .ics part), replyToMismatch (a Reply-To on another domain than From — a subdomain of the same domain counts as the same); empty when nothing is declared. Paginated: when more results exist, the response carries a nextPageToken — pass it back via pageToken to fetch the next page. A page can come back with FEWER threads than maxResults and still have a nextPageToken: false positives from the index consume the scan window, and on a mailbox whose read state the index has fallen behind on, most candidates for an is:unread query can be already-read mail. A short page is therefore not evidence that the result set is exhausted — only an absent nextPageToken is. SPAM AND TRASH ARE EXCLUDED unless the query names them. Gmail leaves both out of any query that does not say `in:spam` / `in:trash`, so a plain `from:someone` returns nothing for a mail that is sitting in spam — measured against a live mailbox, not assumed. Nothing in the result marks the omission, so treat 'no hits' as 'none outside spam and trash'. When mail the user expects is missing, retry with `in:spam` before reporting that it does not exist: mail is often filed as spam because of something the user just did — a signup, a password reset, an order confirmation — which is precisely what a spam filter cannot know and the caller often can. USE WHEN: locating threads by sender, subject, date, label, or read state. DO NOT USE: to fetch a thread you already have the ID of (use get_thread). SIDE EFFECTS: none.

NameTypeReqDescription
maxResultsinteger
pageTokenstring
querystringyes
NameTypeReqDescription
nextPageTokenstring
threadsarrayyes

No examples provided.

snooze ~229

Snooze a thread until a date or time: archives it now, resurfaces when it comes due and sweep_snoozed runs. `until` accepts an explicit date (YYYY-MM-DD), a date+time (YYYY-MM-DD HH:MM or e.g. '2026-06-20 9am'), OR a preset resolved server-side: today, tomorrow, weekend (next Saturday), next week (next Monday), a weekday name (monday–sunday, next occurrence), 'in N days', or 'in N hours'. A preset may carry a trailing time ('tomorrow 9am', 'monday 8:30'). A timed snooze wakes at the next sweep on/after that minute. USE WHEN: deferring a thread to a later date/time instead of leaving it in the inbox. DO NOT USE: for permanent removal (use archive or trash). SIDE EFFECTS: removes INBOX, adds a dated MCP/Snoozed label; reversible via unsnooze.

NameTypeReqDescription
threadIdstringyes
untilstringyes
NameTypeReqDescription
snoozedUntilstringyes
threadIdstringyes

No examples provided.

sweep_snoozed ~180

Resurface all snoozed threads whose date is due (<= today), batched at 1000 messages per API request. Set dryRun:true to rehearse: reports the due labels and threads (dueLabels/dueThreads) as the sweep would find them (from the live label listing; a single snooze label with more than 5000 messages is under-counted in the rehearsal), and wakes nothing. USE WHEN: the user asks to process due snoozes, or as a scheduled maintenance call; dryRun to answer 'what is due right now?' without acting. SIDE EFFECTS: due threads return to the inbox marked unread (none with dryRun); safe to run repeatedly. failedCount/errors report messages a batch could not wake (their label is kept for the next sweep).

NameTypeReqDescription
dryRunboolean
NameTypeReqDescription
datestringyes
dryRunbooleanyes
dueLabelsarrayyes
dueThreadCountnumberyes
dueThreadsarrayyes
errorsarrayyes
failedCountnumberyes
wokenarrayyes
wokenCountnumberyes

No examples provided.

trash ~70

Move a thread to Trash. USE WHEN: the thread should be discarded. DO NOT USE: for inbox cleanup of mail worth keeping (use archive). SIDE EFFECTS: thread moves to Trash; recoverable via untrash for ~30 days, then Gmail deletes it permanently.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

triage_digest ~181

Structured overview of a mailbox slice for triage DECISIONS — sender / label / age buckets, unread and attachment counts, and header-derived signals (newsletter / automated / calendar / replyToMismatch — thread counts overall, and per sender the set of signals its threads carry), instead of a raw thread list. USE WHEN: deciding what to bulk-archive/snooze/label, or summarizing inbox state ('what's in my inbox?'). DO NOT USE: to read a specific thread (use search/get_thread). Samples up to `max` most-recent matches; hasMore flags that more matched than were sampled. byAge buckets by each thread's FIRST message date (thread age, not last activity). SIDE EFFECTS: none.

NameTypeReqDescription
maxinteger
querystring
topNinteger
NameTypeReqDescription
byAgeobjectyes
hasMorebooleanyes
querystringyes
samplednumberyes
signalsobjectyes
topLabelsarrayyes
topSendersarrayyes
unreadnumberyes
withAttachmentsnumberyes

No examples provided.

unsnooze ~44

Cancel a snooze: return the thread to the inbox now. SIDE EFFECTS: removes the snooze label, restores INBOX.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
threadIdstringyes
unsnoozedbooleanyes

No examples provided.

unsubscribe ~291

Unsubscribe from the mailing list a thread came from, via the sender's RFC 8058 one-click endpoint. There is deliberately no URL parameter: the endpoint is taken from the message's own List-Unsubscribe header and nowhere else. Only https one-click endpoints are called (fixed request body, response body discarded); a plain link is reported for the user to open, and a mailto: opt-out is never performed because mailwarden cannot send mail. If the sender offers nothing automatable this returns unsubscribed:false with the alternatives in `options` — it is not an error. USE WHEN: the user wants off a newsletter. Pair with archive/trash or create_filter to deal with mail already in the mailbox. DO NOT USE: to check whether unsubscribing is possible (use list_unsubscribe — it contacts nobody). A sender already contacted in this session is reported with `duplicateOf` and NOT contacted again — safe to retry after a timeout. Pass force:true for a deliberate second attempt (e.g. the endpoint answered 500). SIDE EFFECTS: makes an outbound HTTPS request to the sender's unsubscribe endpoint (plus up to 3 redirects) — the only non-Google host mailwarden ever contacts. This confirms to the sender that the address is live, and it cannot be undone. The mailbox itself is not changed.

NameTypeReqDescription
forceboolean
threadIdstringyes
NameTypeReqDescription
duplicateOfstring
fromstringyes
messageIdstringyes
optionsobjectyes
reasonstring
statusnumber
threadIdstringyes
unsubscribedbooleanyes
urlstring

No examples provided.

untrash ~60

Restore a thread from Trash. SIDE EFFECTS: removes the TRASH label; user labels are preserved, but INBOX is NOT re-added — use modify_labels (add INBOX) to return it to the inbox.

NameTypeReqDescription
threadIdstringyes
NameTypeReqDescription
okbooleanyes

No examples provided.

what_changed ~328

What happened in the mailbox since a point you already hold: messages that arrived or were removed, and labels applied or taken off — from Gmail's own event log, in one call. Pass the `historyId` a previous what_changed or get_profile returned; the reply carries the next one to keep. mailwarden stores NOTHING between calls, so the id lives with you. Reports EVENTS, not current state: a message that was marked unread and then read appears under both, and both are true. For how the mailbox looks NOW, use search or get_thread. Gmail keeps roughly a week of history. An id older than that is an ERROR, never an empty result — it means the question can no longer be answered incrementally, so take a fresh historyId from get_profile and re-establish state with search. `labelId` narrows the feed to events touching one label (e.g. 'INBOX', or a snooze label). Counts are complete even when the id lists are cut at 200 (`truncated`). USE WHEN: a recurring check — 'what came in since I last looked', watching a label, or confirming a bulk action landed. Far cheaper than re-running a search over the whole slice. DO NOT USE: for a first look at a mailbox (there is no id yet — start with triage_digest or search), or to read content: this returns ids only, no sender, subject or body. SIDE EFFECTS: none.

NameTypeReqDescription
labelIdstring
maxinteger
sinceHistoryIdstringyes
NameTypeReqDescription
addedarrayyes
deletedarrayyes
historyIdstringyes
labelsAddedarrayyes
labelsRemovedarrayyes
recordsnumberyes
truncatedbooleanyes

No examples provided.

Common questions

What is the io.github.csitte/mailwarden MCP server?

io.github.csitte/mailwarden is an MCP server listed in the public MCP registry as io.github.csitte/mailwarden. Gmail MCP server for email triage: search, labels, archive, trash, unsubscribe, snooze. This page covers its npm package (mailwarden).

Is the io.github.csitte/mailwarden MCP server safe to use?

io.github.csitte/mailwarden scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the io.github.csitte/mailwarden MCP server expose?

io.github.csitte/mailwarden exposes 26 tools: search, get_thread, list_labels, list_snoozed, get_profile, and 21 more. Their descriptions and schemas cost roughly 5,712 tokens of context every time the server is loaded.

Is the io.github.csitte/mailwarden MCP server still maintained?

io.github.csitte/mailwarden is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the io.github.csitte/mailwarden MCP server under?

io.github.csitte/mailwarden declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.