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.
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_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, optionally records the customer's first message, and does NOT send any email or notify the customer. [price: $0.02]
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional full text of the customer's first message (up to 8000 characters). When provided, it is added to the ticket as the opening customer message; omit it to open an empty ticket. | |
| 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?
Given no annotations, the description carries the full burden and discloses key behaviors: find-or-creates customer, optional first message, no notification, and returns specific fields. It lacks details on error handling or rate limits but provides sufficient behavioral context for an agent.
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 tight three-sentence paragraph. The first sentence states purpose and return values, the second gives usage guidance, and the third adds behavioral caveats. Every sentence earns its place with zero 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 tool with moderate complexity (5 params, 2 required, no output schema), the description covers the core workflow: find-or-create customer, optional first message, no notification, and return values. It could mention idempotency or error states, but it is complete enough for typical agent use.
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 baseline is 3. The description adds context beyond schema by explaining the find-or-create behavior for customerEmail, the optionality of body, and the no-email policy. However, it does not significantly enhance understanding of each parameter beyond the schema's own 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 ('Files a new support ticket'), the resource ('end customer on this tenant'), and the return values ('ticketId, customerId, and status'). It also specifies the use case ('log a new customer issue or request'), distinguishing it from sibling tools like 'create_issue' or 'draft_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?
The description explicitly states when to use ('when an agent needs to log a new customer issue or request') and what the tool does not do ('does NOT send any email or notify the customer'). However, it does not provide explicit alternatives or when-not-to-use scenarios, leaving some guidance implicit.
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". [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. | |
| 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?
Discloses key behavioral traits: saves as draft with delivered:false, notifies thread, requires human approval, returns specific fields. Without annotations, this is fairly comprehensive. Minor gap: doesn't mention permission requirements or idempotency, but still adequate.
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 wasted words. It efficiently conveys purpose, behavior, usage guidance, and return info. 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 no output schema, the description lists return fields (draft id, ticket id, status). It covers the main aspects of the tool. While it could mention error types beyond NOT_FOUND, it is sufficient for this simple 2-parameter 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 descriptions. The description adds value beyond schema: for body, it instructs 'Write it as the message you want the customer to receive'; for ticketId, it adds context about tenant ownership and error behavior (NOT_FOUND). This is helpful.
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 verb (proposes a reply), resource (support ticket), and action (saving as a draft). It explicitly differentiates from siblings like send_reply by noting the draft is NOT sent to the customer, and the context of human approval distinguishes it from other tools.
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 when-to-use guidance: 'Reach for this once you have a ready answer for a ticket and want a human to review and send it.' It also contrasts with alternative actions (look up or send directly), making it clear when not to use this tool.
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.
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. [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. | |
| 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?
Despite no annotations, the description fully discloses key behaviors: it creates a draft queued for human review, does not send to customer, does not close ticket, looks up ticket by id within tenant, and refuses if ticket not found. This provides comprehensive transparency for a write 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 concise and well-structured: opening sentence defines action and key traits, second sentence gives usage context, third explains lookup behavior, and an optional price note. Every sentence adds distinct value without 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 and multiple sibling tools, the description provides complete context: workflow (draft, human approval), usage timing, lookup constraints, and cost. It adequately compensates for the lack of annotations and output 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% with clear descriptions for both parameters. The description adds minor value: for 'summary' it reinforces the draft nature and customer-readiness, and for 'ticketId' it mentions source tools (list_tickets, search_tickets). These additions are helpful but not essential given the schema already covers 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 defines the tool's action: submit a proposed resolution as a draft for human approval. It distinguishes the tool from siblings by explicitly stating it is NOT sent to the customer and does NOT close the ticket, contrasting with tools like 'resolve' or '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?
The description explicitly states when to use the tool: 'Reach for this once you have diagnosed a ticket and have a concrete, customer-ready answer or fix to suggest.' It implicitly excludes using it before diagnosis or for non-final answers. However, it does not name alternative tools for different scenarios.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!
