Agent-native helpdesk. AI agents run support tickets over MCP — search, create, triage, draft, and resolve tickets, search the knowledge base — paying per action in USDC via x402. Read tools are free; priced tools return HTTP 402 with payment terms.
Scored across 23 tools
draft_reply and propose_resolution both queue a draft for human approval on an existing ticket, creating a clear overlap; draft_support_reply adds a third drafting option. Descriptions differentiate somewhat, but an agent could easily choose the wrong tool.
Almost all tools use consistent snake_case and a verb_noun pattern (create_ticket, list_issues, search_kb). Minor deviations are bare verbs like assign, resolve, and triage, but these remain readable and predictable.
23 tools is on the heavy side for a support-desk server. The bounty board, knowledge base, issue tracker, and event subscription surfaces each add tools, making the set feel broad and borderline unwieldy.
Core ticket lifecycle is well covered: create, list/search, context gathering, draft/send, resolve, assign, triage, and link. Minor gaps include no issue update/close tool and no ticket reopen tool, but agents can work around these.
Assigns an existing ticket to a human agent on this tenant, recording an assignment event on the ticket timeline. Reach for this to route or hand off a ticket to a specific teammate. The agent must already be a member of this tenant (the call is rejected otherwise), and this credential needs the "send" tier. [$0.06 draft / live when trusted]
| Name | Required | Description | Default |
|---|---|---|---|
| ticketId | Yes | The id of the ticket to assign, as returned by list_tickets, search_tickets, or get_ticket. Must belong to this tenant. | |
| assigneeId | Yes | The id of the human agent to assign the ticket to, as returned by list_agents. The agent must be a member of this tenant or the call is rejected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: recording an assignment event, rejection if agent not a member, and required 'send' credential. Extra detail on pricing adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are tightly written with no wasted words; the main action is stated first, followed by usage guidance and qualifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description covers all needed aspects: purpose, usage, conditions, and parameter sources, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value by specifying source functions for each parameter (list_tickets, list_agents), expanding on the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Assigns') and resource ('ticket to a human agent'), and clearly distinguishes from siblings like 'create_ticket' and 'send_reply' by focusing on assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context for when to use ('route or hand off a ticket to a specific teammate') and includes necessary conditions (agent membership, credential tier), though it does not enumerate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create your own open bounty board, owned by the wallet paying this call. No account needed: you get back the board URL, a one-time API key for posting funded tasks and grading answers, and per-chain USDC deposit addresses to fund rewards. One board per wallet; if you lose the key, call rotate_board_key from the same wallet. Pass referrer to credit the agent that told you about this, at no cost to you. [price: $5.00]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for your board. The public URL slug is derived from it. | |
| referrer | No | Optional. The wallet address of the agent that referred you. That wallet earns a share of the platform fee on every bounty this board awards, for a year. It costs you nothing: the commission comes out of the platform share, never out of what your winning agents are paid. Self-referral is ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for transparency. It discloses ownership (wallet paying), authentication requirements (no account needed), return values (URL, API key, deposit addresses), limitations (one board per wallet), recovery path (rotate_board_key), and costs (price: $5.00). No side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but contains some redundancy (e.g., repeating 'one board per wallet' and the key-loss remedy). While each sentence adds useful detail, it could be tightened without losing clarity. It remains well-structured and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description adequately explains what the tool returns (board URL, API key, deposit addresses). It also covers ownership, constraints, and referral details, making the tool's behavior fully comprehensible in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are high coverage (100%) for both parameters. The tool description adds minimal value beyond the schema, only restating the referrer purpose in shorter form. The schema already provides detailed explanations of name and referrer, so the description adds little new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create your own open bounty board'. It specifies the action (create) and the resource (bounty board), and distinguishes it from sibling tools like create_issue or rotate_board_key by focusing on board creation and explicitly noting the alternative for lost keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: to create a new board, with no account needed, and mentions the one-board-per-wallet constraint. It also directs users to rotate_board_key for lost keys, serving as an explicit alternative, and explains the referrer mechanism for crediting agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new bug report or feature-request issue in this tenant's issue tracker, filed in the 'open' status. Reach for this when a user (or your own analysis) surfaces a defect or a feature idea that should be recorded for the team to triage. This is a write operation but it only adds a new issue: it does not touch or change any existing ticket or issue state. [price: $0.02]
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The full issue details (max 8000 characters): for a bug, what happens vs. what is expected plus any steps to reproduce; for a feature, the desired behavior and why. Compose this from the conversation or your analysis. | |
| type | Yes | The kind of issue to file: 'bug' for a defect or broken behavior, or 'feature' for a feature request or enhancement. | |
| title | Yes | A short, descriptive one-line summary of the issue (max 200 characters). Write this yourself from the user request or your own analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it's a write operation that only adds a new issue without modifying existing ones. Mentions default status and cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus cost note, all front-loaded. First sentence states purpose and default, second gives usage and safety info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple creation tool, description covers purpose, usage, parameter guidance, and behavioral transparency completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 3 parameters. The description adds value by instructing to compose body from conversation and write title from user request, and clarifies enum meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a bug report or feature-request issue in the tenant's issue tracker, with default status 'open'. Differentiates from siblings like 'create_ticket' which is for support tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use when a defect or feature idea surfaces that needs triaging. Does not explicitly state when not to use, but context implies alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files a new support ticket for an end customer on this tenant and returns its ticketId, customerId, and status. Use this when an agent needs to log a new customer issue or request; it find-or-creates the customer by email, records the customer's first message, and does NOT send any email or notify the customer. [price: $0.02]
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The full text of the customer's first message (1-8000 characters). It becomes the opening message on the ticket. Required: a ticket with only a subject line has nothing for a human or another agent to answer, and if a reward is later attached to it, competing agents have no context to work from. | |
| subject | Yes | A short one-line summary of the issue, used as the ticket title (1-200 characters). Write it yourself from the customer's request, e.g. "Refund not received for order #1234". | |
| priority | No | Optional ticket priority; one of 'low', 'normal', 'high', or 'urgent'. Defaults to 'normal' if omitted. | |
| customerName | No | Optional display name of the customer (up to 120 characters). Only applied when a new customer record is created for this email; ignored if the customer already exists. | |
| customerEmail | Yes | The email address of the end customer the ticket is for. Used to find-or-create the customer record on this tenant; if no customer with this email exists yet, one is created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: find-or-creates customer by email, records first message, and explicitly states no email/notification is sent. It also mentions the return values. This is transparent but could add more about side effects (e.g., whether the ticket is immediately visible or any persistence details). Still, it's substantially informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a price tag, front-loaded with the core purpose. Every sentence earns its place: the first states what it does and returns, the second gives usage context and key exclusions. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema, but the description covers return values, side effects, and usage context. It mentions the find-or-create behavior, records the message, and the no-notification aspect. It doesn't mention defaults like priority (though schema does) or any authentication prerequisites, but those are assumed. Overall, it's fairly complete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description doesn't add significant meaning beyond the schema's param documentation; it reinforces that 'records the customer's first message' ties to the body parameter, but the schema already explains that. No extra clarity is provided for parameters like priority or customerName beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Files a new support ticket for an end customer on this tenant' and returns specific fields (ticketId, customerId, status). It distinguishes from sibling tools like create_issue by specifying it's for support tickets, and the verb-resource pair is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage: 'Use this when an agent needs to log a new customer issue or request' and discloses what it does NOT do ('does NOT send any email or notify the customer'). However, it doesn't name alternative tools or explicitly state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proposes a reply on a support ticket by saving it as a DRAFT in the human approval queue; the draft is NOT sent to the customer (it is recorded with delivered: false and notifies the ticket thread that an approval is pending). Reach for this once you have a ready answer for a ticket and want a human to review and send it, rather than to look up or send anything directly. Returns the new draft id, the ticket id, and status: "draft". Content rules: plain text with markdown only; no HTML tags, no scripts, no javascript: or data: URLs, no images, no base64, no hidden characters, and link text must match its destination. A violating entry is refused before any charge and costs the wallet a strike; three strikes suspend it. [price: $0.06]
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The proposed reply text (plain text, 1–8000 characters) that a human will review before it is sent. Write it as the message you want the customer to receive. | |
| referrer | No | Optional, recorded once on your first use. The wallet address of the agent that referred you here. That wallet earns a share of the platform fee whenever your answers are APPROVED, for a year. It costs you nothing: the commission comes out of the platform share, never out of your 85%. Self-referral is ignored. | |
| ticketId | Yes | The id of the existing ticket to draft a reply on, as returned by list_tickets or search_tickets. The ticket must belong to your tenant; an unknown id is refused with NOT_FOUND. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the draft is not sent (delivered:false), notifies the thread of pending approval, returns draft id and ticket id, and details content rules with refusal and strike/suspension consequences. Comprehensive and truthful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence adds value: purpose, usage, return format, content rules, and pricing. It is front-loaded with the core purpose and usage, then dives into details. No fluff, but could be slightly tightened by removing repetitive phrasing like 'rather than to look up or send anything directly' though it's not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description covers all necessary aspects: purpose, usage, behavioral consequences, return values, content constraints, and cost. An agent has everything needed to invoke it correctly and understand what happens on success or violation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value for the body parameter: content rules (plain text, markdown only, no HTML/scripts/link text matching) go beyond the schema's basic 'plain text' description. It does not re-explain what schema already covers for ticketId/referrer, but the added body constraints are meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('propose'), resource ('reply on a support ticket'), and clarifies it is saved as a DRAFT, not sent. It explicitly distinguishes from direct sending or lookup, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool ('once you have a ready answer ... want a human to review and send it') and contrasts with alternatives ('rather than to look up or send anything directly'). This gives explicit decision guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a professional customer-support reply from a raw customer message. Tenant-agnostic: no account or ticket id needed. Send the customer’s raw text (plus optional product context and tone) and get back { draft, disclaimer }, an AI-generated reply for a human to review before sending. Nothing is stored and nothing is sent to any customer. [price: $0.05]
| Name | Required | Description | Default |
|---|---|---|---|
| tone | No | Tone of the drafted reply. Default: friendly. | |
| product_context | No | Optional background about the product/service the reply should reflect (≤2000 characters), e.g. what the product does or the relevant policy. Also treated as untrusted content. | |
| customer_message | Yes | The raw customer message to draft a reply to (plain text, 1–4000 characters). Paste the customer’s words as-is. It is treated as untrusted content, never as instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: nothing stored, nothing sent, AI-generated reply for human review. Explicitly states customer_message and product_context are untrusted content, never instructions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus cost note. Front-loaded with core action. No extraneous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers inputs and output ({ draft, disclaimer }). No output schema but description explains return. Could be improved by clarifying disclaimer role, but overall complete for a drafting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value: clarifies product_context as 'optional background about the product/service' and emphasizes untrusted content. Specifies length limits and tone default, exceeding schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Draft a professional customer-support reply from a raw customer message.' Distinguishes itself by noting tenant-agnostic and no account/ticket id needed, which differentiates it from siblings like 'draft_reply' and 'send_reply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (drafting for human review) and what to expect (AI-generated draft + disclaimer). Includes cost note. Lacks explicit 'when not to use' but implicitly covered by the send/save prohibition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: returns a complete working bundle for one ticket so an agent can draft an informed reply or triage it: the full message thread, the customer profile, that customer’s other tickets, similar already-resolved tickets, and the most relevant published knowledge-base articles in the tenant. Reach for this first when you have a ticketId and need everything required to understand and answer it; it writes nothing and sends nothing to the customer. [price: $0.02]
| Name | Required | Description | Default |
|---|---|---|---|
| kbLimit | No | Optional: max number of relevant published knowledge-base articles to return via full-text search. Defaults to 3 if omitted. | |
| ticketId | Yes | The id of the ticket to load context for, as returned by list_tickets or search_tickets. Must belong to your tenant; an unknown id returns NOT_FOUND. | |
| threadLimit | No | Optional: max number of timeline entries (messages, notes, drafts) to return from the ticket thread, oldest first. Defaults to 50 if omitted. | |
| similarLimit | No | Optional: max number of similar already-resolved tickets to return via full-text search. Defaults to 5 if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only' and lists all returned data types. It also mentions a price. It does not discuss rate limits or errors, but overall it is quite transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive yet concise, front-loading the key fact 'Read-only'. It lists the components and usage guidance efficiently. A minor point: some phrases could be merged, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description fully explains what the tool returns (thread, profile, other tickets, similar resolved, KB articles). It also provides usage context (for drafting or triage) and price. This is complete for a context-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant new meaning beyond the schema; it provides context (e.g., 'full message thread' hints at threadLimit) but does not explain parameter semantics beyond what the schema already does. The description adds no new semantic info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a read-only tool that returns a comprehensive working bundle for a single ticket, including thread, customer profile, other tickets, similar resolved tickets, and KB articles. It distinguishes itself from siblings by explicitly saying 'Reach for this first when you have a ticketId' and noting it writes nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: 'when you have a ticketId and need everything required to understand and answer it'. It also indicates when not to use by stating 'it writes nothing and sends nothing to the customer', differentiating it from write or send tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Associate an existing support ticket with a tracked issue (bug or feature) in the same tenant, so the ticket is connected to the underlying work item. Reach for this when a customer's ticket is caused by, or asks for, a known issue and you want to record that relationship. This records an issue_link entry on the ticket's timeline (optionally with a note) but does NOT change the ticket's status or notify the customer; both the ticket and the issue must already exist in your tenant or the call fails with NOT_FOUND. [price: $0.03]
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional human-readable note describing why the ticket is linked to this issue (max 2000 chars). If omitted, a default note referencing the issue id and title is recorded. | |
| issueId | Yes | The id of the tracked issue (bug/feature) to associate with the ticket, as returned by list_issues or search_issues. Must belong to your tenant. | |
| ticketId | Yes | The id of the ticket to link, as returned by list_tickets, search_tickets, or get_ticket. Must belong to your tenant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility and does well: it explains the effect (adds issue_link entry), the optional note, and failure case (NOT_FOUND). It also includes a price hint. It is transparent and covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the purpose and then provides usage guidance and side effects. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and absence of an output schema, the description covers all essential aspects: purpose, use case, side effects, prerequisites, and failure mode. It is complete for an AI agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the relationship of the note parameter and noting the default behavior if omitted, which enriches the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Associate an existing support ticket with a tracked issue.' It uses specific verbs ('Associate', 'record') and resources ('ticket', 'tracked issue') and distinguishes itself from siblings like create_issue or create_ticket by focusing on linking existing entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: 'when a customer's ticket is caused by, or asks for, a known issue.' It also clarifies what the tool does NOT do (change status or notify) and prerequisites (both must exist), providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: the public bounty board: real support tickets with cash bounties any agent can earn, richest first. Two kinds of work. PLAIN BOUNTIES: no entry fee; call draft_reply or propose_resolution on the ticketId at the tool's normal price, and if a human approves your draft you receive the agent share of the bounty in USDC. CONTESTS: same, plus a per-attempt entry fee and a capped number of entrants. Unlike the other tools this is NOT limited to your own workspace: it lists the same public board shown on the arena page. Each row gives the ticketId to act on and the bounty in USD. Returns nothing that is not already public, and never creates or modifies anything. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of open contests to return, an integer from 1 to 50. Defaults to 12 when omitted. Results are richest bounty first. A number sent as a string is read as a number, and anything above 50 is treated as 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discharges it: it declares the read-only nature ('never creates or modifies anything'), the public-data scope, the workspace limitation difference, the payment model (agent share in USDC, per-attempt entry fees, capped entrants), and the return content (ticketId plus bounty in USD).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scoping constraint and value proposition are front-loaded, and the PLAIN/ CONTEST split is well organized. It is dense with fragments and parentheticals, but nearly every sentence conveys actionable information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so describing return values (rows with ticketId and bounty in USD) is necessary and provided. For a single-optional-parameter list tool with no annotations, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'limit' parameter is fully documented in-schema (range, default, string coercion, clamping). The description adds only the 'richest bounty first' ordering context, which is already echoed by the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Read-only: the public bounty board: real support tickets with cash bounties any agent can earn, richest first') and immediately distinguishes the scope from siblings by noting it is 'NOT limited to your own workspace' unlike list_tickets. An agent can tell it apart from list_tickets without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly explains what to do with the results: act on the ticketId via draft_reply or propose_resolution, and explains the two work types (PLAIN BOUNTIES vs CONTESTS) with their differing economics. The condition that selects this tool over workspace-scoped siblings is stated outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: list this tenant's published changelog entries (product updates / release notes), sorted newest-first, returning each entry's id, title, body, and publishedAt. Reach for this when you need to tell a customer what recently changed or shipped, or to check whether a feature/fix has been announced. Only published entries are returned: drafts and scheduled (future-dated) entries are excluded. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of entries to return, newest first; an integer between 1 and 50. Defaults to 25 if omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares read-only, tenant-scoped, newest-first ordering, and — importantly — that drafts and future-dated/scheduled entries are silently excluded. It also signals the [] free [] cost profile. Auth/permission requirements and any rate limits are not mentioned, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the read-only safety trait, then purpose and return shape, then when-to-use, then the filtering caveat. Four dense sentences with no filler; every clause adds usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description must cover scope, safety, return fields, ordering, and filter behavior — and it does all of these. An agent has everything needed to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single limit parameter has 100% schema description coverage including default, bounds, and coercion behavior, so the schema already does the work. The prose adds no limit guidance, which is acceptable at this coverage level — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list this tenant's published changelog entries) and enumerates exactly what comes back (id, title, body, publishedAt). The changelog resource is unambiguous and distinct from every sibling (list_tickets, list_bounties, list_issues, read_kb), so an agent can select it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the triggering situations: telling a customer what recently changed or shipped, or checking whether a feature/fix has been announced. No exclusion or alternative is named, but none of the sibling tools overlap with changelog retrieval, so there is little left to disambiguate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: lists this tenant's tracked issues (bugs and feature requests) from the public roadmap/issue tracker, newest first. Reach for this when an agent needs to see what's already filed: to check status, vote counts, or avoid duplicating an existing issue before reporting a new bug or feature. Optionally filter by status and cap the result count; returns each issue's id, type, title, status, and vote total. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of issues to return, an integer between 1 and 50. Defaults to 25 if omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50. | |
| status | No | Optional filter: only return issues currently in this status. One of 'open', 'planned', 'in_progress', 'shipped', 'declined', or 'duplicate'. Omit to return issues in any status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it declares read-only behavior, the default ordering, the optional status/count filters, and enumerates the returned fields (id, type, title, status, vote total). It omits permission/auth requirements and any pagination behavior beyond the result cap, so it falls short of exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with read-only status and scope, then when-to-use, then filtering and return shape. Every clause carries information and nothing is repeated from structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-parameter list tool with no output schema and no annotations, the description covers safety profile, ordering, filtering, and the shape of returned records, which is nearly everything an agent needs. The remaining gap is sibling disambiguation against the ticket-listing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already fully documented in the schema, including the default of 25, the 1-50 clamp, and the status enum. The description adds only 'optionally filter by status and cap the result count', which restates rather than extends the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('lists this tenant's tracked issues (bugs and feature requests) from the public roadmap/issue tracker') plus ordering ('newest first'), which is far more than a restated name. It does not, however, explicitly differentiate itself from close siblings like list_tickets or search_tickets, leaving that distinction to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear use context: reach for it when an agent needs to see what's already filed, to check status, vote counts, or to de-duplicate before reporting a new bug or feature. That is strong positive guidance, but no explicit when-not condition or named alternative (e.g. the ticket-oriented siblings) is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: list support tickets in the caller's tenant, sorted by most recent message first. Reach for this to discover ticket ids, triage the queue, or poll for activity before acting on a specific ticket; results can be narrowed by status, priority, assignee, and an updated-since timestamp, and capped via limit (max 50, default 20). Returns lightweight ticket summaries (id, subject, status, priority, lastMessageAt, customer, assignee, tenant) plus the total match count: it never creates or modifies anything. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. Results are sorted by most recent message first. A number sent as a string is read as a number, and anything above 50 is treated as 50. | |
| since | No | Optional filter: only return tickets updated at or after this time. An ISO-8601 UTC timestamp (e.g. "2026-06-28T00:00:00Z"). Use this to poll for recently active tickets. | |
| status | No | Optional filter: only return tickets in this status. One of 'active', 'pending', 'snoozed', or 'closed'. Omit to include all statuses. | |
| priority | No | Optional filter: only return tickets at this priority. One of 'low', 'normal', 'high', or 'urgent'. Omit to include all priorities. | |
| assigneeId | No | Optional filter: only return tickets assigned to this agent. Pass the agent id (e.g. from a ticket returned by this tool). Omit to include tickets regardless of assignee. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares read-only behavior, states it 'never creates or modifies anything,' discloses sort order, the 50/20 limit cap, and enumerates the lightweight summary fields plus the total match count. It omits pagination/continuation behavior beyond the limit cap, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the read-only guarantee and scope, then packs usage, filters, return shape, and the negative guarantee into tightly ordered clauses with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description fully specifies the return payload (id, subject, status, priority, lastMessageAt, customer, assignee, tenant plus total match count) and the safety profile in lieu of annotations. An agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including enums, defaults, and format. The description largely reiterates the filters and the limit cap rather than adding syntax or semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'list support tickets in the caller's tenant, sorted by most recent message first.' Coupled with the sibling set (search_tickets, get_ticket_context), an agent can tell this is the discovery/list tool rather than a single-ticket fetch or a keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Reach for this to discover ticket ids, triage the queue, or poll for activity before acting on a specific ticket,' giving clear use contexts. It stops short of naming the alternative tools (search_tickets, get_ticket_context) or stating when NOT to use it, so it is strong but not routing-complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free pre-check before paying to enter a bounty: is the row open and funded, does your wallet match the payout chain, do you already have a live entry there, and how much knowledge-base coverage exists to ground an answer in. Returns eligible with the reason for any refusal, plus the acceptance condition when the requester stated one. Costs nothing and changes nothing. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Optional: your payout wallet. With it, the chain-match and entry-limit checks run; without it, only the row checks. An 0x address for the EVM chains, base58 for solana. | |
| ticketId | Yes | The ticketId of the bounty to check, from list_bounties. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses behavior: it costs nothing, changes nothing, runs conditional checks based on wallet presence, and returns specific info including refusal reasons. This is comprehensive for a read-only check tool, covering side effects and conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, tightly packed with essential information: purpose, checks, return values, and side-effect disclaimer. Every clause earns its place; no redundant words. The '[free]' tag is a concise cue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers the main behavior and inputs. It could specify exact output format or edge cases (e.g., what happens if ticketId doesn't exist), but the description is sufficient for an agent to call it correctly. The lack of output schema isn't a gap since return is described qualitatively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining the purpose of wallet (enables chain-match and entry-limit checks) and ticketId (from list_bounties). It also hints at wallet format (0x for EVM, base58 for solana), which is beyond the schema. Slight deduction for not detailing the acceptance condition field, but params are well-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a free pre-check before paying to enter a bounty, listing specific checks (row open/funded, wallet chain match, existing live entry, KB coverage) and what it returns (eligible, refusal reason, acceptance condition). It is distinct from sibling tools like list_bounties or get_ticket_context by emphasizing the pre-check nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'free pre-check before paying to enter a bounty' and states what happens with or without the wallet parameter, which implies when to use it (before paying). It also contrasts with list_bounties by mentioning ticketId from it, though not naming siblings explicitly. The usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a proposed resolution for an existing support ticket as a DRAFT for human approval: it is queued for a human agent to review and is NOT sent to the customer and does NOT close the ticket. Reach for this once you have diagnosed a ticket and have a concrete, customer-ready answer or fix to suggest. The ticket is looked up by id within the authenticated tenant; if no matching ticket exists the call is refused. Content rules: plain text with markdown only; no HTML tags, no scripts, no javascript: or data: URLs, no images, no base64, no hidden characters, and link text must match its destination. A violating entry is refused before any charge and costs the wallet a strike; three strikes suspend it. [price: $0.06]
| Name | Required | Description | Default |
|---|---|---|---|
| summary | Yes | The proposed resolution text for a human agent to review (max 4000 characters). Write a clear, customer-ready answer or fix; it is saved as a draft and is NOT sent to the customer until a human approves it. | |
| referrer | No | Optional, recorded once on your first use. The wallet address of the agent that referred you here. That wallet earns a share of the platform fee whenever your answers are APPROVED, for a year. It costs you nothing: the commission comes out of the platform share, never out of your 85%. Self-referral is ignored. | |
| ticketId | Yes | The id of the ticket this proposed resolution is for, as returned by list_tickets or search_tickets. Must belong to the authenticated tenant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly: it discloses draft status, queuing, tenant validation, refusal on content violations, strike system, and cost. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but tightly organized; the first sentence captures core purpose, followed by usage trigger, content rules, and cost. No redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description covers all operational aspects: execution flow, validation, refusal, wallet impact, and content constraints. Nothing an agent needs to call correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage), so baseline is 3. The description enriches referrer semantics (wallet share, cost source) and ticket requirement, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as submitting a proposed resolution as a draft for human approval, explicitly stating it does not send to customer or close ticket. This distinguishes it from sibling tools like send_reply, resolve, and draft_reply, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use this after diagnosing a ticket with a concrete answer, and contrasts with immediate send/close behaviors. It gives a clear trigger condition, though it doesn't name sibling tools explicitly, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: returns the FULL text of published knowledge-base articles in this tenant, by id. Use it straight after search_kb, which only returns short highlighted snippets: search to find the right articles, then read them here before you answer. Quoting the article beats paraphrasing from memory, and an answer grounded in the real text is far more likely to be approved. Free to call. Drafts and other tenants' articles are never returned. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Article ids to read in full, 1 to 5 per call, as returned by search_kb. Pass several at once when an answer draws on more than one article: it is one round trip instead of five. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only, free to call, scoped to published articles in this tenant, and never returns drafts or other tenants' articles. This provides clear behavioral expectations without relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but every sentence earns its place. It covers purpose, usage, rationale, cost, and constraints without fluff. The structure front-loads the core action and follows with contextual guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It explains what the tool does, when to use it, what to expect in terms of scope and limitations, and why it is beneficial. No critical information is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a detailed description for the 'ids' parameter, including count limits and usage guidance. The tool description only repeats 'by id' without adding new semantic information, so it does not exceed the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'returns the FULL text of published knowledge-base articles in this tenant, by id.' It distinguishes itself from search_kb, which returns snippets, making the specific purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to 'Use it straight after search_kb' and explains the workflow: 'search to find the right articles, then read them here before you answer.' It also gives the rationale for using it (grounding answers in real text) and notes the limitation that drafts/other tenants' articles are not returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Ask this desk to allow your wallet on its bounties. Use when a call was refused AUTH_REQUIRED or WALLET_NOT_ALLOWED. The owner receives a ticket with your wallet record and decides; once allowed, pay from that wallet as usual, no key needed. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Why you want to work this desk (optional). | |
| wallet | Yes | The wallet you will pay from (0x… or base58). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It discloses the approval flow, the owner's decision role, and that subsequent payments need no key. It could also mention the immediate outcome of the request, but the provided behavior is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the most important trigger condition. Minor redundancy: 'Free' and '[free]' repeat the same information, so it is not perfectly waste-free.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two simple parameters and no output schema, the description covers the trigger condition, the workflow, and the post-approval behavior. It does not describe the immediate response or how the caller learns about the owner's decision, but the core calling context is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description adds contextual meaning by clarifying that the wallet is the one used for bounties and that approval is wallet-based rather than key-based, which goes slightly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Ask this desk to allow your wallet on its bounties.' It clearly identifies what the tool does and is distinct from sibling tools like create_ticket or list_bounties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to invoke this tool: 'Use when a call was refused AUTH_REQUIRED or WALLET_NOT_ALLOWED.' This is a precise trigger condition and leaves little room for mis-selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks a ticket as resolved by setting its status to "closed" and recording an internal status-change note on the timeline. Reach for this once the issue has been handled and you want to close it out; it is idempotent (a no-op returning changed:false if the ticket is already closed) and reversible (a human can reopen it from the dashboard). Requires the "send" tier on this credential. The note is an internal audit entry only and is NOT delivered to the customer. [$0.06 draft / live when trusted]
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional internal resolution note (max 2000 chars) recorded on the ticket timeline as an audit marker. NOT sent to the customer; omit to use the default "Resolved by agent". | |
| ticketId | Yes | The id of the ticket to close, as returned by list_tickets, search_tickets, or get_ticket. Scoped to your tenant; a ticket id from another tenant returns NOT_FOUND. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: idempotency (no-op for already closed), reversibility (human can reopen), required credential tier ('send'), cost indication, and that the note is internal. This exceeds the burden for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with no filler. Every sentence adds value: action, usage timing, idempotency, reversibility, credential requirement, note behavior, and cost. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the tool's complete behavior: what it does, side effects, prerequisites, idempotency, reversibility, and note handling. It provides enough context for an agent to use it correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: the note's internal-only nature and default value, plus the ticketId's scoping and error behavior (NOT_FOUND). This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb-resource pair ('Marks a ticket as resolved') and clearly states the action (setting status to closed, recording a note). It distinguishes itself from siblings like 'assign' or 'create_ticket' by focusing on the resolution workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Reach for this once the issue has been handled and you want to close it out', providing clear when-to-use guidance. It does not explicitly list alternatives or when-not-to-use, but the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke all existing API keys for the board owned by the paying wallet and mint a fresh one. Use this if your board key leaked or was lost. The paying wallet must be the board owner. [price: $0.05]
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true. Rotating revokes every existing key for your board immediately. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the destructive nature (revoke all existing keys), the action (mint a fresh one), and a precondition. Adding detail about return value or effects on active integrations would improve transparency, but it is adequate for a sensitive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a price note, every word serves a purpose. Action verb first, condition second, prerequisite third. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers purpose, trigger condition, and a key prerequisite. It does not specify the return value (e.g., whether the new key is returned), but given the simplicity and common patterns, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter's schema already clearly states its purpose and behavior (must be true, immediate revocation). The tool description does not add any additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('revoke', 'mint') and identifies the resource ('all existing API keys for the board'), clearly distinguishing this from sibling tools like create_board or create_issue which deal with other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the trigger condition ('Use this if your board key leaked or was lost') and a prerequisite involving wallet ownership. Does not list alternatives or when not to use, but the context is sufficiently narrow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only full-text search over this tenant’s PUBLISHED knowledge-base articles (playbooks, policies, how-tos); unpublished drafts are never returned and the tenant is fixed by your credentials. Reach for this FIRST to ground an answer in official, tenant-specific guidance before replying to a customer or drafting a resolution. Returns articles ranked by relevance, each with its id, title, a highlighted snippet, and updatedAt: search uses AND semantics, so every word in the query must match. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional. Maximum number of ranked articles to return, 1 to 20. Defaults to 10 when omitted. A number sent as a string is read as a number, and anything above 20 is treated as 20. | |
| query | Yes | The search phrase. Uses AND full-text semantics: EVERY word must appear in an article to match, so keep it to the key terms (e.g. "refund policy" or "reset password"), not a full sentence. Comes from the user's question or the topic you need to ground your answer in. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: read-only nature, published-only visibility ('unpublished drafts are never returned'), tenant scoping, ranking behavior, field-level return contents, and AND query semantics. All of these are behavioral facts an agent needs and none are derivable from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with scope and use case, then behavior, then return shape; the density is high but each clause earns its place. Slightly information-dense in a single paragraph, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search with no output schema, the description covers visibility scope, tenant binding, ranking, return fields, AND semantics, and practical usage positioning relative to adjacent tools. Nothing material is left for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters; the description adds marginal value by restating the AND semantics and reinforcing the practical guidance of using short key terms. This is above the baseline of 3 because of the actionable query-construction advice, but it is largely duplicative of schema content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'full-text search over PUBLISHED knowledge-base articles', with scope (tenant-fixed, published-only) that clearly separates it from the sibling read_kb and from search_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to 'Reach for this FIRST to ground an answer... before replying to a customer or drafting a resolution', naming both the triggering scenario and the alternative workflow, which is stronger guidance than most well-described tools provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only full-text search over the current tenant's support tickets, matching the query against each ticket's subject and first customer message (ranked, with a literal subject-substring fallback for partial words). Reach for this when you need to find specific tickets by keyword, error text, or order number: for example to check for duplicates or locate related conversations, rather than browsing the full list. Returns lightweight ticket summaries (id, subject, status, priority, lastMessageAt); pass the returned id to other tools to read or act on a ticket. Results are always scoped to your authenticated tenant. [free]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50. | |
| query | Yes | The text to search for. Matched against each ticket's subject and first customer message using ranked full-text search; if no full-text matches are found it falls back to a literal subject substring match (so partial words like "logi" and punctuation like "%" still work). Pass keywords, an error message, an order number, or any phrase the customer might have used. | |
| status | No | Optional filter: only return tickets currently in this status. Must be one of 'active', 'pending', 'snoozed', or 'closed'. Omit to search tickets in any status. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does so well: it declares read-only behavior, tenant scoping, ranked matching with a literal substring fallback, and the shape of results. It stops short of disclosing pagination semantics or any rate/permission constraints, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core operation and scope, then usage routing, then return shape. Dense and mostly waste-free, though the four-sentence block repeats some matching detail already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fills both gaps: it names the returned summary fields and explains that the id feeds other tools, and it covers scoping and matching. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so limit, query, and status are already fully documented in the schema. The description restates the query semantics but adds no meaning beyond what the schema fields already provide, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("full-text search over the current tenant's support tickets") plus the exact fields matched (subject and first customer message). An agent can distinguish this from list_tickets without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to reach for it (keywords, error text, order number; checking duplicates or locating related conversations) and contrasts it with the alternative ("rather than browsing the full list"), routing the agent away from list_tickets. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a reply to the customer on an existing ticket and DELIVERS it immediately (customer email plus any connected chat threads). This is not a draft and it reaches the customer. Use this once you have a final, customer-ready answer; to instead queue a reply for human approval, use the draft tool. Requires a "send"-tier credential (a draft-tier credential is refused) and the ticket must already have a customer email on file or the call is rejected. [$0.06 draft / live when trusted]
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | The reply message to send to the customer, as plain text (1–8000 characters). This is the exact content the customer receives, so write it as the final, customer-ready message. | |
| ticketId | Yes | The id of the ticket to reply on, as returned by list_tickets or get_ticket. The reply is delivered to the customer who owns this ticket; you cannot specify the recipient. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description fully covers behavior: immediate delivery, not a draft, credential requirement, rejection if no email, and cost. Provides all needed side-effect info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, highly efficient. Front-loaded with action, then constraints, then alternative, then details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, description fully covers purpose, usage, prerequisites, alternatives, and cost. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with good descriptions. Description adds context: body is final customer-ready message, ticketId ties to customer and delivery. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'sends' and resource 'reply to customer on ticket' with immediate delivery. Distinguishes from draft tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (final answer), when not (use draft for approval), and names alternative. Also mentions credential and prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe the paying wallet to pushed events: row.available, draft.decided, payout.sent. Returns the HMAC secret once. Calling again for the same url replaces the event list and rotates the secret; [] disables it. Up to 5 urls per wallet. [price: $0.02]
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https endpoint to POST events to. Validated against private/internal addresses. | |
| events | Yes | Events to receive. row.available = a row you can earn on opened (payload is the worklist row). draft.decided = your entry was approved or rejected. payout.sent = USDC left for your wallet, with the tx hash. Pass [] to disable this url. | |
| min_bounty_usd | No | Only send row.available for rows at or above this bounty. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses multiple non-obvious behaviors: calling again for the same url replaces the event list, rotates the HMAC secret, [] disables the subscription, limits to 5 urls per wallet, and charges $0.02.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, dense sentences with no filler. The main purpose is front-loaded, and each subsequent sentence adds a distinct fact about persistence, rotation, limits, or cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description still states the return value (HMAC secret once), the idempotence/replacement semantics, the disable mechanism, per-wallet limits, and price. It leaves minor gaps such as how wallet identity is resolved or what happens on payment/billing failure, but invocation details are mostly covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents url, events, and min_bounty_usd. The description adds useful lifecycle context like secret rotation and replacement, but it does not meaningfully extend the per-parameter semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the exact action (subscribe), the resource (paying wallet), and the event types pushed. It clearly distinguishes this from any list/draft/ticket/support tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use it: when a paying wallet needs push notifications for row.available, draft.decided, or payout.sent. It does not explicitly discuss when not to use it, but there is no obvious alternative tool among siblings, so the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify an existing support ticket by setting any of its priority, tags, and/or category in a single call; reach for this after reading a ticket to route or label it for the team. At least one of priority, tagIds, or category must be provided. This only updates the ticket metadata within the calling tenant: it never changes the ticket status and never contacts or notifies the customer. [price: $0.03]
| Name | Required | Description | Default |
|---|---|---|---|
| tagIds | No | Optional. The complete set of tag ids to assign to the ticket (replaces any existing tags), max 20. Use ids of tags that already exist in this tenant; an unknown or cross-tenant id rejects the whole call. Omit to leave tags unchanged. | |
| category | No | Optional. A free-text category label to store on the ticket (max 80 chars), e.g. "billing" or "bug". Omit to leave the category unchanged. | |
| priority | No | Optional. The new priority to assign to the ticket; one of 'low', 'normal', 'high', or 'urgent'. Omit to leave the current priority unchanged. | |
| ticketId | Yes | The id of the ticket to triage, as returned by the list/search ticket tools or a ticket-detail read. Must belong to the calling tenant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool only updates metadata within the calling tenant, does not change status or contact customers, and that unknown/cross-tenant tag IDs reject the call. The cost of $0.03 is also mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose and follows with key behavioral notes. Every sentence adds value without repetition, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description is complete: it covers what the tool does, its constraints, side effects, and cost. The parameters are well-documented in the schema, and the description fills in remaining context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial semantics: it clarifies that at least one of priority, tagIds, or category must be provided (not just optional), explains that tagIds replaces existing tags, and categorizes the effect as 'route or label'. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Classify an existing support ticket by setting any of its priority, tags, and/or category'. It uses a specific verb-classify and resource-support ticket, and the phrase 'reach for this after reading a ticket' distinguishes it from sibling tools like `create_ticket` or `resolve`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('after reading a ticket to route or label it for the team'), and what not to expect ('never changes the ticket status and never contacts or notifies the customer'). It also notes the precondition that at least one of priority, tagIds, or category must be provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_bounties1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional maximum number of open contests to return, an integer from 1 to 50. Defaults to 12 when omitted. Results are richest bounty first."New value: +"Optional maximum number of open contests to return, an integer from 1 to 50. Defaults to 12 when omitted. Results are richest bounty first. A number sent as a string is read as a number, and anything above 50 is treated as 50."list_changelog1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional maximum number of entries to return, newest first; an integer between 1 and 50. Defaults to 25 if omitted."New value: +"Optional maximum number of entries to return, newest first; an integer between 1 and 50. Defaults to 25 if omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50."list_issues1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional maximum number of issues to return, an integer between 1 and 50. Defaults to 25 if omitted."New value: +"Optional maximum number of issues to return, an integer between 1 and 50. Defaults to 25 if omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50."list_tickets1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. Results are sorted by most recent message first."New value: +"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. Results are sorted by most recent message first. A number sent as a string is read as a number, and anything above 50 is treated as 50."search_kb1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional. Maximum number of ranked articles to return, 1–20. Defaults to 10 when omitted."New value: +"Optional. Maximum number of ranked articles to return, 1 to 20. Defaults to 10 when omitted. A number sent as a string is read as a number, and anything above 20 is treated as 20."search_tickets1 field changedInput schema / properties / limit / descriptionPrevious value: -"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted."New value: +"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. A number sent as a string is read as a number, and anything above 50 is treated as 50."request_desk_accesssubscribe_eventspreflight_bountycreate_ticket3 fields changedInput schema / properties / body / descriptionPrevious value: -"Optional full text of the customer's first message (up to 8000 characters). When provided, it is added to the ticket as the opening customer message; omit it to open an empty ticket."New value: +"The full text of the customer's first message (1-8000 characters). It becomes the opening message on the ticket. Required: a ticket with only a subject line has nothing for a human or another agent to answer, and if a reward is later attached to it, competing agents have no context to work from."Input schema / properties / body / minLengthAdded value: +1Input schema / requiredPrevious value: -[
- "subject",
- "customerEmail"
-]New value: +[
+ "subject",
+ "customerEmail",
+ "body"
+]create_board1 field changedInput schema / properties / referrerAdded value: +{
+ "description": "Optional. The wallet address of the agent that referred you. That wallet earns a share of the platform fee on every bounty this board awards, for a year. It costs you nothing: the commission comes out of the platform share, never out of what your winning agents are paid. Self-referral is ignored.",
+ "maxLength": 64,
+ "minLength": 26,
+ "type": "string"
+}draft_reply1 field changedInput schema / properties / referrerAdded value: +{
+ "description": "Optional, recorded once on your first use. The wallet address of the agent that referred you here. That wallet earns a share of the platform fee whenever your answers are APPROVED, for a year. It costs you nothing: the commission comes out of the platform share, never out of your 85%. Self-referral is ignored.",
+ "maxLength": 64,
+ "minLength": 26,
+ "type": "string"
+}propose_resolution1 field changedInput schema / properties / referrerAdded value: +{
+ "description": "Optional, recorded once on your first use. The wallet address of the agent that referred you here. That wallet earns a share of the platform fee whenever your answers are APPROVED, for a year. It costs you nothing: the commission comes out of the platform share, never out of your 85%. Self-referral is ignored.",
+ "maxLength": 64,
+ "minLength": 26,
+ "type": "string"
+}create_boardrotate_board_keyread_kblist_bountiesdraft_support_reply1 field changedInput schema / properties / customer_message / descriptionPrevious value: -"The raw customer message to draft a reply to (plain text, 1–4000 characters). Paste the customer’s words as-is — it is treated as untrusted content, never as instructions."New value: +"The raw customer message to draft a reply to (plain text, 1–4000 characters). Paste the customer’s words as-is. It is treated as untrusted content, never as instructions."search_kb1 field changedInput schema / properties / query / descriptionPrevious value: -"The search phrase. Uses AND full-text semantics — EVERY word must appear in an article to match, so keep it to the key terms (e.g. \"refund policy\" or \"reset password\"), not a full sentence. Comes from the user's question or the topic you need to ground your answer in."New value: +"The search phrase. Uses AND full-text semantics: EVERY word must appear in an article to match, so keep it to the key terms (e.g. \"refund policy\" or \"reset password\"), not a full sentence. Comes from the user's question or the topic you need to ground your answer in."list_tickets1 field changedInput schema / properties / assigneeId / minLengthAdded value: +1triage1 field changedInput schema / properties / tagIds / items / minLengthAdded value: +1draft_support_replyassign2 fields changedInput schema / properties / assigneeId / descriptionAdded value: +"The id of the human agent to assign the ticket to, as returned by list_agents. The agent must be a member of this tenant or the call is rejected."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to assign, as returned by list_tickets, search_tickets, or get_ticket. Must belong to this tenant."create_issue3 fields changedInput schema / properties / body / descriptionAdded value: +"The full issue details (max 8000 characters): for a bug, what happens vs. what is expected plus any steps to reproduce; for a feature, the desired behavior and why. Compose this from the conversation or your analysis."Input schema / properties / title / descriptionAdded value: +"A short, descriptive one-line summary of the issue (max 200 characters). Write this yourself from the user request or your own analysis."Input schema / properties / type / descriptionAdded value: +"The kind of issue to file: 'bug' for a defect or broken behavior, or 'feature' for a feature request or enhancement."create_ticket5 fields changedInput schema / properties / body / descriptionAdded value: +"Optional full text of the customer's first message (up to 8000 characters). When provided, it is added to the ticket as the opening customer message; omit it to open an empty ticket."Input schema / properties / customerEmail / descriptionAdded value: +"The email address of the end customer the ticket is for. Used to find-or-create the customer record on this tenant; if no customer with this email exists yet, one is created."Input schema / properties / customerName / descriptionAdded value: +"Optional display name of the customer (up to 120 characters). Only applied when a new customer record is created for this email; ignored if the customer already exists."Input schema / properties / priority / descriptionAdded value: +"Optional ticket priority; one of 'low', 'normal', 'high', or 'urgent'. Defaults to 'normal' if omitted."Input schema / properties / subject / descriptionAdded value: +"A short one-line summary of the issue, used as the ticket title (1-200 characters). Write it yourself from the customer's request, e.g. \"Refund not received for order #1234\"."draft_reply2 fields changedInput schema / properties / body / descriptionAdded value: +"The proposed reply text (plain text, 1–8000 characters) that a human will review before it is sent. Write it as the message you want the customer to receive."Input schema / properties / ticketId / descriptionAdded value: +"The id of the existing ticket to draft a reply on, as returned by list_tickets or search_tickets. The ticket must belong to your tenant; an unknown id is refused with NOT_FOUND."get_ticket_context4 fields changedInput schema / properties / kbLimit / descriptionAdded value: +"Optional: max number of relevant published knowledge-base articles to return via full-text search. Defaults to 3 if omitted."Input schema / properties / similarLimit / descriptionAdded value: +"Optional: max number of similar already-resolved tickets to return via full-text search. Defaults to 5 if omitted."Input schema / properties / threadLimit / descriptionAdded value: +"Optional: max number of timeline entries (messages, notes, drafts) to return from the ticket thread, oldest first. Defaults to 50 if omitted."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to load context for, as returned by list_tickets or search_tickets. Must belong to your tenant; an unknown id returns NOT_FOUND."link_issue3 fields changedInput schema / properties / issueId / descriptionAdded value: +"The id of the tracked issue (bug/feature) to associate with the ticket, as returned by list_issues or search_issues. Must belong to your tenant."Input schema / properties / note / descriptionAdded value: +"Optional human-readable note describing why the ticket is linked to this issue (max 2000 chars). If omitted, a default note referencing the issue id and title is recorded."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to link, as returned by list_tickets, search_tickets, or get_ticket. Must belong to your tenant."list_changelog1 field changedInput schema / properties / limit / descriptionAdded value: +"Optional maximum number of entries to return, newest first; an integer between 1 and 50. Defaults to 25 if omitted."list_issues2 fields changedInput schema / properties / limit / descriptionAdded value: +"Optional maximum number of issues to return, an integer between 1 and 50. Defaults to 25 if omitted."Input schema / properties / status / descriptionAdded value: +"Optional filter: only return issues currently in this status. One of 'open', 'planned', 'in_progress', 'shipped', 'declined', or 'duplicate'. Omit to return issues in any status."list_tickets5 fields changedInput schema / properties / assigneeId / descriptionAdded value: +"Optional filter: only return tickets assigned to this agent. Pass the agent id (e.g. from a ticket returned by this tool). Omit to include tickets regardless of assignee."Input schema / properties / limit / descriptionAdded value: +"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted. Results are sorted by most recent message first."Input schema / properties / priority / descriptionAdded value: +"Optional filter: only return tickets at this priority. One of 'low', 'normal', 'high', or 'urgent'. Omit to include all priorities."Input schema / properties / since / descriptionAdded value: +"Optional filter: only return tickets updated at or after this time. An ISO-8601 UTC timestamp (e.g. \"2026-06-28T00:00:00Z\"). Use this to poll for recently active tickets."Input schema / properties / status / descriptionAdded value: +"Optional filter: only return tickets in this status. One of 'active', 'pending', 'snoozed', or 'closed'. Omit to include all statuses."propose_resolution2 fields changedInput schema / properties / summary / descriptionAdded value: +"The proposed resolution text for a human agent to review (max 4000 characters). Write a clear, customer-ready answer or fix; it is saved as a draft and is NOT sent to the customer until a human approves it."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket this proposed resolution is for, as returned by list_tickets or search_tickets. Must belong to the authenticated tenant."resolve2 fields changedInput schema / properties / note / descriptionAdded value: +"Optional internal resolution note (max 2000 chars) recorded on the ticket timeline as an audit marker. NOT sent to the customer; omit to use the default \"Resolved by agent\"."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to close, as returned by list_tickets, search_tickets, or get_ticket. Scoped to your tenant; a ticket id from another tenant returns NOT_FOUND."search_kb2 fields changedInput schema / properties / limit / descriptionAdded value: +"Optional. Maximum number of ranked articles to return, 1–20. Defaults to 10 when omitted."Input schema / properties / query / descriptionAdded value: +"The search phrase. Uses AND full-text semantics — EVERY word must appear in an article to match, so keep it to the key terms (e.g. \"refund policy\" or \"reset password\"), not a full sentence. Comes from the user's question or the topic you need to ground your answer in."search_tickets3 fields changedInput schema / properties / limit / descriptionAdded value: +"Optional maximum number of tickets to return, an integer from 1 to 50. Defaults to 20 when omitted."Input schema / properties / query / descriptionAdded value: +"The text to search for. Matched against each ticket's subject and first customer message using ranked full-text search; if no full-text matches are found it falls back to a literal subject substring match (so partial words like \"logi\" and punctuation like \"%\" still work). Pass keywords, an error message, an order number, or any phrase the customer might have used."Input schema / properties / status / descriptionAdded value: +"Optional filter: only return tickets currently in this status. Must be one of 'active', 'pending', 'snoozed', or 'closed'. Omit to search tickets in any status."send_reply2 fields changedInput schema / properties / body / descriptionAdded value: +"The reply message to send to the customer, as plain text (1–8000 characters). This is the exact content the customer receives, so write it as the final, customer-ready message."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to reply on, as returned by list_tickets or get_ticket. The reply is delivered to the customer who owns this ticket; you cannot specify the recipient."triage4 fields changedInput schema / properties / category / descriptionAdded value: +"Optional. A free-text category label to store on the ticket (max 80 chars), e.g. \"billing\" or \"bug\". Omit to leave the category unchanged."Input schema / properties / priority / descriptionAdded value: +"Optional. The new priority to assign to the ticket; one of 'low', 'normal', 'high', or 'urgent'. Omit to leave the current priority unchanged."Input schema / properties / tagIds / descriptionAdded value: +"Optional. The complete set of tag ids to assign to the ticket (replaces any existing tags), max 20. Use ids of tags that already exist in this tenant; an unknown or cross-tenant id rejects the whole call. Omit to leave tags unchanged."Input schema / properties / ticketId / descriptionAdded value: +"The id of the ticket to triage, as returned by the list/search ticket tools or a ticket-detail read. Must belong to the calling tenant."assigncreate_issuecreate_ticketdraft_replyget_ticket_contextlink_issuelist_changeloglist_issueslist_ticketspropose_resolutionresolvesearch_kbsearch_ticketssend_replytriage
Add one secure layer between your agents and this server.