Jade Email

Remove a binding that attached a ruleset to an inbox. Takes the `bindingId` (from `list_inbox_rules` — each ruleset entry carries its bindingId). The ruleset itself stays; only this inbox stops using it. Pass an array of `bindingId`s to detach in one call; per-binding failures surface in the `errors` array without failing the whole call.

detach_ruleset_from_inbox

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>

forward_email

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 the address to reply to and a sendable from inbox ready for send_email. </routing>

get_email

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 — plus a companion text block carrying a one-hour temporary download URL. Oversized (> ~150KB) or unsupported types return only the download URL. <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. - Every result includes the temporary download URL. If the client interface doesn't display the inline image or PDF, give the user the download link so they can open the file themselves. - 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>

get_email_attachment

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>

get_email_for_forward

Fetch an email prepared for a reply. <hints> - Returns `replyTo` (the address to reply to, with any display name stripped: the sender for mail you received, the recipients for mail you sent), `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>

get_email_for_reply

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.

get_ruleset

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. - Hidden categories are left out of both slug lists, as they are out of the web sidebar. `unreadCount` still counts their mail. - `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>

get_triage_summary

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, the unified Everything view, the unscoped list_emails view, and get_triage_summary's category lists; inbox and category pages (and a category-scoped list_emails call) 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_categories

List the user's domains. `domains` is exactly the set `send_email` accepts as the domain half of `fromInbox`. `receiveOnlyDomains` lists the free domains provided by Jade. They receive mail at any address and remain receive-only after upgrading. <hints> - Build a `fromInbox` as `<local part>@<one of domains>`. `list_inboxes` returns only local parts. - To give the user an address to hand out, pair a different local part for each sender with a domain from either list, such as `netflix@<domain>`. - An empty `domains` array means send, reply, and forward are unavailable. The user can still receive mail. </hints> <routing> USE WHEN: finding the user's free Jade domain, constructing a `fromInbox` for send_email, checking whether the user can send at all, or telling the user which addresses they can hand out. DO NOT USE FOR: per-sender inboxes (list_inboxes), or the domain a specific email arrived at (the `domain` field on email results). </routing>

list_domains

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 except mail in hidden categories (the same rows the web Everything view shows; scope to the category explicitly to read hidden mail). Trash (`status: "deleted"`) and archive (`status: "archived"`) listings include hidden categories, as their web views do. 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. An unscoped page can come back empty with `hasMore: true` when hidden categories fill it; keep paging with `nextCursor`. 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_emails

List the email addresses verified for the forwardTo rule action. Call this before setting action.forwardTo; only a listed address is accepted.

list_forwarding_addresses

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_inbox_rules

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 domains (list_domains), or browsing the mail inside an inbox (list_emails with an inbox filter). </routing>

list_inboxes

List the user's rulesets — named, reusable rule collections that can be attached to multiple inboxes. Each result has a `name`, optional `description` (use it 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_rulesets

List the addresses waiting in Screening. Screening holds mail to an address that has never received mail at a domain with screening on. Each row is an address; call list_screened_emails for its emails.

list_screened_addresses

List the emails waiting for one screened address, newest first. Read one with get_email.

list_screened_emails

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>

list_sent_emails

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>

mark_category_read

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>

move_inbox_rule

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.

move_inbox_ruleset

Reorder a rule within its ruleset using a semantic position (first, last, up, down, before, after). The ruleset is renumbered to sequential order and the full renumbered rule list is returned. Order inside the ruleset is the order the rules run in for every inbox the ruleset is attached to.

move_ruleset_rule

Start an attachment upload. Returns a temporary `uploadUrl` to send the file to and the `attachmentHandle` that send_email takes. <hints> - Step 1 of a two-step flow. After this call, HTTP PUT the raw file bytes to `uploadUrl` with `Content-Length: <fileSize>` and `Content-Type: <contentType>`. A body of any other length is rejected. Then pass `attachmentHandle` in send_email's `attachmentHandles`. - Use `uploadUrl` from your own HTTP tooling, for example `curl -X PUT --data-binary @file`. It expires after `expiresIn` seconds. The handle is single-use. - Limits: 7 MB per file, 10 files and 7 MB total per email. Executables (.exe, .bat, .cmd, .com, .scr, .pif) are rejected. </hints> <routing> USE WHEN: the user wants to send a file they have, or one you produced, as an email attachment. DO NOT USE FOR: forwarding an existing email's attachments (forward_email carries them server-side), or reading an attachment (get_email_attachment). </routing>

prepare_attachment_upload

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>

reorder_categories

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>

recategorize_category

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>

recategorize_emails

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>

recategorize_inbox

Screen in an address at a domain and deliver its waiting emails as new mail. Matching rules can forward the released mail, send bounces, or unsubscribe from mailing lists. Future mail to it is delivered. Safe to retry after a failure. If the retry reports Address not found, the earlier call already landed.

allow_screened_address

Screen out an address at a domain. Future mail to it bounces back to the sender, waiting emails move to Trash, and those under 24 hours old are bounced too. Screen out adds a bounce rule to the inbox. Deleting the rule stops future bounces. Safe to retry after a failure. If the retry reports Address not found, the earlier call already landed.

block_screened_address

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. - Archived emails are included in results and carry `status: "archived"`. Deleted emails are filtered out; to look at the trash, 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>

search_emails

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`. - Attachments: call prepare_attachment_upload for each file, PUT the bytes to its `uploadUrl`, then pass the handles in `attachmentHandles`. Limits: 7 MB per file, 10 files and 7 MB total per email. If any handle is unknown, expired, or already used, nothing is sent. - 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>

send_email

Turn screening on or off for one of the user's domains. Turning on reports activating until it is ready; addresses that already receive mail keep working. Turning off releases everything still waiting and keeps earlier decisions. Matching rules can forward the released mail, send bounces, or unsubscribe from mailing lists. Works on any domain list_domains returns, including receive-only domains.

set_domain_screening

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_email_expiration

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>

set_email_status

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>

unsubscribe_email

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, the Everything view, the unscoped list_emails view, and get_triage_summary's category lists; `false` to make visible again. Inbox and category pages (and a category-scoped list_emails call) 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_category

Set or clear the name recipients see in From on mail sent from an inbox. <hints> - `inbox` is the local part, not the full address. - Pass `senderName: null` to clear it. - Safe to retry. </hints>

update_inbox

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` changes only the fields you send. Omitted fields stay unchanged; pass `null` for a field to remove that action. </hints>

update_inbox_rule

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.

update_ruleset

Update mutable match/action fields on a rule inside a ruleset. Pass `ruleId` plus any subset of matchText, matchLocation, always, action, or stopProcessing. Within `action`, omitted fields stay unchanged; pass null for a field to remove that action. The change applies to every inbox bound to the ruleset. Use `move_ruleset_rule` to reorder within the ruleset.

update_ruleset_rule