Jade Email

Queue a forwarded email. Async: returns `{queued: true}` once the message is queued for sending. <hints> - `forwardingEmailId` MUST be an email this user owns (server-side tenant gate; cross-tenant IDs are rejected). - `htmlContent` is ONLY your covering note (may be empty). In `mode: 'inline'` (default) the server appends the original message below it as a full-HTML Gmail-format quote — tables, styling, and inline images intact — and re-attaches the original's files (filtered by `keepAttachmentSourceIndexes` if provided). Do NOT paste the forwarded header or quoted body into htmlContent; that would duplicate them. - `mode: 'attachment'` packages the original's raw MIME as a single .eml attachment instead. Requires `hasRawMime: true` from get_email_for_forward. - Forward starts a NEW thread. Do NOT set In-Reply-To / References anywhere. - `fromInbox` defaults to "the inbox the original landed at" in the web UI but is freely chosen here — must still be an address at a domain the user owns. get_email_for_forward's `suggestedFromInbox` is a ready-made value. </hints> <routing> USE WHEN: sending an existing email onward to a new recipient. DO NOT USE FOR: replying to the sender (send_email with `replyToEmailId`), or a fresh email (send_email). </routing>

Fetch a single email including the parsed body. <hints> - Defaults to plain text (easier for LLMs and cheaper in tokens). Pass `format: "html"` only if raw markup matters. - `maxLength` truncates long bodies and appends a truncation marker. Default 20000 chars is usually enough. - `includeHeaders: true` fetches raw email headers via a second read — only needed for deep analysis. - The `attachments` array includes a stable `index` for each attachment. Pass that `index` to get_email_attachment to download the file — it's the opaque handle, not `fileName` (which can collide within one email). </hints> <routing> USE WHEN: reading or analyzing an email's contents. DO NOT USE FOR: preparing a reply — call get_email_for_reply instead, which returns a clean from-address and a sendable from inbox ready for send_email. </routing>

