io.github.csitte/mailwarden
NPM · MAILWARDEN · SCANNED SEP 20
Gmail MCP server for email triage: search, labels, archive, trash, unsubscribe, snooze.
Available components
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
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
claude mcp add csitte-mailwarden -- npx -y mailwarden
{
"mcpServers": {
"csitte-mailwarden": {
"command": "npx",
"args": [
"-y",
"mailwarden"
]
}
}
} {
"servers": {
"csitte-mailwarden": {
"command": "npx",
"args": [
"-y",
"mailwarden"
]
}
}
} codex mcp add csitte-mailwarden -- npx -y mailwarden
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"csitte-mailwarden": {
"type": "local",
"command": [
"npx",
"-y",
"mailwarden"
],
"enabled": true
}
}
} openclaw mcp add csitte-mailwarden --command npx --arg -y --arg mailwarden
mcp_servers:
csitte-mailwarden:
command: "npx"
args: ["-y", "mailwarden"] {
"McpServers": {
"csitte-mailwarden": {
"Transport": "stdio",
"Command": "npx",
"Arguments": [
"-y",
"mailwarden"
]
}
}
} assistant mcp add csitte-mailwarden -t stdio -c npx -a -y mailwarden
{
"mcpServers": {
"csitte-mailwarden": {
"command": "npx",
"args": [
"-y",
"mailwarden"
]
}
}
} 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
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 →
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 →
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.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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…
| Name | Type | Req | Description |
|---|---|---|---|
| add | array | – | – |
| crossCheck | boolean | – | – |
| dryRun | boolean | – | – |
| maxMessages | integer | – | – |
| query | string | yes | – |
| remove | array | – | – |
| verify | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| capped | boolean | yes | – |
| crossChecked | object | – | – |
| dryRun | boolean | yes | – |
| failed | array | yes | – |
| labelsToCreate | array | – | – |
| matchedMessages | number | yes | – |
| matchedThreadCount | number | yes | – |
| matchedThreads | array | yes | – |
| submittedMessages | number | yes | – |
| submittedThreadCount | number | yes | – |
| submittedThreads | array | yes | – |
| unverifiedPredicates | array | yes | – |
| verified | object | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| dryRun | boolean | – | – |
| threadIds | array | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| attempted | number | yes | – |
| dryRun | boolean | yes | – |
| requested | number | yes | – |
| requests | number | yes | – |
| results | array | yes | – |
| skippedDuplicates | number | yes | – |
| skippedOutOfTime | number | yes | – |
| unsubscribed | number | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| addLabels | array | – | – |
| applyToExisting | boolean | – | – |
| excludeChats | boolean | – | – |
| from | string | – | – |
| hasAttachment | boolean | – | – |
| maxMessages | integer | – | – |
| negatedQuery | string | – | – |
| query | string | – | – |
| removeLabels | array | – | – |
| size | integer | – | – |
| sizeComparison | string | – | – |
| subject | string | – | – |
| to | string | – | – |
| verify | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| addLabelIds | array | yes | – |
| applied | – | yes | – |
| criteria | object | yes | – |
| forward | string | – | – |
| id | string | yes | – |
| removeLabelIds | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| backgroundColor | string | – | – |
| name | string | yes | – |
| textColor | string | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| color | object | – | – |
| id | string | yes | – |
| name | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| attachmentId | string | yes | – |
| destPath | string | yes | – |
| messageId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| saved | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| emailAddress | string | yes | – |
| historyId | string | yes | – |
| messagesTotal | number | yes | – |
| threadsTotal | number | yes | – |
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…
| Name | Type | Req | Description |
|---|---|---|---|
| full | boolean | – | – |
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| messages | array | yes | – |
| metadataOnly | boolean | – | – |
| threadId | string | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| filters | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| labels | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| snoozed | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| max | integer | – | – |
| query | string | – | – |
| topN | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| hasMore | boolean | yes | – |
| query | string | yes | – |
| sampled | number | yes | – |
| sendersFound | number | yes | – |
| subscriptions | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| bodyCandidates | array | yes | – |
| from | string | yes | – |
| hasUnsubscribe | boolean | yes | – |
| httpsUrls | array | yes | – |
| mailtos | array | yes | – |
| messageId | string | yes | – |
| oneClick | boolean | yes | – |
| subject | string | yes | – |
| threadId | string | yes | – |
No examples provided.
mark_read ~36
Mark a thread as read. SIDE EFFECTS: removes UNREAD; reversible via mark_unread.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
No examples provided.
mark_unread ~36
Mark a thread as unread. SIDE EFFECTS: adds UNREAD; reversible via mark_read.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| add | array | – | – |
| remove | array | – | – |
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| maxResults | integer | – | – |
| pageToken | string | – | – |
| query | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| nextPageToken | string | – | – |
| threads | array | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| until | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| snoozedUntil | string | yes | – |
| threadId | string | yes | – |
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).
| Name | Type | Req | Description |
|---|---|---|---|
| dryRun | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| date | string | yes | – |
| dryRun | boolean | yes | – |
| dueLabels | array | yes | – |
| dueThreadCount | number | yes | – |
| dueThreads | array | yes | – |
| errors | array | yes | – |
| failedCount | number | yes | – |
| woken | array | yes | – |
| wokenCount | number | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| max | integer | – | – |
| query | string | – | – |
| topN | integer | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| byAge | object | yes | – |
| hasMore | boolean | yes | – |
| query | string | yes | – |
| sampled | number | yes | – |
| signals | object | yes | – |
| topLabels | array | yes | – |
| topSenders | array | yes | – |
| unread | number | yes | – |
| withAttachments | number | yes | – |
No examples provided.
unsnooze ~44
Cancel a snooze: return the thread to the inbox now. SIDE EFFECTS: removes the snooze label, restores INBOX.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| unsnoozed | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| force | boolean | – | – |
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| duplicateOf | string | – | – |
| from | string | yes | – |
| messageId | string | yes | – |
| options | object | yes | – |
| reason | string | – | – |
| status | number | – | – |
| threadId | string | yes | – |
| unsubscribed | boolean | yes | – |
| url | string | – | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| threadId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| ok | boolean | yes | – |
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.
| Name | Type | Req | Description |
|---|---|---|---|
| labelId | string | – | – |
| max | integer | – | – |
| sinceHistoryId | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| added | array | yes | – |
| deleted | array | yes | – |
| historyId | string | yes | – |
| labelsAdded | array | yes | – |
| labelsRemoved | array | yes | – |
| records | number | yes | – |
| truncated | boolean | yes | – |
No examples provided.
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.