Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write. The description adds the important nuance that only explicitly approved fields are applied, implying unapproved fields remain unchanged. However, it does not disclose that this overwrites ticket fields, that confirm=true is required, or that expectedRevision provides optimistic locking.

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 with no wasted words, which is concise. However, for a tool with 7 parameters, destructive behavior, and optimistic locking, this is under-specified rather than appropriately concise. It could be expanded without becoming verbose.

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 complex: it involves a destructive update, a required confirmation flag, an expectedRevision for concurrency, and 7 parameters. Yet the description provides only one line and does not cover the flow, prerequisites, or consequences. Even with annotations and schema, the description leaves significant gaps for safe usage.

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 0%, so the description must compensate for explaining parameters. It vaguely references 'recommendation fields' which maps to approvedFields, but does not explain recommendationId, ticketId, expectedRevision, actor, or the confirm mechanism. This leaves critical parameter behavior undocumented at the description level.

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: 'Apply only explicitly approved recommendation fields to the ticket.' The verb 'apply', the resource 'ticket', and the qualifier 'only explicitly approved fields' distinguish it from sibling tools like submit_triage_recommendation and reject_triage_recommendation.

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?

There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites like having a pending recommendation or needing to confirm approval. The sibling tool names imply context, but the description itself provides no explicit when/when-not direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral information about the algorithm being 'deterministic' and the results being only 'likely' duplicates, which clarifies that the tool is heuristic and reproducible, beyond what annotations state.

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, concise sentence that is front-loaded with the tool's purpose and method. It contains no unnecessary words 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?

The tool is simple (1 param, output schema present, annotations clear) and the description covers the main purpose. However, it omits explanation of the 'id' parameter and does not offer usage guidance, leaving some gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description mentions no parameters. The schema defines 'id' as a required string with a pattern, but the description doesn't explain that 'id' refers to the ticket to find similar ones. Schema coverage is 0%, and the description fails to compensate by describing the parameter's 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 a specific action: 'Find likely duplicate tickets' using a defined method ('deterministic text similarity'). This distinguishes it from sibling tools like list_tickets or get_ticket, which serve different purposes.

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 implies a use case (finding duplicate tickets) but provides no explicit guidance on when to choose this tool over alternatives such as search_knowledge or get_ticket. The uniqueness of the duplicate-detection purpose is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping to one ticket but does not disclose pagination behavior, ordering, or what happens when ticketId is 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 a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core functionality.

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 has an output schema and safety annotations, so basic use is covered. However, the description is minimal for a paginated read tool with an optional filter; it does not explain pagination or the precise behavior when ticketId is missing, leaving some 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?

The schema has 0% description coverage, so the description must compensate. It only hints at ticketId via 'one ticket' and does not explain limit or offset semantics. The parameter names are somewhat self-explanatory, but the description lacks explicit mapping and context for all three parameters.

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 a read operation for audit events, with explicit scope: all events or events for one ticket. This distinguishes it from sibling tools like get_ticket or list_tickets, which operate on tickets, not audit events.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of audit trail use cases, prerequisites, or exclusions, leaving the agent without explicit decision support.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the metric categories and the 'current' qualifier, providing useful context about the tool's scope without contradicting 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 a single sentence with no filler, stating exactly what the tool calculates. It is appropriately sized for a zero-parameter tool.

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 zero-parameter input, comprehensive annotations, and presence of an output schema, the description sufficiently explains the tool's purpose and scope. It names all metric types returned, making it complete without over-explaining.

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 tool has zero parameters, so the baseline score of 4 applies. The description does not need to explain any parameters.

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 the specific verb 'Calculate' and identifies four distinct metric categories (queue, SLA, recommendation, savings). This clearly differentiates it from sibling tools that focus on individual tickets, audit events, or recommendation approvals.

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?

No explicit usage guidance or alternative tools are mentioned. The description implies it's the metrics aggregation tool, but doesn't state when to prefer it over list_tickets or get_ticket, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read behavior is covered. The description adds no new behavioral context beyond what is already known, such as error handling or permissions. It does not contradict 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 a single sentence that is direct and efficient. Every word serves a purpose, with no filler or repetition.

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 read-one-ticket tool with an output schema and rich annotations, the description is sufficient. The tool's behavior is fully captured by 'read one support ticket by ID', and no additional context about return values or side effects is necessary given the structured metadata.

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 0%, so the description carries the parameter explanation burden. It says 'by ID', which clarifies that the 'id' property is the ticket identifier, but it does not elaborate on the expected format beyond the schema's pattern (TKT-####). The single parameter is straightforward, so this is adequate but not enriching.

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 'Read one support ticket by ID' uses a specific verb ('read') and resource ('support ticket') with the identifier method ('by ID'). It clearly distinguishes from siblings like list_tickets and search_knowledge, which serve different purposes.

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 implies usage when you have a specific ticket ID and need to fetch a single ticket, which is a reasonable inference. However, it does not explicitly contrast with alternatives like list_tickets or find_similar_tickets, nor does it mention when not to use it (e.g., for bulk retrieval).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool read-only and non-destructive, so the description need not repeat that. It adds the 'local' qualifier and pagination hint, but lacks deeper behavioral context like default sort order or handling of missing filters. No contradiction with 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?

