Back to tracker
Plugin tracker
Tools
Explore what tracked Claude Connectors and ChatGPT Plugins can actually do. Search by tool, Plugin, Brand, category, verb, or access requirement.
Latest snapshot2026-09-12USmethodology registry-public-v1
Searchable tools
113,018
Authless tools
7,424
Auth required
100,766
Described tools
61,167
113,018 tools
- ver_productover · Ficha de un producto por EAN (precio, disponibilidad, marca, categoría y link a la ficha web). No devuelve fotos. Medicamentos: no disponibles.Farmacia SianoFarmacia Siano
PluginrequiredCommerce - attach_ruleset_to_inboxattach · Attach a ruleset to one or more inboxes. The binding occupies one slot in the inbox's rule chain and expands in place at evaluation time to the ruleset's rules (in their own order). By default appends at the end; pass `position` for a specific slot. The same ruleset cannot be attached to one inbox twice.
`inbox` accepts a single inbox local part or an array; the response is always `{ rulesetId, bindings: [...] }` with one entry per inbox. Per-inbox failures surface in an `error` field on the entry without failing the whole call. Prefer the array form over a loop.Jade EmailJade EmailPluginrequiredProductivity
- create_categorycreate · Create a new email category.
<hints>
- `name` is the user's intended label. The slug (immutable lowercase identifier) is derived from it automatically. Pass a real human name like "Receipts"; the slug becomes "receipts".
- The slug must be unique per user. On collision the call errors with both the slug and the existing category's display name so you can tell the user which row blocks the new one.
- Names must be non-empty, ≤50 characters, and cannot be the reserved value "everything" (reserved for the unified inbox view).
- `color` is an optional hex string used only for UI display. Omit if the user didn't ask for one.
- `description` is optional free-form text (≤500 chars) the user can read in settings and that future agents will see in `list_categories` — use it to record the INTENT of the category ("order confirmations from US retailers", "newsletters I might read if I have time") so the right bucket is obvious later.
- `hidden` (optional, default false) suppresses the category from the sidebar and the unified Everything view. Inbox and category pages still surface its mail. Use this for buckets the user wants kept out of normal browsing (e.g. a "private" pile fed by inbox rules).
- Creating a category does NOT assign any existing emails to it. Use `recategorize_*` tools afterwards if the user wants historical mail moved.
</hints>Jade EmailJade EmailPluginrequiredProductivity
- create_inbox_rulecreate · Create a new inbox rule. By default appends at the end of the chain. Pass `position` to drop the rule at a specific slot in one call — the server resolves the intent and renumbers the chain for you.
<evaluation_model>
- Rules fire in ascending `order` (lowest first) on every incoming email.
- Each matching rule's category/status OVERWRITES the current value. The LAST matching rule wins — so a later "exception" rule can override an earlier "default" rule.
- `stopProcessing: true` halts the chain entirely at the point of the match. No later rules run. The stopProcessing rule's values become final.
- bounce, unsubscribe, and notify are side-effect actions that queue async work, not state changes — they fire every time the rule matches a new email.
- Rules apply to INCOMING mail only. To reclassify existing emails after a rules change, call recategorize_inbox or recategorize_category; use recategorize_emails only when you already have a specific id list.
</evaluation_model>
<hints>
- To build "default category X, except Y → category Z": create the default FIRST at `position: {kind: "first"}` with `always: true → X`, then create the override (later in the chain, matching Y → Z). Leave `stopProcessing: false` on both — the override wins via overwrite, not halting.
- To insert a rule between two existing rules, pass `position: {kind: "before", ruleId}` or `{kind: "after", ruleId}`. Don't hand-pick an integer; the server handles the math.
- The chain is always renumbered to sequential 1..N on every insert or move, matching the settings UI. Don't think of `order` as a stable integer — think of it as the position in the list.
- Set `always: true` with empty `matchText` and `matchLocation` arrays for a catch-all rule.
</hints>Jade EmailJade EmailPluginrequiredProductivity
- create_rulesetcreate · Create an empty named ruleset. Add rules with `create_ruleset_rule` then attach to inboxes with `attach_ruleset_to_inbox`.
<hints>
- `name` is non-empty, ≤100 chars, unique per user (case-insensitive).
- `description` is optional free-form (≤500 chars) — WRITE one describing the intent ("auto-unsubscribe + mark marketing") so future agents can pick the right ruleset.
- `isDefault: true` marks this as the default ruleset for NEWLY-created inboxes. At most one ruleset can be default; setting this clears any prior default. Existing inboxes are NOT retroactively bound.
</hints>Jade EmailJade EmailPluginrequiredProductivity
- create_ruleset_rulecreate · Append a rule to a ruleset. Same rule shape and evaluation semantics as `create_inbox_rule` — the rule fires when the ruleset is attached to an inbox and evaluation reaches its position in the chain.Jade EmailJade EmailPluginrequiredProductivity
- delete_categorydelete · Delete a category. This removes the category record but does NOT touch emails previously assigned to it — those emails keep the slug until recategorized.
<hints>
- If the user wants the emails moved, call `recategorize_category` BEFORE delete to shift them to a different bucket.
- Deleting a slug that doesn't exist throws "Category not found".
</hints>Jade EmailJade EmailPluginrequiredProductivity
- delete_inbox_ruledelete · Delete one or more inbox rules permanently. Pass an array of ruleIds to delete in one call; per-rule failures surface in the `errors` array without failing the whole call. The inbox chain tolerates gaps — deletions do not renumber surrounding rules.Jade EmailJade EmailPluginrequiredProductivity
- delete_rulesetdelete · Delete a ruleset and cascade: every binding from any inbox to this ruleset is removed, and every rule inside it is deleted. DESTRUCTIVE and wide-reaching — check `list_rulesets` for the `ruleCount` and use `list_inbox_rules` on the affected inboxes if you want to confirm the blast radius before calling.Jade EmailJade EmailPluginrequiredProductivity
- delete_ruleset_ruledelete · Delete a rule from its ruleset.Jade EmailJade EmailPluginrequiredProductivity
- detach_ruleset_from_inboxdetach · 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.Jade EmailJade EmailPluginrequiredProductivity
- forward_emailforward · 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>Jade EmailJade EmailPluginrequiredProductivity
- get_emailget · 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>Jade EmailJade EmailPluginrequiredProductivity
- get_email_attachmentget · 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>Jade EmailJade EmailPluginrequiredProductivity
- get_email_for_forwardget · 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>Jade EmailJade EmailPluginrequiredProductivity
- get_email_for_replyget · 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>Jade EmailJade EmailPluginrequiredProductivity
- get_rulesetget · 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.Jade EmailJade EmailPluginrequiredProductivity
- get_triage_summaryget · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_categorieslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_domainslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_emailslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_inbox_ruleslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_inboxeslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- list_rulesetslist · 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.Jade EmailJade EmailPluginrequiredProductivity
- list_sent_emailslist · 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>Jade EmailJade EmailPluginrequiredProductivity
- mark_category_readmark · 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>Jade EmailJade EmailPluginrequiredProductivity
- move_inbox_rulemove · 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>Jade EmailJade EmailPluginrequiredProductivity
- move_inbox_rulesetmove · 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.Jade EmailJade EmailPluginrequiredProductivity
- move_ruleset_rulemove · Reorder a rule within its ruleset. Returns the full renumbered list.Jade EmailJade EmailPluginrequiredProductivity
- recategorize_categoryrecategorize · 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>Jade EmailJade EmailPluginrequiredProductivity
- recategorize_emailsrecategorize · 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>Jade EmailJade EmailPluginrequiredProductivity
- recategorize_inboxrecategorize · 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>Jade EmailJade EmailPluginrequiredProductivity
- reorder_categoriesreorder · 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>Jade EmailJade EmailPluginrequiredProductivity
- search_emailssearch · 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>Jade EmailJade EmailPluginrequiredProductivity
- send_emailsend · 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>Jade EmailJade EmailPluginrequiredProductivity
- set_email_expirationset · 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>Jade EmailJade EmailPluginrequiredProductivity
- set_email_statusset · 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>Jade EmailJade EmailPluginrequiredProductivity
- unsubscribe_emailunsubscribe · 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>Jade EmailJade EmailPluginrequiredProductivity
- update_categoryupdate · 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>Jade EmailJade EmailPluginrequiredProductivity
- update_inbox_ruleupdate · 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>Jade EmailJade EmailPluginrequiredProductivity
- update_rulesetupdate · 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.Jade EmailJade EmailPluginrequiredProductivity
- update_ruleset_ruleupdate · Patch a rule inside a ruleset. Use `move_ruleset_rule` to reorder within the ruleset.Jade EmailJade EmailPluginrequiredProductivity
- Assign Form Field to Document Roledochub · Assign an existing form field to a document role so that role's signer fills it.
Side effects: changes field ownership only; never touches the field's value.
Works for any field type, including signature fields.
Primary use: resolving a PREPARING sign request draft when send validation
reports that a recipient "must be assigned at least one field or have
annotations enabled" — assigning an unassigned (or wrongly assigned) field
to the signer's role clears that blocker.
Required inputs:
- documentId: the draft's document id (not the template id).
- formfieldId: a field id on that document.
- documentRoleId: a role id on the same document. If the role does not exist
or belongs to a different document, the call fails with a not-found error.
Returns:
{"status": "success", "formfield": { ... }} — same field shape as the
form-field listing, with documentRole updated.
Use when: a draft's fields are unassigned or assigned to the wrong recipient.
Not for: setting field values, or creating new fields (place those in the
DocHub editor).DocHubDocHubPluginoptionalProductivity
- Create Sign Request Draft from Templatedochub · Create a DocHub sign request draft from a template document.
Side effects: creates a draft only. No emails are sent to signers until the
draft is finalized and sent.
Required inputs:
- documentId: a template document id (isTemplate=true).
- documentRoles: one entry per template role, each with id and email. Role
ids come from the template's roles; signer emails come from the user.
Name, queue order, and signer type come from the template. Each entry
accepts optional canAnnotate: true to grant the role's signer free
annotation of the document (write/draw anywhere as free content — it
does not make the template's fields fillable for them); omit it to keep
the template's stored role configuration. Creation fails with "must be
assigned at least one field or have annotations enabled" when a role has
neither assigned fields nor annotations — resolvable by re-calling with
canAnnotate: true for that role, or by assigning fields to the role in
the template (fullUrl).
Optional inputs:
- title: sign request title. Default: the template document's title.
- emailContent: invitation subject and/or body overrides. Any omitted field
falls back to its default; omitting emailContent entirely applies both.
Default subject: "ACTION NEEDED: {title}".
Default body: "Please review, sign, and complete this document."
{title} resolves to the effective title (custom if given, otherwise the
template title); pass plain values, not pre-interpolated strings.
Returns:
Success: {
"status": "success",
"signRequestId": str,
"documentUrl": str,
"title": str,
"emailSubject": str,
"emailBody": str
}
documentUrl is a link to review the draft before it is sent.
Use when: starting a role-based sign request from an existing template —
sending a templated contract or form out for electronic signature (esign).
Not for: regular imported/generated documents.DocHubDocHubPluginoptionalProductivity
- Create Sign Request from Documentdochub · Create a DocHub sign request from a regular (non-template) document.
Side effects: creates a sign request, usually in PREPARING/draft mode when
preparingEnabled is true; it is not sent until finalized.
Constraint: a regular document can have at most one sign request ever —
including one already sent, in progress, or completed. The DocHub API
enforces this and rejects a second attempt with a validation error. The
existing request appears in the sign-request listing under the same
document id. The same content can be reused by copying the document in
the DocHub web app, or via a template flow.
Required inputs:
- documentId: a regular imported/generated document id.
- signers: one or more signer email assignments; optional name and
queuePosition when provided. Optional canAnnotate (no default) grants the
signer free annotation — writing, drawing, or signing anywhere as free
content; it does not make form fields fillable, since a field can be
completed only by the signer whose role it is assigned to. A PREPARING
draft may be created with signers that have neither assigned fields nor
the grant — its roles are created with it, and sending stays blocked
until every recipient has at least one field or annotations enabled.
Immediate sends (preparingEnabled=false) require each signer to carry
canAnnotate=true or match an existing role with assigned fields at
creation time; older DocHub servers enforce this for drafts as well.
Optional inputs:
- ownerEntityId: inferred from the authenticated DocHub user when omitted.
- title: sign request title. Default: the document's title.
- emailContent: invitation subject and/or body overrides. Any omitted field
falls back to its default; omitting emailContent entirely applies both.
Default subject: "ACTION NEEDED: {title}".
Default body: "Please review, sign, and complete this document."
{title} resolves to the effective title (custom if given, otherwise the
document title); pass plain values, not pre-interpolated strings.
- preparingEnabled: defaults to true (review before sending).
Returns:
Success: {
"status": "success",
"signRequestId": str,
"signRequestStatus": str,
"documentUrl": str | null,
"documentId": str | null,
"signerIds": [str],
"title": str,
"emailSubject": str,
"emailBody": str
}
DocHub validation errors (signer emails, missing fields, document state)
are returned in the response.
Use when: sending a regular generated/imported document for signature or
esign — "send this for signature", "get this contract e-signed" — when it
does not have a sign request yet.
Not for: template role-based flows, or a document that already has a sign
request (see Constraint).DocHubDocHubPluginoptionalProductivity
- Fill Form Field on DocHub Documentdochub · Set the value of a fillable form field (PUT /api/v2/formfields/:formfield_id).
Side effects: overwrites the field's current value (idempotent for the same value).
Only fields marked ``isFillable: true`` in the form-field listing can be
updated: ``ftText`` and ``dhAutoDate`` (string ``value``) or ``ftCheckBox``
(boolean ``value``). Pass ``ffType`` exactly as returned for that field.
Permissions: ``isFillable: true`` fields may be filled when ``documentRole``
is null (unassigned) or when ``documentRole.email`` matches the
authenticated user's email. Fields assigned to a different email are
rejected by the API. Role assignment is not a prerequisite for filling.
Returns:
{"status": "success", "formfield": { ... }} — same field shape as the
form-field listing.
After success, present `documentUrl` from the prior form-field listing as a clickable link.
Use when: setting text, auto-date display text, or checkbox state on a
fillable field — "fill out this form", "complete my part of the
document".
Not for: non-fillable field types (signatures, radio groups); fields
assigned to a different signer.DocHubDocHubPluginoptionalProductivity
- Generate Document PDFdochub · Generate a professional PDF document from a natural-language request —
contract, agreement, invoice, lease, NDA, letter, receipt, or a custom
type. On
success the document is saved to DocHub and its URL and an inline PDF
preview are returned.
Response `status` is one of:
- "needs_more_info": required details are missing. `fields` lists the
information still needed; a retry supplies those values in `sourceFacts`,
repeats the same `request`, and sets `previousRunId` to the returned
`runId`.
- "success": contains `documentId`, `documentUrl`, and `pdfUrl`.
- "error": contains a user-ready `message` and an `errorCode`.
`upgrade_required` means a free/basic-plan limit was reached;
`ai_rate_limit_exceeded` means a paid plan's AI allowance is used up;
`documentProduced: true` means the PDF was produced but could not be
saved to DocHub.
Use when: the user asks for any drafted document — "draft a contract",
"write up a lease", "make me an invoice".
Not for: retrieving or editing existing DocHub documents.DocHubDocHubPluginoptionalProductivity
- Get Current Authenticated DocHub Userdochub · Get the current authenticated user's profile from DocHub.
Returns:
{"status": "success", "user": {"id": str, "name": str, "email": str,
"createdAt": str | null, "entityId": str, "timezone": str | null}}
"timezone" is the IANA timezone saved in the user's DocHub preferences;
null when unset.
Use when: checking who is logged in, verifying authentication, or
looking up the saved timezone for presenting timestamps.
Not for: looking up other users.DocHubDocHubPluginoptionalProductivity
- Get Document from DocHubdochub · Get a document from DocHub by its ID.
Fetches document metadata and a signed PDF download URL in parallel.
Returns:
Text JSON: {"status": "success", "document": {"id": str, "title": str,
"fullUrl": str | null, "isTemplate": bool, ...}}
structured_content: same document fields plus {"pdfUrl": str,
"pdfUrlExpiresIn": int} for the PDF viewer widget.
Use when: retrieving a specific document by a known ID.
Not for: unknown document IDs — find one via a document listing first.DocHubDocHubPluginoptionalProductivity
- Get Sign Request Details from DocHubdochub · Fetch detailed info on a single DocHub sign request.
Returns per-signer status, viewedAt / signedAt timestamps, signer
emails, and queue positions in addition to the list-view fields.
Returns:
{
"status": "success",
"signRequest": {
"id": str, "status": str, "createdAt": str, "updatedAt": str,
"sender": "me" | "others",
"document": {"id": str, "title": str, "fullUrl": str},
"signers": [{
"name": str, "email": str, "isCurrentUser": bool,
"status": str, "viewedAt": str | null,
"signedAt": str | null, "queuePosition": int | null,
}],
}
}
Use when: answering "who hasn't signed yet?", "when did X sign?", or any
question needing per-signer timestamps.
Not for: listing multiple sign requests.DocHubDocHubPluginoptionalProductivity
What is Tool Explorer?
Tool Explorer indexes the callable tool names and descriptions attached to public registry profiles. It is useful for seeing what agents can actually invoke, not just which profile exists.
How do category and verb filters work?
Category filters use the live registry category rollup. Verb filters use the public tool insights rollup, so the page stays backed by the same read models as the tracker charts.
Why do auth requirements matter?
Auth requirements show whether a tool is likely usable without account connection, requires authentication, is private, or is unknown in the current snapshot.