Sendraven MCP Server vs Mailwarden
A side-by-side look at the Sendraven MCP Server and Mailwarden MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Sendraven MCP Server for communication work as a local process; choose Mailwarden for communication as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Sendraven MCP Server when
- You need dedicated capabilities in the Communication domain.
- You prefer a local stdio subprocess transport.
- You have the keys it needs:
SENDRAVEN_API_KEY. - You want tools like
send_email, list_emails, get_email.
Choose Mailwarden when
- You need dedicated capabilities in the Communication domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: OAuth 2.0.
- You want tools like
search, get_thread, list_labels.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Communication | Communication |
| Quality signal | 63/100 · Good | 64/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | OAuth 2.0 |
| Pricing | Not declared | Free |
| Required env vars | SENDRAVEN_API_KEY | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 1 | 0 |
| Directory activity | 3 views 0 installs 0 upvotes | 5 views 0 installs 0 upvotes |
| Tools | 55 | 26 |
| Full listing | View Sendraven MCP Server | View Mailwarden |
Tools & capabilities
Sendraven MCP Server tools 55
send_emailSend a transactional email, immediately or scheduled. scheduled_at takes a relative phrase like 'in 3 days' or an ISO timestamp. The From domain must already be verified. Every accepted send answers with the same fields: id, status, thread_id, scheduled_at, skipped, reason and approval_id. skipped: true (status 'rejected', with reason) means every recipient was suppressed or opted out and nothing was sent; a retry answers the same. status 'pending_approval' (with approval_id) means a person must release it; a retry does not release it. Otherwise skipped is false and reason and approval_id are null. idempotency_key makes a retry of the identical message safe; it matches only the identical message. Refusals, by type: 422 no_verified_identity (the From domain has no verified sending domain; a retry answers the same until it is added and verified); 422 invalid_request (a bad field, or more than 50 recipients across to, cc and bcc, which fit as separate messages or a campaign); 422 unknown_topic; 422 invalid_schedule; 403 recipient_not_allowed (this key's allowlist); 429 daily_limit (this key's daily cap; it resets tomorrow, and a retry today answers the same); four billing refusals, all 402 and none retryable — plan_limit_reached (the Free plan's 3,000 emails a month are spent; a person has to activate paid sending), payment_method_required (the workspace has never had a payment method verified, so no outbound email leaves it at all, including on Free; only a person can add one, in the dashboard), billing_past_due (the payment failed for good) and budget_exceeded (the workspace's own spend ceiling; by default it stops marketing and lets transactional through); 422 workspace_suspended and 422 no_postal_address (a person has to act). 502 ses_error is the provider, and a later retry with the same idempotency_key is safe. get_usage shows which of these applies before a send, and apart from ses_error none clears by repeating the call.list_emailsList messages newest first with their delivery status, including held, scheduled, skipped and failed ones and the mail campaigns and automations sent. Filter by status or recipient. Paged: at most 100 per call; while has_more is true, next_cursor passed back as cursor with the same filters returns the next page. An unknown status is refused with 422 invalid_request rather than answering an empty log.get_emailFetch one message with its full event timeline (send, delivery, bounce, complaint, open, click). The timeline shows why an email didn't arrive.cancel_scheduled_emailCancel a scheduled email before it sends. Only works while status is 'scheduled': a message that has already started sending, or is in any other state, answers 409 invalid_state naming its status; a retry answers the same, and get_email shows where it stands. An unknown id answers 404 not_found.list_sending_domainsList sending domains with their verification status and the DNS records each one needs. Each record shows what is currently published, so this diagnoses a stuck verification. mail_from says whether SES has adopted the bounce. subdomain as the Return-Path: pending while SES polls for its MX record, then active. SES polls for 72 hours from when the domain was added, not from when the MX appears, and then marks it failed; publishing the MX later and calling verify_sending_domain restarts it. A verified domain sends fine meanwhile; only SPF alignment waits.add_sending_domainRegister a sending domain and get back the DNS records to publish. It takes the domain mail is sent from — mail.<domain> and news.<domain> are provisioned beneath it and the right one is chosen per message, so a marketing complaint spike can never affect password reset delivery. risk_class provisions one of the two on its own. Two records come back marked optional: an inbound MX so replies land in threads, and a link. CNAME that turns on click tracking on the customer's own name once its certificate is issued. Adding a domain that already exists returns it rather than a duplicate. A public suffix such as co.uk or github.io is not a domain anyone can send from and is refused with 422 invalid_request; the domain registered under it, e.g. example.co.uk, is accepted. Passing mail.example.co.uk or news.example.co.uk is read as example.co.uk. A plan with no room for another domain answers 402 plan_limit_reached; a retry answers the same until a person upgrades or removes a domain.verify_sending_domainRe-check a domain's DNS records now instead of waiting for the background monitor. Also restarts bounce-path (mail_from) verification when SES gave up before the MX record existed.list_suppressionsList addresses we refuse to mail and why (hard_bounce, complaint, unsubscribe, manual, list_hygiene), newest first, each with its scope. When someone reports not receiving email, this shows whether the address is suppressed. email returns one address's suppressions directly; scanning pages instead is how the wrong suppression gets cleared. At most 100 per call; while has_more is true, next_cursor passed back as cursor returns the next page.add_suppressionStop sending to an address. Scope 'marketing' leaves transactional mail working; the default is 'all'. Reason 'unsubscribe' is a real opt-out: it also cancels the person's queued scheduled sends and ends their automation enrolments, which is what a person who asked to stop expects and 'manual' does not do. A hard bounce or complaint already on file is never replaced; the response is the stored suppression (id, email, reason, scope, detail, created_at), so its reason says which one stands.remove_suppressionRemove a suppression so the address can be mailed again. A hard bounce means the address was rejected by the receiving server, and re-sending raises the bounce rate that AWS enforces on. The scope must match the stored one: removed: false means nothing was suppressed in that scope (an address suppressed for 'marketing' is not lifted by 'all'); list_suppressions with email shows the scope that is stored.create_broadcastCreate a campaign as a draft. Nothing is sent: preview_broadcast reports its reach and send_broadcast sends it. identity_id must be a marketing sending domain (see list_sending_domains; risk_class 'marketing'). topic_key must name an existing topic (list_topics); an unknown one is refused with 422 unknown_topic, since it would count everyone as opted out. A segment_id must filter the same audience as audience_id. An A/B test takes 2 to 10 'variants' that differ in subject, from_name or send_at, and optionally 'ab_test'. A subject or from-name test sends sample_share of the audience (default 0.2) split evenly across the variants, waits decide_after_minutes (default 240) after the sample is out, picks the variant with the best unique open rate (or click rate with metric 'click'), and sends the rest to it. Each variant needs at least 100 recipients in the sample or the send is refused — preview_broadcast shows the number. Metric 'click' only works once the domain has click tracking; until then every variant shows zero clicks and the first variant wins by default. The response's web_version_url is a public page of the campaign (one URL, no recipient's unsubscribe link) to share on a site or social post; null until click tracking is active.get_broadcastOne campaign, with a 'progress' object while it is sending, paused or testing: how many addresses are still pending, sent, failed, or skipped because the person opted out after the campaign started. This is what tells a paused campaign that is still making progress from one that is waiting; pause_reason says on what, and resume_after when a warm-up pause renews. progress is null for a campaign not in flight. For an A/B test, progress.by_variant is a list of { key, pending, sent, failed, skipped } in variant order, ending with a row whose key is null: the addresses still waiting for the winner. An A/B test also carries 'ab_test' with live per-variant results — sent, unique opens, unique clicks and their rates — plus 'decide_at' and, once decided, 'winner' and 'decided_by'. Status 'testing' means the sample is out and the rest of the audience is waiting on the decision.- +43 more on the listing page
Mailwarden tools 26
searchSearch 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.get_threadFetch 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 disagree with the ones above. `unchecked: true` means the message carried no report at all — that is 'nobody looked', NOT 'nothing wrong'; unauthenticated does not imply forged, and authenticated does not imply honest (a phisher can hold a passing DMARC on his own lookalike domain). USE WHEN: reading a thread's content after finding it via search. DO NOT USE: with a message ID — this takes thread IDs. SIDE EFFECTS: none (does not mark as read).list_labelsList 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.list_snoozedList all snoozed threads with their due dates. SIDE EFFECTS: none.get_profileReturn 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.what_changedWhat 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.triage_digestStructured 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.list_unsubscribeReport 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.list_subscriptionsWho 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.create_labelCreate 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.modify_labelsAdd/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.bulk_modifyBulk-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 predicate is re-run as a label filter (`labelIds`) instead of a query operator, and any message the two routes disagree about is left untouched and listed in `crossChecked.dropped`. It costs one extra list per predicate — flat, not per message — so unlike `verify` it stays cheap on a large sweep. Read it as a contradiction detector: a disagreement is real, agreement proves nothing, because both routes read the same index. `unverifiedPredicates` therefore stays as it is even when this runs. A capped match set is not cross-checked at all (`crossChecked.capped`), since a message missing from a page is not a message missing the label. Set dryRun:true to rehearse: the same query resolution, matched counts/threads and the labels that would be created — and no message or label is touched. A dry run reads the SAME unverified index, so it confirms the size of the set, never its correctness. USE WHEN: mass operations — 'archive all newsletters older than 30 days' (query + remove INBOX), bulk labeling, bulk mark-read; dryRun first when the query is broad or the user should see the set before it changes. DO NOT USE: for a single thread (use modify_labels or the dedicated tools), or with neither add nor remove. SIDE EFFECTS: modifies up to maxMessages messages in one call (none with dryRun); label changes are reversible by the inverse call.- +14 more on the listing page
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Sendraven MCP Server
{
"mcpServers": {
"mcp-249": {
"command": "npx",
"args": [
"-y",
"@sendraven/mcp"
],
"env": {
"SENDRAVEN_API_KEY": "YOUR_SENDRAVEN_API_KEY_HERE"
}
}
}
}
Mailwarden
{
"mcpServers": {
"csitte-mailwarden": {
"command": "npx",
"args": [
"-y",
"mailwarden"
]
}
}
}
Frequently asked questions
Sendraven MCP Server is categorized under Communication and uses a local stdio subprocess. Mailwarden belongs to Communication and uses a local stdio subprocess. Pick Sendraven MCP Server for communication work and Mailwarden for communication.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Sendraven MCP Server has no declared pricing — check the project's own site. Mailwarden is listed as free. Auth: oauth 2.0. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add mcp-249 and csitte-mailwarden as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Sendraven MCP Server has a quality signal of 63/100 (Good) with 3 views, 0 installs and 1 GitHub stars. Mailwarden has 64/100 (Good) with 5 views, 0 installs and 0 GitHub stars.