Fetch the contents of a specific attachment on an email. Returns supported bytes inline as an MCP content block — JPEG/PNG/GIF/WebP images, PDFs (as embedded resources), and text/* files. Oversized (> ~150KB) or unsupported types fall back to a one-hour temporary download URL in a text message so the user can retrieve the file themselves. <hints> - Call get_email first to see which attachments exist. Use the `index` field from the returned `attachments` array as the `attachmentIndex` here — it's the opaque handle, not `fileName` (filenames can collide within one email). - `attachmentCount` on list_emails summaries tells you whether an email has attachments at all, so you can skip get_email entirely for emails with 0 attachments. - Inline support: JPEG/PNG/GIF/WebP images, application/pdf, and any text/* payload (plain text, HTML, calendar invites, CSV). Office documents, archives, SVG, and executables are returned as a download URL inside a text message — surface that URL to the user and do not attempt to fetch it yourself. - Files larger than ~150KB are returned as a download URL regardless of type. Don't pre-filter on size yourself — just call the tool and react to whatever content block comes back. </hints> <routing> USE WHEN: reading the content of a specific attachment. DO NOT USE FOR: listing attachments — call get_email, which returns the full attachment list with indexes. </routing>

Fetch an email prepared for forwarding. <hints> - Returns `originalSubject`, `suggestedSubject` ("Fwd: ..."), a Gmail-style `forwardedHeader` block, the quoted body, the list of `originalAttachments` (source index, filename, and content type — file references are server-only), and `hasRawMime` (whether the original can be forwarded as a .eml attachment). - `forwardedHeader` and `quotedContent` are CONTEXT for you (so you can describe the message to the user) — do NOT embed them in forward_email's htmlContent. The server appends the original message itself, as full HTML with images intact. - Intended as step 1 of a two-step forward workflow. Follow with forward_email passing `forwardingEmailId: originalEmailId`, the chosen `to` recipients, the `suggestedSubject`, `fromInbox: suggestedFromInbox` (null means the user has no sending domains), and an htmlContent containing only the covering note (may be empty). - Forward starts a NEW thread — do not pass the source email's threading info anywhere. </hints> <routing> USE WHEN: the user asks to forward an email. DO NOT USE FOR: replying — call get_email_for_reply instead. </routing>

Fetch an email prepared for a reply. <hints> - Returns `replyTo` (clean from-address with display-name stripped), `suggestedSubject` ("Re: ..."), `suggestedFromInbox` (a complete, sendable from address — null when the user has no sending domains), and `originalInbox` (the local part of the address that received the original). - Intended as step 1 of a two-step reply workflow. Follow with send_email using: `to: [replyTo]`, `subject: suggestedSubject`, `fromInbox: suggestedFromInbox`, and `replyToEmailId: originalEmailId` so the reply threads with the original. - `htmlContent` on the follow-up send_email is ONLY the reply body you compose. The server appends the quoted original below it — do NOT paste a quote or attribution line yourself; that would duplicate them. - To read the original before composing, call get_email. </hints> <routing> USE WHEN: the user asks to reply to an email. DO NOT USE FOR: just reading an email's body — call get_email instead. </routing>

Fetch one ruleset with its rules in execution order. Same rule shape as direct inbox rules minus `inbox` — the rules apply to whichever inbox is bound to the ruleset. For browsing multiple rulesets, prefer `list_rulesets` with `includeRules: true` instead of looping this tool.

One-call summary of what needs the user's attention: the total unread count plus which categories currently hold new or pinned mail. <hints> - Counts cap at a single query page (roughly 500-1000 emails, newest first) — a user with more unread mail than that sees an undercount. This is the same approximation the web sidebar badge uses. - `categoriesWithNew` / `categoriesWithPinned` are category slugs — pass them straight to list_emails' category filter or cross-reference list_categories for display names. - Follow up with list_emails (`filter: {kind: "category", slug, status: "new"}`) to read what's actually there. </hints> <routing> USE WHEN: the user asks "what's new", "what needs my attention", "catch me up" without naming a specific category or inbox. DO NOT USE FOR: browsing actual emails (list_emails), or the full category listing with descriptions (list_categories). </routing>

List the user's email categories, sorted by the user's chosen order. <hints> - `slug` is the immutable lowercase identifier — pass it to other tools when referencing a category. `displayName` is the user-facing label (mutable via update_category). - `description` is free-form text the user wrote to explain what the category is for — USE IT when picking the right category for a rule or recategorize call, since the displayName alone may be ambiguous. - `color` is a UI-only hex string. `hidden: true` means the category is suppressed from the sidebar and the unified Everything view; inbox and category pages still surface its mail. `order` is the sort position. </hints> <routing> USE WHEN: resolving category slugs, or choosing the right bucket for a rule action or recategorize call. DO NOT USE FOR: browsing the mail inside a category — call list_emails with a category filter. </routing>

List the user's verified sending domains — exactly the set `send_email` accepts as the domain half of `fromInbox`. <hints> - Build a `fromInbox` as `<local part>@<one of these domains>`. `list_inboxes` returns only local parts. - An empty array means the account has no sending domains: the user can still receive mail, but send, reply, and forward are unavailable. </hints> <routing> USE WHEN: constructing a `fromInbox` for send_email, or checking whether the user can send at all. DO NOT USE FOR: per-sender inboxes (list_inboxes), or the domain a specific email arrived at (the `domain` field on email results — that domain can be receive-only and rejected for sending). </routing>

List the user's received emails. Filter by category, inbox, or omit the filter for the user-wide view. Optionally narrow any scope to a single status (`new`, `read`, `pinned`, `deleted`, or `archived`). Returns metadata only — use get_email to read the body. <hints> - Filter kinds: `{kind: "category", slug: "..."}` scopes to a category (pass the slug from `list_categories`), `{kind: "inbox", inbox: "..."}` scopes to a single inbox, `{kind: "all"}` or omitted returns everything. Category and inbox cannot be combined — the underlying indexes serve one or the other, not both. - The `inbox` value is the LOCAL PART only (e.g., "newsletter"), not the full "[email protected]". Call list_inboxes for exact values. - `status` is optional on every filter kind. Omit it for the default pinned→new→read stack (what the web UI shows). Pass it to isolate a single status (e.g., `status: "new"` for unread triage, `status: "pinned"` for starred, `status: "deleted"` for trash). - Paginate with `cursor` from a previous response. `hasMore: true` signals more pages exist. Cursors are not interchangeable across different filter+status combinations. - Every email in the response includes `attachmentCount`. Use it to triage "which thread has the PDF" without fetching each body — skip straight to get_email on the emails where `attachmentCount > 0`. </hints> <routing> USE WHEN: browsing/triaging received emails by category, inbox, or status. DO NOT USE FOR: keyword search across subjects or bodies (call search_emails), sent emails (call list_sent_emails), or reading a body (call get_email). </routing>

List the inbox's ordered chain as a mix of direct rules and attached rulesets. Each item is either `kind: "rule"` (a direct inbox rule) or `kind: "ruleset"` (a binding to a named ruleset, with its rules nested in order). Items interleave by the shared `order` namespace. <evaluation_model> At runtime the chain is flattened: each ruleset binding expands in place to its contained rules, then the loop runs in order. `stopProcessing` on any rule — direct OR inside a ruleset — halts the WHOLE chain. Edit a rule inside a ruleset via `update_ruleset_rule` and every inbox bound to that ruleset sees the change. </evaluation_model>

List the user's inboxes (email addresses they receive mail at), ordered by most recent activity. <hints> - Each result's `inbox` field is the local part (e.g., "newsletter" for [email protected]) — the exact value to pass as `filter.inbox` to list_emails or as `inbox` to the rule tools. - Power users can have many hundreds of inboxes — this is the central premise of Jade. Returns up to 500 in a single call with a `truncated` flag; work with the subset you need rather than iterating every result. </hints> <routing> USE WHEN: discovering which per-sender inboxes exist, or resolving an exact inbox value for another tool. DO NOT USE FOR: the user's sending domains (list_domains), or browsing the mail inside an inbox (list_emails with an inbox filter). </routing>

List the user's rulesets — named, reusable rule collections that can be attached to multiple inboxes. Each result has a `name`, optional `description` (USE THIS to pick the right ruleset by intent, the name alone is often ambiguous), `isDefault` flag, and `ruleCount`. Edits to a ruleset propagate to every inbox it's bound to. Pass `includeRules: true` to inline each ruleset's full rule list — same shape as `get_ruleset`. The implementation already fetches rules to compute `ruleCount`, so this is free data and avoids the N×`get_ruleset` follow-up loop.

List the user's sent emails (outbox), most recent first. <routing> USE WHEN: the user asks about email they sent, their outbox, sent history, or whether Jade recorded a send after the mail provider accepted it. DO NOT USE FOR: received emails — call list_emails with no filter or a category/inbox filter. </routing>

Mark every new email in a category as read in one call. <routing> USE WHEN: bulk-clearing a category like "newsletter" or "marketing" without needing to list emails first. DO NOT USE FOR: marking specific emails by id — call set_email_status with the id list and `status: "read"` instead. </routing>

Reorder a rule within its inbox chain using a semantic intent. The server resolves the intent to concrete orders and renumbers the entire chain to sequential 1..N so the result matches what the settings UI would show. <hints> - `{kind: "first"}` — move to the top of the chain (runs first). - `{kind: "last"}` — move to the bottom of the chain (runs last). - `{kind: "up"}` — swap with the rule immediately above (no-op if already first). - `{kind: "down"}` — swap with the rule immediately below (no-op if already last). - `{kind: "before", ruleId}` — insert immediately before another rule in the same inbox. - `{kind: "after", ruleId}` — insert immediately after another rule in the same inbox. - Moving a rule to a different inbox is NOT supported — delete and recreate with the new inbox instead. - Returns the full renumbered chain so you can see the updated `order` on every rule. </hints>

Reorder a ruleset binding within the inbox's merged chain. For `before` / `after`, the `bindingId` field names another binding in the same inbox. To step past a direct inbox rule, use `up` / `down` — the merged chain is renumbered across rules and bindings together. Returns the renumbered list of bindings for this inbox.

Reorder a rule within its ruleset. Returns the full renumbered list.

Re-categorize every email in a category (both 'new' and 'read' status) in a single tool call — re-applies each email's inbox rules (the web UI calls this "Reprocess"). Fetches all matching emails and queues them as one batch. <routing> USE WHEN: the user just edited rules and wants a whole category (e.g., "uncategorized", "marketing") re-evaluated. DO NOT USE FOR: reclassifying by sender or inbox — use recategorize_inbox for inbox-level reclassification. </routing>

Queue a specific list of emails for re-categorization in one call (the web UI calls this "Reprocess": it re-applies each email's inbox rules; there is no way to pick a category directly). Batches internally and returns the queued count plus any per-email errors. <routing> USE WHEN: you already have a list of email ids you want to reclassify (e.g., from a prior list_emails response). DO NOT USE FOR: reclassifying everything in a category or inbox — call recategorize_category or recategorize_inbox, which skip the list step entirely. </routing>

Re-categorize every email in a specific inbox (both 'new' and 'read' status) in a single tool call — re-applies the inbox's rules (the web UI calls this "Reprocess"). Fetches all matching emails and queues them as one batch — the standard follow-up after adding or editing rules on that inbox. <routing> USE WHEN: the user just added or edited rules on a specific inbox and wants existing emails re-evaluated. DO NOT USE FOR: reclassifying a category across multiple inboxes — use recategorize_category instead. </routing>

Reorder the user's categories. Pass every slug in the desired order; the call updates each category's sort position. Slugs not present in the user's account are rejected so a stale snapshot can't silently drop rows. <hints> - The order set here drives sidebar and settings list display. Sort order in `list_categories` reflects this. - Pass the COMPLETE set of slugs. Partial reorders aren't supported — call `list_categories` first if you need the current set. </hints>

Keyword search across the user's emails, with structured operators for common filters. Matches on subject, inbox, from, to, and body. Returns metadata only — use get_email to read the body. <hints> - Operators: `from:` / `to:` / `cc:` / `bcc:` (address match), `subject:`, `body:`, `has:attachment`, `category:`, `before:` / `after:` / `on:` (YYYY-MM-DD dates only, e.g. `before:2026-03-01`), `larger:` / `smaller:` (size with k/m suffixes, e.g. `larger:500k`), and `is:read` / `is:unread`. Quoted phrases keep spaces (`subject:"order shipped"`); prefix a token with `-` to negate it (`-from:noreply`). - Everything ANDs together — every operator and free-text word must match. There is no OR; run two searches for disjunction. Unknown `foo:bar` tokens match as literal text. - Plain free-text queries get fuzzy matching (minor typos still match) and a recency boost. The moment any operator is present, results rank by relevance only. - Subject and inbox terms weigh heaviest in relevance ranking. The first result is the best match, not the newest email. - Deleted and archived emails are filtered out of results. To look at deleted items, use `list_emails` with `status: "deleted"` instead. - No pagination cursor — bump `limit` (max 100) if you need more results. - If search is unavailable or fails, this tool returns an empty array rather than an error — don't infer "no matches" from an empty response without trying a broader query. </hints> <routing> USE WHEN: the user describes what they're looking for in words — a sender, subject keyword, or body phrase — without knowing the inbox/category. DO NOT USE FOR: browsing by category or inbox (call list_emails), or fetching a known email by id (call get_email). </routing>

Queue an outbound email. Async: returns `{queued: true}` once the message is queued for sending; Jade normally processes it within seconds. <hints> - `fromInbox` MUST be an address at a domain the user owns. The tool independently verifies this against the user's registered domains and will reject other senders with a clear error. If unsure which addresses are valid, call list_inboxes first and use `<local-part>@<domain>` where the domain appears in other emails' `from` fields. - For replies, call get_email_for_reply first to get a clean recipient, suggested subject, and a sendable from address, then pass them into this tool along with `replyToEmailId` so the reply threads with the original. When `replyToEmailId` is set, `htmlContent` is ONLY your reply body — the server appends the quoted original below it. - `textContent` is optional — if omitted, the server derives plain text from `htmlContent`. - Delivery failures are not reported back through this tool — confirm via list_sent_emails, which shows the message once the mail provider accepts it. Recorded there means accepted for delivery, not that the recipient received it. </hints> <routing> USE WHEN: sending a fresh email or a reply (with `replyToEmailId`). DO NOT USE FOR: forwarding an existing email — call forward_email, which carries the original content and attachments server-side. </routing>

Schedule one or more emails for permanent deletion a set number of days from now, or remove an existing schedule. The scheduled deletion is a hard delete that bypasses trash and is irreversible once it fires (typically within ~48 hours of the target time). <hints> - `days` is counted from NOW, not from when the email was received. This is the manual-control counterpart to the rule `deleteAfterDays` action (which measures from the email's receipt timestamp). - Pass `days: null` to REMOVE an existing expiration so the email is never auto-deleted — including expirations originally set by an inbox rule. - `days` accepts 1–3650. Re-running with a new `days` reschedules from now (it does not add to the existing date). - Whether an email currently has an expiration is visible as `expiresAt` (ISO 8601, or `null`) on every list_emails / search_emails / get_email result. - Reading or pinning an email leaves a schedule intact; soft-deleting it (set_email_status → "deleted") replaces any schedule with the standard 30-day trash-retention TTL. - Accepts a single emailId or an array (up to 500). Per-email failures surface in `errors` without failing the whole call. </hints> <routing> USE WHEN: the user wants to auto-delete specific emails after a while, or wants to cancel a scheduled deletion on specific emails. DO NOT USE FOR: auto-expiring all future mail to an inbox — set a `deleteAfterDays` action on an inbox rule (create_inbox_rule) instead. For an immediate (not scheduled) delete, use set_email_status with status "deleted". </routing>

Set the status of one or more emails. Use this for any lifecycle state change — reading, unreading, pinning/unpinning, deleting (soft), or archiving. Idempotent: emails already in the target state are reported in `noChange`. <hints> - `status: 'pinned'` moves the email to the pinned shelf regardless of its prior state. To unpin, set `status: 'read'` — pinned → read applies as an intentional unpin. - `status: 'deleted'` is a soft delete — restore the email by setting it to `'new'`; setting it to `'read'` intentionally leaves deleted mail untouched. - When `status: 'read'`, deleted and archived emails are left untouched and reported in `noChange` so a bulk mark-as-read can't accidentally resurrect them. To pull a deleted/archived email back into the primary view, use `'new'` instead. - `status: 'new'` resurrects a deleted/archived email back into the primary view. - Missing email ids surface per-email in the `errors` array; they do not fail the whole call. </hints> <routing> USE WHEN: changing email status by id list for any target state. DO NOT USE FOR: clearing an entire category by name — call `mark_category_read` instead (one call, no id list required). </routing>

Queue an automatic unsubscribe attempt for one or more emails, using each email's List-Unsubscribe header (HTTP POST or email). <hints> - Pass an array of emailIds to queue in one call; per-email failures surface in the `errors` array without failing the whole call. Prefer one batch call over a loop. - Dedup is per-email, not per-sender: each email queues its own attempt, and future mail from the same sender is unaffected. To unsubscribe on every future arrival, set `unsubscribe: true` on an inbox rule instead. - `queued` means the attempt was accepted for processing, not that the sender honored it. Emails without unsubscribe information fail silently at processing time. </hints> <routing> USE WHEN: the user wants off a mailing list represented by specific received emails. DO NOT USE FOR: recurring auto-unsubscribe on an inbox (create_inbox_rule with `action.unsubscribe`), or making mail stop arriving in Jade views (set_email_status or a rule with `status: "deleted"`). </routing>

Update a category's mutable fields. The slug is immutable — pass it as the identifier. <hints> - Omit a field to leave it unchanged. - For `displayName`, `color`, `description`: pass an empty string ("") to CLEAR, or a value to set. `displayName` clearing falls back to a capitalized form of the slug. - For `hidden`: pass `true` to suppress from the sidebar + Everything view, `false` to make visible again. Inbox and category pages always surface the mail regardless. - Renaming a category is just `update_category({ slug, displayName: "New Name" })`. The slug never changes, so URLs and rule action targets keep working without any data rewrite. </hints>

Update mutable match/action fields on an existing inbox rule. Pass `ruleId` plus any subset of matchText, matchLocation, always, action, or stopProcessing. The rule's id and inbox are immutable — to move a rule to a different inbox, delete it and recreate. To reorder a rule within its inbox, use **move_inbox_rule** instead — this tool intentionally does NOT accept `order`, because raw integer ordering is an implementation detail the MCP surface hides from callers. <hints> - Updating `action` fully replaces the action object; pass the complete new action, not a partial. </hints>

Update a ruleset's metadata. Omit a field to leave it unchanged; pass `description: ""` to CLEAR it; pass `isDefault: true` to make this the default (clearing any prior default); `isDefault: false` unmarks without promoting a new default.

Patch a rule inside a ruleset. Use `move_ruleset_rule` to reorder within the ruleset.