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.
Claiming proves that you control this connector and unlocks listing details, thumbnails, health checks, and analytics. It does not change or interrupt the running server.
Complete one method below. Compare the methods and read troubleshooting steps.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 16 of 16 tools scored.
Most tools have distinct purposes, but the presence of three drafting tools (draft_reply, draft_support_reply, propose_resolution) with overlapping functionality may cause confusion. Descriptions help differentiate them, but an agent could still misselect.
Tool names predominantly follow a verb_noun pattern in snake_case (e.g., create_ticket, list_issues). However, a few tools like 'assign' and 'triage' are single verbs, and 'draft_support_reply' breaks the pattern slightly. Overall consistent but not perfect.
16 tools is well-scoped for a customer support server covering ticket management, issue tracking, knowledge base, and changelog. Each tool serves a clear purpose without bloat.
The tool surface covers the core ticket lifecycle (creation, triage, assignment, context, drafting, sending, resolving) and supports issue linking and knowledge base search. Minor gaps like updating ticket details or bulk actions exist but are not critical.
assignAInspectAssigns 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_boardAInspectCreate 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_issueAInspectCreate 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.
create_ticketAInspectFiles 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.
draft_replyAInspectProposes 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_support_replyAInspectDraft 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.
get_ticket_contextAInspectRead-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.
link_issueAInspectAssociate 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.
list_bountiesAInspectRead-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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It states the tool is read-only, never creates or modifies anything, returns only public information, is free, and explains the two types of work (plain bounties and contests with entry fees and capped entrants). This is exhaustive 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 well-structured with clear sections for plain bounties and contests, and uses formatting like ALL CAPS for emphasis. It is slightly verbose with some repetition (e.g., 'read-only' and 'never creates or modifies anything' convey similar meaning), but every sentence adds meaningful detail about how to earn bounties.
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, the description provides enough detail to understand what the tool does and what it returns (each row gives ticketId and bounty in USD). It also covers the workflow for acting on the bounties and the constraints (public, not workspace-limited, entry fees for contests), making it complete for an agent to decide when and how to use 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?
The schema description covers 100% of the single 'limit' parameter, including default and behavior. The description adds context about 'richest first' and the public board, but doesn't add new semantic meaning beyond the schema, so the baseline score of 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 clearly states the tool lists the public bounty board, with a specific verb ('list') and resource ('public bounty board'). It differentiates from siblings by explicitly noting 'Unlike the other tools this is NOT limited to your own workspace,' and details what is returned (ticketId and bounty in USD).
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 clear context on when to use it (to see public bounties and earn cash) and mentions alternatives for acting on it (draft_reply or propose_resolution). However, it lacks explicit exclusions or 'when not to use' guidance, though the differentiation from workspace-limited tools implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_changelogAInspectRead-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. |
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 'Read-only' behavior and explicitly states that only published entries are returned (drafts/scheduled excluded). This provides sufficient transparency for a simple read 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?
The description is a single paragraph but well-organized: read-only declaration, what it returns, sorting, usage context, and exclusions. Every sentence adds value with no redundancy. Slightly longer than necessary but still concise.
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 (1 parameter with full schema coverage, no nested objects, no output schema), the description covers key aspects: return fields, filtering, usage context. The return fields are listed, compensating for lack of output schema. It is complete for a changelog listing 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% with the single parameter 'limit' fully described in schema. The description adds value by stating the sort order ('newest-first'), which is not in the schema, and implicitly confirms the default limit behavior. Baseline 3 plus additional sort info yields a 4.
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's action ('list'), resource ('this tenant's published changelog entries'), and provides specific details: entries are product updates/release notes, sorted newest-first, and return specific fields (id, title, body, publishedAt). It effectively distinguishes from sibling tools that are about issues/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?
The description states when to use the tool: 'when you need to tell a customer what recently changed or shipped, or to check whether a feature/fix has been announced.' It implies not for drafts/scheduled entries. While it lacks explicit 'when not to use' or alternatives, the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_issuesAInspectRead-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. | |
| 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?
No annotations, so description carries full burden. Labels tool 'read-only', mentions filter and limit behavior, and lists return fields. Does not discuss authentication or rate limits, but those are minor for a tenant-specific read 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, no fluff, front-loaded with key information. Efficient and to the point.
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 two optional params, description covers purpose, usage, and return shape. Omits mention of default limit (25) from schema but still adequate.
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 description adds limited value beyond the schema. It mentions optional filtering and cap on count, but this is redundant with the schema descriptions. Baseline of 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 clearly states it lists issues (bugs and feature requests), sorted newest first, and distinguishes from sibling tools like create_issue and list_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 when to use: to check status, vote counts, avoid duplicate before reporting. Provides clear context and implicitly suggests not to use it for creating issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ticketsAInspectRead-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. | |
| 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?
Read-only and non-destructive behavior is explicitly stated ('never creates or modifies anything'). Returns lightweight summaries with specific fields and total count, sorted by most recent message. With no annotations, this fully discloses behavioral traits.
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?
Description is concise and well-structured: read-only flag first, then use cases, then filtering options, then return format, then safety guarantee. Every sentence is informative with no waste.
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, the description covers the return values (lightweight summaries with specific fields). It also explains sorting, limits, and filtering, making it complete for a list 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% with descriptions for each parameter, so baseline 3. The description adds value by explaining the default and max for limit, and the purpose of filters (e.g., 'poll for recently active tickets'). Slightly above baseline.
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 'list support tickets' with a specific verb and resource, and distinguishes from siblings like search_tickets by focusing on listing vs searching. It also notes the sorting order.
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 use cases: 'discover ticket ids, triage the queue, or poll for activity'. While it doesn't directly say when not to use, the context and sibling tools imply alternatives. Could be improved by contrasting with search_tickets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preflight_bountyAInspectFree 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.
propose_resolutionAInspectSubmit 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_kbAInspectRead-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.
request_desk_accessAInspectFree. 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.
resolveAInspectMarks 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.
rotate_board_keyAInspectRevoke 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.
search_kbAInspectRead-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–20. Defaults to 10 when omitted. | |
| 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?
No annotations provided, so description carries full burden. It discloses read-only nature, AND search semantics, fixed tenant based on credentials, and that drafts are excluded. Lacks details on rate limits or error behavior but covers key behavioral traits.
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 short fragment, front-loaded with purpose. Every sentence adds value: 'Read-only full-text search...' immediately conveys function, then scope, then usage advice. 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, description covers return fields (id, title, snippet, updatedAt) and ranking by relevance. Constraints like limit range and AND semantics are explained. For a 2-parameter tool, this provides all necessary context for correct invocation.
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 significant meaning: explains AND semantics, recommends keeping query to key terms, and specifies default limit (10) which is not in schema. This helps the agent use parameters effectively.
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's a read-only full-text search over PUBLISHED knowledge-base articles, distinguishing it from sibling tools like search_tickets. The description explicitly mentions the scope (tenant-specific, published only) and purpose (ground answers in official guidance).
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' before replying, and clarifies what it does NOT do (return unpublished drafts). Provides context for when to use it (grounding answers) and implies alternatives for other search needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ticketsAInspectRead-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. | |
| 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?
Without annotations, the description carries full transparency burden. It discloses read-only nature, search algorithm (ranked full-text with substring fallback), return structure (lightweight summaries), and scoping. It could mention idempotency or lack of side effects more explicitly, but 'read-only' suffices.
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 concise (3 sentences), front-loaded with purpose, then usage, then output and scoping. Every sentence adds value with no 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?
Given no output schema, the description adequately explains return fields (id, subject, status, priority, lastMessageAt) and how to use the id. It covers search behavior and scoping. Could mention pagination or error handling, but not critical for a search 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% with good parameter descriptions. The description adds value by explaining the query's matching behavior and fallback mechanism, and clarifies the default limit. This goes beyond what the schema alone provides.
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 full-text search over support tickets, specifying matched fields (subject and first customer message) and tenant scoping. It distinguishes itself from sibling tools like list_tickets (browsing full list) and search_kb (knowledge base) through explicit use-case guidance.
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 when-to-use guidance ('Reach for this when you need to find specific tickets by keyword... rather than browsing the full list') and gives concrete examples (check for duplicates, locate related conversations). It does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_replyAInspectSends 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_eventsAInspectSubscribe 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.
triageAInspectClassify 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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, bound to the signed-in Glama account, and expire after seven days. They contain no email address or other personal information. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