A single, front-loaded sentence with no wasted words. It is concise and direct, though somewhat under-specified given the tool's parameter count.

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 8 optional parameters and a rich set of filter enums, the description is too brief. It gives only a high-level summary and does not cover the variety of filtering dimensions (status, priority, team, etc.). An output schema exists, which reduces the need to describe return values, but the description still lacks essential context for a complex 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 description coverage is 0%, and the description does not explain any of the 8 parameters. It generically says 'filter' which hints at the filter parameters, but does not add meaning beyond their raw names and enums. The description fails to compensate for the lack of 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 tool's verb ('filter and page') and resource ('local support ticket queue'), distinguishing it from siblings like get_ticket (which fetches a single ticket). However, it does not explicitly name a sibling for contrast, so it falls just short of a 5.

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 implies usage for browsing ticket lists via filtering/pagination, but it provides no explicit when-to-use guidance or alternatives. Since no exclusions are stated, the context is clear but minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, so the safety profile is known. The description adds minimal context by mentioning 'record feedback', but it does not explain consequences like irreversibility or state changes beyond what annotations imply.

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, clear sentence that is front-loaded with the action and outcome. 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 the destructive nature and 4 required parameters, the description is too sparse. It does not explain side effects, prerequisites, or how rejection fits into the workflow, even though an output schema exists.

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?

With 0% schema description coverage, the description must compensate, but it only implicitly references 'feedback'. It does not clarify the meaning or relationships of recommendationId, ticketId, or actor, leaving the agent to infer from parameter names alone.

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 ('Finalize') and identifies the resource ('local triage proposal') and the outcome ('as rejected and record feedback'). It clearly distinguishes this from sibling tools like approve_triage_recommendation and submit_triage_recommendation.

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 no guidance on when to use this tool versus alternatives (e.g., approve_triage_recommendation). It simply states what the tool does without context about the decision process or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, informing the agent this is a safe, repeatable read operation. The description adds the 'local' qualifier, indicating the search scope, but does not reveal behavior like result ranking or pagination. Given annotations, this is acceptable and not contradictory, but the added value is minimal.

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, front-loaded with the action, and contains no filler. It efficiently conveys the core purpose.

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 search tool, the description, combined with robust annotations and an output schema, is adequate. It specifies the resource type and scope. It lacks any caveats about search behavior, but the simplicity of the tool and presence of output schema compensate.

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 two parameters (query and limit) with zero schema descriptions. The description does not explain these parameters, leaving the agent to infer that 'query' is the search term and 'limit' caps results. This is a significant gap since the description carries full burden for param semantics with 0% 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 function: searching local support knowledge and policy articles. The verb 'search' and the resource 'knowledge and policy articles' are specific and distinct from sibling tools that deal with tickets, queues, or audit events.

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 for when this tool is appropriate: when the agent needs to search knowledge articles. However, it does not explicitly state when to avoid it or mention alternatives, such as find_similar_tickets for ticket similarity, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotations: it explicitly states that the tool does not change the ticket or external systems, and that the proposal is local. This provides more specific non-destructive behavior than the annotations' destructiveHint=false. It could further disclose persistence or visibility details, but the key context is present.

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 concise sentence that delivers the core purpose effectively without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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 complexity (19 parameters, 16 required) and the presence of an output schema, the description is too minimal. It does not explain how this tool fits into the triage workflow (e.g., relation to approve/reject), what the parameters mean, or under what circumstances it should be called. The description is insufficient for an agent to correctly select and invoke the tool 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 description coverage is 0%, so the description must compensate for parameter meaning. However, the description provides zero details about any of the 19 parameters. It mentions 'triage proposal' but does not explain what fields like category, priority, team, or rationale signify, leaving the agent to rely solely on the schema's property names and enums.

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 with a specific verb ('Store') and resource ('local triage proposal'). It also explicitly notes that it does not change the ticket or external systems, which distinguishes it from sibling tools like approve_triage_recommendation and reject_triage_recommendation.

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 implies usage through 'without changing the ticket or external systems', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any when-not-to-use conditions. The context is clear but the guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.