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

The annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds no extra behavioral context, such as whether the article is published by default, permission requirements, or side effects. It simply restates the action without disclosing any nuances.

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 with zero waste. It is front-loaded with the action and resource, and contains no redundant information. It is efficiently 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?

For a create operation with 8 parameters and 3 required, the description is minimal and does not address usage context or behavioral traits. It does not mention that a section_id must exist, how to handle drafts, or any side effects. It relies entirely on the schema, which is thorough but does not provide guidance on when or how to call the tool appropriately.

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 provides full descriptions for all 8 parameters (100% coverage), so the description does not need to explain them. It adds no additional meaning beyond what the schema already offers, so the 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 a specific verb 'Create' and a specific resource 'Help Center article', which distinguishes it from update_article and delete_article. There is no ambiguity about what the tool does.

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 gives no guidance on when to use this tool versus alternatives. It does not mention that it is for adding new articles, nor does it contrast with update_article or any other sibling. The agent receives no context for tool selection beyond the action itself.

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 readOnlyHint=false and destructiveHint=false, and the description adds no further behavioral context. It does not disclose side effects, permissions, rate limits, or success/failure behavior, providing zero value beyond the structured 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 wasted words, and it is front-loaded with the action. However, it is so minimal that it borders on under-specification, yet for conciseness the absence of fluff earns a high score.

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 nested conditions/actions objects, four parameters, and no output schema, this one-line description is insufficient. It does not explain the automation's purpose, any constraints on conditions/actions, or what happens on successful creation, leaving an agent without essential 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 100%, so every parameter already has descriptive text. The tool description mentions no parameter details; the schema carries the full semantic burden, which is why the 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 'Create a new automation' is a near-verbatim restatement of the tool name, offering no definition of what an automation is or how it differs from create_trigger or create_macro. It identifies the verb and resource but leaves the resource's semantics vague, and it does not differentiate among sibling creation 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?

The description gives no guidance on when to use this tool vs alternatives. It lacks any mention of prerequisites, use cases, or exclusions, so an agent cannot determine whether to choose this over create_trigger or create_macro.

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 simply states the action and adds no behavioral context beyond what the annotations already provide (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). It does not mention return values, duplicate-name handling, or permission requirements, so it adds no value beyond the structured metadata.

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, efficient sentence with no filler words. It is appropriately sized for such a simple tool, even though it is thin on explanatory detail.

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 simple two-parameter schema and the annotations covering safety traits, the description is minimally sufficient. However, the lack of an output schema and any mention of return values or edge-case behavior leaves a small completeness gap. It is adequate but not thorough.

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 fully documents both parameters (name and description) with clear descriptions, so schema coverage is 100%. The tool description does not add any parameter-level semantics, but the high schema coverage justifies a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Create') and a specific resource ('agent group'), which is enough to distinguish it from sibling tools like list_groups, get_group, update_group, and delete_group. However, it does not explicitly call out alternatives, so it stops short of a top score.

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 on when to use this tool versus alternatives, no prerequisites, and no mention of checking for existing groups. The intended usage is only implied by the name and the CRUD context of the sibling tools, leaving the agent to infer the right conditions.

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 this is a write operation (readOnlyHint false) and not destructive (destructiveHint false). The description adds no behavioral details beyond 'create', such as side effects, authentication requirements, or rate limits. It provides no additional transparency beyond what annotations already convey.

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 extremely brief (one sentence), but it is under-specified rather than appropriately concise. It does not front-load any useful details beyond the bare action. While there is no fluff, the content is so minimal that it fails to inform the agent effectively.

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 creation tool with three parameters and no output schema, the description is grossly inadequate. It does not mention return values, potential errors, or any required context. An agent cannot correctly invoke this tool based solely on this description; it would need to infer everything from the schema.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters (title, actions, description). The description adds no extra meaning about how parameters relate or what constitutes valid input, but given full schema coverage, the 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 'Create a new macro' is essentially a restatement of the tool name 'create_macro'. It states the verb and resource but adds no distinction from sibling tools like update_macro or delete_macro beyond the verb itself, which is already implied by the name. This borders on tautology, offering minimal semantic value.

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. It does not mention conditions, prerequisites, or exclude any cases. An agent has no context to decide between create_macro and other macro operations, such as update_macro or list_macros.

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 indicate readOnlyHint=false, so the write behavior is already known; the description adds no extra behavioral context such as side effects, uniqueness requirements, default values, or what happens on success or failure. It simply restates the operation without enriching the annotation-derived understanding.

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 short sentence with no wasted words and is easy to parse. It is appropriately concise, though it sacrifices useful context by being extremely minimal.

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 create operation with five parameters and no output schema, the description provides only the bare minimum. It does not explain expected return behavior, validation rules, relationship to existing organizations, or any uniqueness constraints. The schema covers parameter formats, but the behavioral context needed for confident invocation is largely absent.

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 for parameters, so the schema already explains name, tags, notes, details, and domain_names. The description itself adds no parameter-level meaning, which meets the baseline but does not exceed it.

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 and resource: 'Create a new organization.' It distinguishes the tool from siblings like create_ticket and create_user by naming the organization resource, though it does not explicitly contrast with update_organization or other CRUD siblings.

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 about when to use this tool versus alternatives. There is no mention of when create_organization should be chosen over update_organization, nor any prerequisites or context for creating an organization.

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 establish readOnlyHint=false and idempotentHint=false, and the description adds no further behavioral context such as required authentication, side effects, response shape, or constraints. It merely restates the create action with no new information beyond the 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 zero filler words. It states the purpose immediately and wastes no space.

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 9-parameter mutation tool with no output schema, the description is too thin. It lacks usage context, expected outcomes, and any caveats, leaving agents to rely solely on the schema and annotations.

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 already documents all 9 parameters with descriptions, so the baseline is 3. The description itself contributes no additional parameter meaning, but it doesn't need to because schema coverage is 100%.

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 'Create a new ticket' states a specific verb and resource, clearly distinguishing this from sibling update_ticket and delete_ticket. It unambiguously identifies the operation even without the tool name.

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 gives no guidance on when to use this tool versus alternatives such as update_ticket or export_tickets, and no mention of prerequisites or intended workflow. An agent is left to infer the appropriate context entirely.

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 indicate this is a mutation (readOnlyHint=false) but say nothing about side effects, reversibility, or permissions. The description adds no behavioral context beyond 'create', leaving the agent unaware of what creating a trigger actually does (e.g., whether it activates immediately, requires specific scopes, or has naming constraints). The openWorldHint=true suggests potential unknown side effects that the description fails to address.

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 extremely short ('Create a new trigger') but this is under-specification, not conciseness. It front-loads nothing useful and fails to earn its place by providing any substantive guidance. The entire burden falls on the schema, which is insufficient for a complex nested object structure.

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 (nested conditions and actions, no output schema, no explanation of trigger semantics), the description is grossly incomplete. It does not explain what a trigger is, how conditions are evaluated, how actions apply, or what the response looks like. An agent would be forced to guess or infer critical behavior, especially with the openWorldHint flag.

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 all four parameters (title, conditions, actions, description) are documented in the schema. The description adds no additional meaning beyond the schema, so it meets the baseline for high coverage without enhancing understanding of the nested structures (e.g., all/any conditions, action field/value semantics).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new trigger'), which is clear. However, it does not differentiate from siblings like create_automation or create_macro, so an agent cannot tell what makes a trigger distinct. This meets the 'clear but no sibling differentiation' bar.

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 on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or comparison to other creation tools. An agent has no way to know if a trigger is the right choice for a given task.

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 this is a write operation (readOnlyHint=false), non-idempotent, and non-destructive. The description adds nothing beyond 'Create a new user' — it does not mention side effects, uniqueness constraints (e.g., duplicate email), authentication requirements, or what happens on failure. With no annotation coverage for these aspects, the description fails to enrich behavioral understanding.

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 zero redundancy. It is extremely concise and front-loaded, stating exactly what the tool does without wasting 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 tool with 7 parameters and no output schema, the description is severely under-specified. It does not mention required parameters (name, email), the role enum, or what the response will contain. An agent has no idea what to expect from a successful call or how to interpret errors, making the description nearly useless beyond the schema.

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

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

Schema description coverage is 100%, so all parameters (name, email, role, tags, notes, phone, organization_id) are already well-documented with their own descriptions. The tool description adds no additional parameter meaning, which matches the baseline of 3 for high 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 states a clear verb ('Create') and resource ('a new user'), distinguishing it from update/delete/list operations on users. However, it does not specify any unique behavior or scope beyond that, making it adequate but not exceptional.

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 on when to use this tool versus alternatives such as create_organization or create_ticket, nor any prerequisites (e.g., whether an organization must exist first). The description provides no context for selection.

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=false, idempotentHint=false, and destructiveHint=false. The description adds no behavioral context beyond restating the action, such as potential side effects, authentication requirements, or that it returns the created view. With annotations present, it fails to add any extra value.

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, concise sentence with no unnecessary words. It is front-loaded with the core action, though it offers minimal detail. While efficient, it is slightly under-specified for a tool with nested parameters, but it avoids verbosity.

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 a nested conditions object with all/any arrays, and there is no output schema. The description doesn't explain how to use these fields, what operators are valid, or what the response will be. An agent would need to infer usage from the schema alone, which is insufficient 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%, so the schema fully documents title, conditions, and description. The description adds no additional meaning about how to construct the conditions object or interpret the all/any arrays. Baseline of 3 applies since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Create') and resource ('view'), which is distinct from sibling tools like update_view, delete_view, and list_views. It doesn't explain what a view is or its domain context, but the action and target are 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?

No guidance on when to use this tool versus alternatives like update_view or create_ticket. It doesn't mention prerequisites, permissions, or scenarios where this tool is appropriate. The description is purely declarative with no contextual 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true, and the description offers no additional behavioral context such as irreversibility, cascade effects, permission requirements, or response behavior. The text merely restates the action rather than enriching it beyond the 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?

One short sentence contains no filler and is appropriately front-loaded with the action. It earns its place but could have added useful caveats without significantly reducing conciseness.

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 one-parameter delete operation, the annotation set covers destructive and idempotent behavior, making the short description minimally adequate. It lacks explicit notes on irreversibility or side effects, but given the strong schema and annotation coverage, the gaps are modest.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented as 'Article ID to delete'. The description adds no further semantic detail beyond the schema, which is acceptable at the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Delete') and a clear resource ('Help Center article'), leaving no ambiguity about what the tool does. It is also distinguishable from sibling tools such as delete_ticket, create_article, update_article, and get_article by naming the article resource and the deletion verb.

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 gives no guidance on when to choose this tool over alternatives or any exclusions or prerequisites. An agent must infer from the tool name and sibling list that delete_article is for removing articles rather than tickets or other Help Center entities.

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 destructiveHint true, readOnlyHint false, and idempotentHint true. The description adds no additional behavioral context—it does not mention permanence, side effects, or what happens to associated data. It merely restates the operation, providing no value beyond the 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, concise sentence that states the purpose without any fluff. It is front-loaded and efficient, earning its place. However, it is minimal, and additional context could be added without violating conciseness.

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 delete operation with one parameter and annotations covering destructive and idempotent behavior, the description is adequate but not thorough. It lacks a note about permanence or reversibility, which would be useful for a destructive action. Given the tool's simplicity and annotation coverage, this is acceptable but leaves room for improvement.

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 fully documents the single 'id' parameter with a description ('Automation ID to delete'), achieving 100% schema coverage. The description adds no additional parameter meaning, so the baseline of 3 applies as the schema carries the semantic load.

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 'Delete' and the resource 'automation', which conveys the tool's purpose without being a tautology. It distinguishes from sibling delete tools (e.g., delete_ticket, delete_user) by naming the specific resource. However, it doesn't add any extra specificity beyond the name, so it stops 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 provides no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. While the resource name implies its use, there is no explicit instruction, so the agent must infer usage. This falls short of even implied usage guidance.

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 destructiveHint=true and idempotentHint=true, which cover the core safety profile. The description adds no additional behavioral traits beyond what the annotations provide—such as permanence, cascading effects, or required permissions—so it meets the baseline but doesn't enrich the agent's understanding.

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 ('Delete a group') with no filler or redundant information. It is appropriately terse for a simple, one-parameter delete operation and is front-loaded with the core 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?

For a simple delete with one parameter and no output schema, the description is minimally adequate. It covers the basic action but does not mention potential failure conditions, restrictions (e.g., groups with members), or side effects beyond deletion. With annotations covering destructive behavior, it's sufficient but not comprehensive.

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% coverage: the only parameter 'id' is described as 'Group ID to delete'. The description does not add any extra meaning beyond the schema's definition, so it stays at the baseline for high 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 'Delete a group' clearly identifies the action (delete) and the resource (group), which is unambiguous and differentiates it from sibling delete tools for other resources. However, it is nearly identical to the tool name and adds no extra context about scope or specifics.

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. It doesn't mention conditions, prerequisites, or scenarios where this tool is preferred over other delete operations. While the resource type inherently distinguishes it from siblings, no explicit usage context is given.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description only restates the delete action and adds no new behavioral context such as permanence, cascading effects, required permissions, or the result of attempting to delete a non-existent macro.

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 one short, front-loaded sentence with zero filler. It is appropriately concise, though it sacrifices useful detail.

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 single-parameter delete operation, the annotations and schema provide adequate safety and parameter context. The description is minimal but not incomplete enough to prevent calling the tool; however, it lacks side-effect information that would be valuable for a destructive action.

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% coverage with a clear description for the required 'id' parameter ('Macro ID to delete'). The description adds no additional parameter semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a macro' uses a specific verb and resource, making the action unmistakable. It doesn't add detail to differentiate from sibling delete tools, but the target resource is named clearly enough for selection.

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 about when to use this tool versus alternatives like update_macro or delete_ticket. There are no prerequisites, exclusions, or contextual hints beyond the implied intent of the operation.

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 provide destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description adds nothing beyond the bare action. It does not mention whether the deletion is permanent, cascades to related resources, or requires special authorization.

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, so it is easy to parse and front-loaded. However, the brevity is achieved by omitting useful context, so it is concise but not exceptionally well-rounded.

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 one-parameter delete operation, the schema plus annotations supply the essential call information. The lack of any return-value hint or side-effect description leaves it minimally complete rather than fully specified.

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

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

The schema fully documents the only parameter ('id' with description 'Organization ID to delete'), so the high coverage baseline applies. The description adds no further meaning to the parameter, such as format or prerequisites.

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 ('Delete') and identifies the resource ('an organization'), so an agent can tell this apart from sibling delete_* tools by resource. It adds no detail about deletion semantics, so it is clear but not fully differentiated.

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 on when deletion is appropriate, what prerequisites exist (e.g., admin permission, empty organization), or which alternative tool to prefer. The only use case is implied by the tool name, which the description simply restates.

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 supply destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description merely restates the action and adds nothing about consequences such as whether the deletion is permanent, whether associated data like comments is removed, or whether any confirmation is required.

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 short sentence with no filler, front-loading the action first. Every word earns its place, especially given the simplicity of the 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?

For a one-parameter, no-output-schema delete operation, the description plus annotations cover the essential behavior. It is slightly incomplete because it does not clarify the postcondition or whether the deletion cascades, but the low complexity and existing annotations keep this close to fully sufficient.

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%: the single parameter id is already documented as 'Ticket ID to delete'. The description adds no further semantic detail about the parameter, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific action ('Delete') and a specific resource ('a ticket'), clearly distinguishing it from sibling tools like get_ticket, update_ticket, and delete_user. Even though it is terse, it fully communicates what the tool does.

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, irreversibility, or related workflows. Sibling tools exist for creating, updating, and reading tickets, but the description does not help an agent choose among them beyond the verb itself.

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 disclose destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds no additional context about side effects, irreversibility, or what happens to related data. It merely restates the action without enriching the agent's understanding.

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 with no wasted words. It is appropriately minimal for the tool's simplicity and fully front-loaded.

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 with one parameter and clear annotations. The description covers the essential action but omits details like error behavior or return format, which, while not critical for a delete operation, would enhance completeness. Given no output schema, a slightly richer description could be beneficial.

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 fully documents the single 'id' parameter with type and description (100% coverage). The tool description adds no extra meaning beyond what the schema provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action 'Delete' and the resource 'trigger' clearly. It is specific enough to identify the operation, though it does not differentiate from sibling tools beyond the obvious (e.g., get_trigger, update_trigger).

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 like update_trigger or delete_automation. There is no mention of prerequisites, exclusions, or conditions that would make this tool the correct choice.

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 destructiveHint=true and readOnlyHint=false, so the description adds nothing beyond what structured data conveys. It doesn't disclose potential cascading effects, whether the deletion is soft or hard, or the openWorldHint implication of external side effects, which leaves the agent underinformed about consequences.

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 with no filler. For a one-parameter delete tool, this is appropriately sized and front-loaded; there is no wasted text.

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 (one parameter, no output schema) and the presence of openWorldHint=true indicating potential side effects, the description is notably incomplete. It omits any mention of what happens on success, failure, or the irreversible nature of deletion, leaving gaps an agent would need to handle.

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%; the schema already describes 'id' as 'User ID to delete'. The description repeats this without adding additional semantics like format, requiredness, or edge-case behavior. Since the schema carries the burden, a 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 'Delete a user' clearly states the verb (delete) and the resource (user), distinguishing it from sibling tools that target other resources like tickets or organizations. However, it lacks any nuance about scope, irreversibility, or special conditions, so it's clear but not exceptional.

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, nor are there any prerequisites, restrictions, or typical scenarios mentioned. Since this is a straightforward delete operation, some context about required permissions or consequences would help, but none is given.

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 destructiveHint=true and readOnlyHint=false, so the description's 'Delete' adds no new information. It does not disclose any additional behaviors like permanence, cascading effects, or permission requirements. Given annotations cover the destruction aspect, the description contributes nothing beyond the structured metadata.

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, compact sentence: 'Delete a view.' There is no redundant wording or filler; every word contributes to the core purpose. For a simple operation with one parameter, this is appropriately concise and 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?

For a tool with one required parameter and no output schema, the description plus annotations (destructive, idempotent, read-only false) cover the essential safety profile. The description itself is minimal but does not miss any critical information for a straightforward delete operation. However, it lacks any mention of return value or side effects beyond what annotations imply, so it is only minimally complete.

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% (the single 'id' parameter is documented as 'View ID to delete'), so the schema already carries the parameter meaning. The description does not add any extra context about the id, such as format, constraints, or relation to other resources. Baseline 3 is appropriate because the schema does the heavy lifting.

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 (delete) and the resource (a view). It is specific enough to distinguish from sibling delete tools (delete_ticket, delete_user, etc.) by the resource name, though it does not explicitly call out that distinction. The verb-resource pairing is unambiguous, so an agent can infer the tool's scope.

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, prerequisites, or context such as 'use when a view is no longer needed.' There are no sibling tools that also delete views, so the use case is obvious from the name, but the description itself offers no explicit 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 cover readOnly/idempotent/destructive hints. The description adds valuable non-annotation behavior: large exports require multiple calls, continuation depends on a returned resume value, and output is written to the export folder. It does not fully describe the response shape, but adds meaningful stateful behavior context.

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 focused sentences: the first front-loads purpose, output format, and rationale; the second explains the pagination/resume behavior. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no required parameters, the description covers the core aspects: what is exported, where it is written, the file format, and the resumable multi-call behavior. It could be more explicit about the exact return fields, but the description gives enough for an agent to call and continue the export 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 covers all four parameters at 100%, so the baseline is 3. The description adds extra value by explaining the resume continuation pattern ('call again with only the returned resume value'), which sharpens how the resume parameter is meant to be used beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb + resource ('Export every ticket matching a Zendesk search to a JSON Lines file'), adds file format details ('one ticket per line'), and gives a clear use case ('for analyzing more tickets than fit in a conversation'). This distinguishes it from sibling search/list/get tools despite not naming them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly says when to use this tool: when you need to analyze more tickets than fit in a conversation, and it explains the multi-call resume pattern. It does not explicitly name alternatives or state when not to use it, so it stops short of a full 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?

Annotations already declare readOnlyHint=true, so the safe read-only nature is covered. The description adds little behavioral context beyond the fact that it fetches a single article; return format and behavior are only partially implied by the raw parameter. This is acceptable but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short, front-loaded sentence states the resource, operation, and key selection criterion. There is no filler or repeated information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup tool, the description combined with the schema covers the essential knowledge an agent needs: the resource type, the required ID, and the option to get the raw object. It could mention the default summary behavior more explicitly, but nothing critical is missing.

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

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

Schema description coverage is 100%, with the id and raw parameters fully documented in the schema. The description reinforces the id parameter by saying 'by ID', but it does not add meaningful meaning beyond what the schema already 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 names a specific verb and resource: 'Get a specific Help Center article by ID.' It clearly distinguishes itself from list_articles and search_articles by emphasizing that it retrieves one article using its ID.

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 phrase 'by ID' signals the appropriate condition for using this tool, and sibling names like list_articles and search_articles provide obvious alternatives. It does not explicitly state when not to use it, but the context is clear enough for an agent to route correctly.

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, so the description carries no additional behavioral burden. It adds no extra context such as not-found behavior or return shape, but it does not contradict the 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 conveys the operation, resource, and lookup key efficiently.

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, one-parameter getter with readOnlyHint and full schema coverage, the description is sufficient for an agent to invoke it correctly. It does not mention response behavior, but the low complexity and annotations offset that gap.

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

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

Schema description coverage is 100% and the id parameter is already described as 'Automation ID'. The description adds no additional 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?

States a clear verb ('Get'), specific resource ('automation'), and retrieval criterion ('by ID'). It distinguishes itself from list_automations and other automation CRUD siblings through the word 'specific'.

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: this is for fetching a single automation using its ID. It does not explicitly mention alternatives like list_automations, but the usage is self-evident for a simple CRUD getter.

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 and openWorldHint=true, so the safe read-only nature is covered. The description adds minimal behavioral context beyond that—it simply restates the retrieval semantics. It does not contradict the annotations, but it also does not disclose potential errors, response shape, or authorization needs.

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 focused sentence with no filler or redundant detail. It communicates the essential operation immediately and is appropriately sized for such a simple 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?

For a one-parameter read-only getter with annotations covering safety and a fully documented schema, the description is mostly sufficient. It could mention the return value or not-found behavior, but the tool's simplicity means an agent can invoke it correctly with the given information.

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 documents the only parameter with 100% coverage: 'id' as a number with description 'Group ID'. The description adds no meaningful semantic detail beyond what the schema provides, 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 uses a clear verb ('Get') and resource ('specific group') with an explicit identifier ('by ID'), which distinguishes this from list_groups and other group CRUD operations. It is specific and unambiguous, though it does not name an alternative to explicitly differentiate from.

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 phrase 'specific group by ID' implies this tool is for retrieving one known group rather than listing all groups, but there is no explicit guidance about when to choose this over list_groups or how it relates to other group tools. Usage 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?

Discloses that including article counts can be slower on large Help Centers, which is useful beyond the readOnlyHint annotation. Provides this behavioral trade-off 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?

Single, succinct sentence that front-loads the purpose and adds a performance note. No redundant phrases or verbosity.

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?

Adequate for a read-only, single-parameter tool. No output schema, but the description implies a tree structure; missing explicit return format is a minor gap.

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

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

Schema covers the parameter fully, but the description adds context on performance impact and default behavior, which is valuable beyond the schema 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?

Clearly states it retrieves the Help Center's structure as a tree, including categories and sections, with details like article counts and dates. Distinguishes itself from article-specific tools by focusing on the overall structure.

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?

Implies use for assessing content gaps or staleness, which suggests when to use (analysis) versus alternatives like get_article. Lacks explicit exclusions, but the use case is clear.

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 and openWorldHint=true, indicating a safe, non-mutating operation. The description 'Get' is consistent with this. It does not add extra context such as return format or error behavior, but given the annotations cover the safety profile, the bar is lower. No contradiction.

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 sentence with zero waste, fully front-loaded. Every word earns its place; it is appropriately minimal.

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 get-by-ID tool with one parameter and annotations covering safety, the description is sufficient. It lacks return format details, but with no output schema and a low-complexity operation, that is not a critical gap. It tells the agent exactly what the tool does and what input it needs.

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%: the 'id' parameter is described as 'Macro ID'. The description's 'by ID' adds no new meaning beyond that. Per rubric, baseline 3 applies since the schema does the heavy lifting.

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 'Get a specific macro by ID' clearly states the verb (get), the resource (macro), and the scope (specific by ID). It distinguishes from list_macros which would return multiple, and from create/update/delete which have different verbs. No ambiguity.

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 use when you have a known macro ID and need its details, as opposed to list_macros when you don't. However, there is no explicit statement of alternatives or when-not-to-use. The context is clear but the exclusion is only implicit.

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 and openWorldHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond what annotations provide—no mention of 404 behavior, response format, or that it returns a single object. With annotations covering the safety profile, a 3 is appropriate.

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 sentence with zero waste. The key information—what the tool does and how it identifies the resource—is front-loaded and immediately actionable.

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 single-resource read tool with one parameter and annotations covering safety, the description is nearly complete. It doesn't explain return values, but no output schema exists and the tool's purpose makes the return type predictable. The only minor gap is not explicitly routing to list_organizations for multi-fetch scenarios.

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%—the only parameter 'id' is described as 'Organization ID' in the schema. The description adds no additional meaning beyond restating that the organization is fetched by ID. Baseline 3 is correct when the schema does the heavy lifting.

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 'Get a specific organization by ID' clearly states the verb (get), resource (organization), and the identifying parameter (ID). It distinguishes from list_organizations (which lists all) and create/update/delete_organization siblings, though it doesn't explicitly name them.

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: use when you need a single organization by its ID. It doesn't explicitly state when not to use it or mention alternatives like list_organizations for fetching multiple organizations, but the context is reasonably clear given the sibling tool names.

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 and openWorldHint=true, so the safety profile is known. The description adds no behavioral details—no mention of authentication, rate limits, data freshness, or that it returns aggregated data. Since annotations cover the read-only aspect, the description should add something like 'Returns aggregated call metrics' but does not.

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, efficient sentence with no filler. It is appropriately front-loaded with the core purpose, though it lacks additional structure (e.g., bullet points) that could be useful for a multi-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?

The tool has no output schema and only a bare description. It fails to explain what the statistics contain (e.g., call volumes, agent statuses), what the return format might be, or how the report parameter influences output. For a read-only tool with optional filters, this is incomplete—an agent cannot predict what data it will receive.

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 each parameter having a description and the report parameter having an enum. The tool description does not add any parameter details beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb-resource pair ('Get Zendesk Talk statistics') and distinguishes it from siblings, as there is no other Talk-related tool. It is specific enough that an agent knows it retrieves statistics, though the exact scope (call/queue metrics) is left to the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives. There are no sibling Talk tools, so the absence is not critical, but the description does not provide context like 'Use this to retrieve call performance metrics' or mention any preconditions.

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 and openWorldHint=true, so the agent knows this is a safe read operation. The description adds no extra behavioral context beyond stating the purpose—it does not mention the default summary response or the effect of the 'raw' parameter. With annotations covering safety, a 3 is appropriate; the description adds minimal value on top of the structured metadata.

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 that states the core function with zero redundancy. It is concise and to the point, ideal for quick comprehension.

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 get-by-ID tool with annotations covering safety and schema covering parameters, the description is sufficient. It does not mention the default return format (summary vs. raw), but that is captured in the 'raw' parameter description. Given the simplicity, nothing critical is missing for an agent to call 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?

Schema description coverage is 100% (both 'id' and 'raw' have descriptions). The description does not add any meaning beyond what the schema already provides. Per the rubric, baseline 3 is correct when the schema does the heavy lifting.

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 ('Get'), the resource ('a specific ticket'), and the key qualifier ('by ID'). This distinguishes it from list_tickets (which returns multiple) and get_ticket_comments (which returns comments). The purpose is unambiguous and immediately actionable.

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 the primary use case: when you have a ticket ID and need the ticket details. However, it does not explicitly mention alternatives or when not to use this tool (e.g., 'use list_tickets to search'). The context is clear enough for an agent to infer usage, but it lacks explicit exclusions.

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 and openWorldHint, covering the safety profile. The description adds genuinely useful behavior beyond those: chronological ordering (oldest first), output format (plain text with author names), and content scope (public replies + internal notes). Minor tension: 'every' overpromises against the max_comments cap and openWorldHint, but this is a schema-level nit, not an annotation contradiction.

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?

One tight sentence with zero filler. The core verb+object is front-loaded, and the trailing clause packs content scope, ordering, and format into a short list. Every element 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?

For a low-complexity read tool with fully documented parameters and safety annotations, the description covers what an agent needs to invoke and interpret results. Since there is no output schema, the description's 'plain text with author names' serves as the return-value disclosure. It does not describe truncation behavior, but that is largely covered by the max_comments parameter definition.

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 all three parameters (id, max_comments, include_internal) are already documented in the schema with defaults and semantics. The description's mention of 'public reply and internal note' loosely mirrors the include_internal parameter but adds no new meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get'), a specific resource ('the conversation on a ticket'), and exactly what it returns: public replies, internal notes, oldest first, plain text with author names. This clearly distinguishes it from the sibling get_ticket, which returns ticket fields rather than the comment thread.

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 gives clear context, explicitly defining the tool's scope as the conversation thread on a ticket rather than the ticket record itself, so an agent can infer when to call it. It does not, however, explicitly name alternatives or state when-not-to-use it, which would be needed for 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?

Annotations already declare readOnlyHint=true, so the read-only behavior is disclosed. The description itself adds no additional behavioral context such as error handling, permissions, or response shape, but for a simple ID-based getter this is acceptable and there is 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?

The description is a single, front-loaded sentence with no wasted words. It conveys the essential operation and selection criterion in minimal space.

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-only lookup with one fully documented parameter and safe annotations, this description is largely sufficient. It does not mention return values or error behavior, but the absence of an output schema and the simplicity of the operation make that a minor gap.

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

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

With 100% schema description coverage, the schema already fully documents the 'id' parameter as a Trigger ID. The description only repeats the concept of retrieving by ID and adds no extra meaning, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get'), the resource ('a specific trigger'), and the selection criterion ('by ID'). This distinguishes it from sibling tools like list_triggers, which retrieves multiple triggers, and create/update/delete_trigger, which perform other operations.

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 that this tool should be used when a caller has a specific trigger ID and wants that single trigger, but it does not explicitly mention when not to use it or point to alternatives like list_triggers. The context is clear enough for a simple CRUD getter, but explicit routing guidance is absent.

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, so the description does not need to repeat that the operation is read-only. The description adds no additional behavioral context such as response format or error handling, but it does not contradict the 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, efficient sentence with no unnecessary words, front-loading the action and resource. Every word 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?

For a simple get-by-ID tool with annotations covering read-only behavior, the description is minimally adequate. However, it lacks usage guidance to differentiate it from list_users and does not specify any return structure, which could be inferred from similar tools.

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

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

The schema fully describes the single parameter 'id' as 'User ID' with 100% coverage. The description adds no extra semantic meaning beyond the schema, so the 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 the verb 'Get' and the resource 'specific user by ID', which unambiguously identifies it as a single-user retrieval operation. It is distinct from list_users and mutation tools, making its purpose immediately clear.

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 like list_users. It does not mention that it is intended for retrieving a user when the ID is known, nor does it state any exclusions 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 and openWorldHint, so the read-only nature is clear. The description adds no behavioral context beyond annotations—no mention of response format, errors, or additional side effects—so it contributes little 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?

A single front-loaded sentence with no filler. It conveys resource, operation, and selection criterion without 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 read-only getter with one required, fully documented parameter, the description is sufficient for correct invocation. The lack of an output schema means return-value detail would add value, but it is not essential for deciding when or how to call this 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%, and the id parameter is already described as 'View ID'. The description restates that the view is selected by ID but adds no new format, constraints, or parameter-level guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a clear verb ('Get'), resource ('view'), and selection criterion ('by ID'). It unambiguously distinguishes this from list_views (all views) and from create/update/delete siblings.

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?

Usage is implied: use when you know a specific view ID. However, there is no explicit guidance about when to prefer this over list_views or other view-related tools, leaving the agent to infer the intended context.

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 provide readOnlyHint and openWorldHint. The description adds no behavioral context beyond those annotations, such as pagination behavior, return shape, or how the result set is scoped. No contradiction exists, but no additional transparency is offered.

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, direct sentence with no wasted words. It is appropriately concise, though it sacrifices potentially useful details for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what the response contains, but it only says 'List Help Center articles.' It also omits clarification of pagination, sorting defaults, and the distinction from search_articles, leaving important gaps for correct selection and 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?

The input schema has 100% description coverage for all four parameters, so the description does not need to repeat them. The description adds no extra meaning about how parameters interact, such as default sort order or pagination limits, but the schema already carries the necessary information.

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-resource pair ('List Help Center articles') and is clearly distinct from siblings like list_tickets or get_article. However, it does not explicitly differentiate from search_articles or get_help_center_structure, leaving some purpose ambiguity.

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 on when to use this tool versus alternatives such as search_articles or get_help_center_structure. The description only states the action; it does not mention when listing is appropriate or when another tool should be chosen.

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 and openWorldHint=true, which cover the safety profile. The description adds no behavioral context beyond that, such as pagination behavior or response format. It neither contradicts nor enriches the annotations, so a baseline of 3 is appropriate.

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 with no wasted words. The action is front-loaded, and it is perfectly sized for a simple list operation. Structure is optimal for clarity.

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 list tool with read-only annotations, the description is minimally sufficient but lacks any mention of filtering, sorting, or what the returned list contains. The openWorldHint suggests variability, but the description does not elaborate. It is adequate but not comprehensive.

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%, with both 'page' and 'per_page' already documented. The description does not add any additional parameter context. Since the schema fully covers parameters, the baseline is 3; the description adds no value here.

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 (list) and the resource (automations) within Zendesk. It distinguishes itself from sibling list tools (list_triggers, list_views, etc.) by explicitly naming the resource. This is a specific and unambiguous purpose.

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 context (when you need to retrieve automations) but provides no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or prerequisites. The resource name makes it obvious, but there is no direct guidance.

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 and openWorldHint=true, so the description doesn't need to repeat safety. It adds the 'newest first' ordering behavior, which is not in the schema. It also clarifies the mapping between chats and tickets, which is useful. However, it doesn't mention pagination specifics beyond what the schema provides.

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 sentence with no waste. It front-loads the core action and adds a clarifying parenthetical about the tickets relationship, which is efficient.

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 is simple (list, no required params, no output schema), the description is sufficient. It explains the output (tickets) and ordering. The only minor gap is whether it includes all chats or if there are scope limitations, but annotations (openWorldHint) suggest broad scope. Overall complete for its complexity.

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 parameters are well-documented. The description adds that results are ordered 'newest first', which is relevant for page/per_page usage, but it doesn't add substantial semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists chat conversations, and clarifies the relationship to Zendesk tickets. It distinguishes this from list_tickets by noting these are specifically chat/messaging conversations, though it doesn't explicitly name sibling alternatives.

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 when to use this tool (when you need chat conversations) but does not explicitly state when not to use it or recommend alternatives. It doesn't contrast with list_tickets or search, so an agent might not know to use search for more complex queries.

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 and openWorldHint=true, so the safety profile is covered by structured data. The description adds no behavioral detail beyond the Zendesk scope - nothing about pagination defaults, ordering, or response shape. It does not contradict the 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 zero wasted words. 'List agent groups in Zendesk' is appropriately sized for a simple list operation.

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-only list tool with two fully documented optional params and safety covered by annotations, almost everything needed is present. The minor gap is the absence of an output schema, which leaves the description with some responsibility for the response shape that it does not address.

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%: both page and per_page carry descriptions, including the per_page max of 100. The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and resource ('agent groups') with a scope qualifier ('in Zendesk'), making the operation unambiguous. It is clearly distinguishable from sibling get_group (single retrieval) and from list_* tools targeting other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use list_groups versus get_group for single-group lookup, and no indication of pagination strategies. Usage is only implied by the tool name 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat those. However, the description adds no behavioral context beyond the annotations, such as pagination behavior, rate limits, or what the response contains. It is a minimal statement that does not enrich the agent's understanding of the tool's 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 a single short sentence, which is concise and free of fluff. However, it essentially restates the tool name with minimal added value (just 'in Zendesk'). It is appropriately sized for a simple tool, but it lacks any front-loaded key information that would make it more useful.

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 that the tool is a simple list operation with read-only annotations and fully documented parameters, the description is barely adequate. It does not describe the return format or any nuances of the list operation, but for a straightforward list tool, this may be sufficient. It could benefit from mentioning pagination limits or the absence of filtering, but the annotations and schema cover the basic safety and parameter aspects.

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 provides full documentation for both parameters (page and per_page) with descriptions, so the schema covers parameter semantics. The description does not add any additional meaning or usage details about the parameters, but since schema coverage is 100%, the 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 the verb 'List' and the resource 'macros', which is distinct from sibling tools like list_triggers and list_tickets. It is unambiguous and immediately understandable, though it does not add any scope or filtering details that would further differentiate it from similar list operations.

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 on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or mention that this lists all macros without filtering. Sibling tools such as list_triggers are similar but the description offers no differentiation or use-case 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=true and openWorldHint=true, covering the safety and open-world aspects. The description adds nothing beyond that – it does not mention pagination behavior, ordering, or any potential side effects. Since it provides no additional behavioral context, it scores low despite the annotations lowering the bar.

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 with no redundant words. It is front-loaded with the action verb and resource, making it easy to scan. It contains no filler or repeated information, so it is highly efficient.

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 list tool with two optional parameters and read-only annotations, the description is minimal but functional. However, it does not clarify pagination behavior or the scope of results (e.g., whether all organizations are returned or only those accessible to the user). It also lacks any mention of alternatives, which is a gap. Given the existing schema and annotations, it is adequate but not complete.

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

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

Schema description coverage is 100%, so the page and per_page parameters are already fully documented in the input schema. The description does not mention them, but the schema carries the burden. Baseline of 3 is appropriate because the description adds no extra meaning, yet the schema covers all parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('List') and resource ('organizations') with scope ('in Zendesk'). It distinguishes itself from sibling tools like get_organization (which retrieves a single entity) and create/update/delete_organization (which mutate data). The purpose is unambiguous and specific.

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 gives no guidance on when to use this tool versus alternatives such as get_organization or search. It does not mention any conditions, exclusions, or preferred contexts. An agent has to infer usage from the name and schema, which is insufficient.

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, so the description does not need to restate that. However, the description adds nothing beyond 'List tickets' – it does not explain openWorldHint (e.g., that results may be partial or require pagination) or mention any default behavior like sorting or limit. With annotations covering the read-only nature, the description contributes little extra behavioral context.

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 with no filler. It is appropriately short, though it could include a brief note on pagination or sorting to be more useful 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?

For a list tool with four optional parameters and no output schema, the description is incomplete. It does not clarify how to use pagination effectively, which sort fields are valid, or whether the response is a paginated collection. The schema covers parameter definitions but not usage context. An agent would need to guess at the intended workflow.

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 all four parameters (page, sort_by, per_page, sort_order) are already documented in the schema. The description adds no additional meaning or usage hints; the baseline of 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb 'List' and the resource 'tickets' clearly, so the agent knows it fetches multiple tickets. However, it does not differentiate from siblings like get_ticket (singular) or export_tickets, and it lacks any scoping details such as filtering or which ticket fields are returned. It is not a tautology, but it is minimal.

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 on when to use this tool versus alternatives. It does not mention that get_ticket is for a single ticket, nor does it advise on pagination or sort usage. An agent must infer that this is the general list operation, with no exclusions or context.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only and unbounded result-set behaviors are covered. However, the description adds no additional behavioral context—no mention of pagination behavior, response format, sorting, or rate limits. Since the description provides no value beyond what the annotations give, the score is low; it is not contradictory, but it adds no 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 a single concise sentence—'List triggers in Zendesk'—that front-loads the purpose clearly. It is efficient and contains no filler. While it is very short, it earns its place as a minimal statement of purpose, though it sacrifices depth for brevity.

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: it lists triggers with optional pagination. The schema documents the parameters, and the annotations cover safety and open-world behavior. The description lacks details like default page size, return shape, or any filtering, but for a straightforward list operation these are not critical. The agent can infer most of what it needs from the schema and annotations, but the description adds little beyond the obvious, so it is adequate but not comprehensive.

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%, meaning both parameters (page, per_page) are fully documented in the input schema. The description does not mention these parameters or add any meaning beyond the schema, so a baseline score of 3 is appropriate. There is no extra semantic value provided by the description.

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 'List triggers in Zendesk' clearly states the verb (List) and resource (triggers in Zendesk). It is unambiguous about what the tool does. However, it does not differentiate itself from sibling list tools (e.g., list_macros, list_automations) beyond the resource name, so it lacks the explicit scoping or caveats seen in higher-scoring definitions.

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 on when to use this tool versus alternatives. It does not mention when to prefer list_triggers over get_trigger (for a single trigger) or over search, nor does it provide any context about prerequisites or use cases. The description simply states the action without any usage context, leaving the agent to infer.

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 and openWorldHint=true, covering the safety profile. The description adds no behavioral detail beyond the tool name—no mention of pagination defaults, result ordering, or what user fields are returned.

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 filler or redundancy beyond a minor overlap with the tool name. It is efficiently concise, though it could have used that brevity to add behavioral context.

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—no required parameters, no output schema, and all params documented in the schema. Still, the description omits useful context like default page size or response format, and with no output schema the agent must infer the return shape. This is minimally adequate but not complete.

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% (page, role, per_page are all documented in the schema), so the baseline of 3 applies. The description does not elaborate on parameter semantics, but the schema carries the full weight for these straightforward optional filters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List') and resource ('users in Zendesk'), clearly identifying it as a read/list operation. However, it does not explicitly distinguish it from sibling list_* tools (e.g., list_tickets, list_groups), relying on the tool name to carry that differentiation.

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 like get_user (for a single user) or search (for complex queries). The optional parameters (page, role, per_page) are self-evident from the schema, but the description gives no usage context or exclusions.

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 and openWorldHint=true, so the safety and potential breadth of results are known. The description adds no additional behavioral details such as pagination behavior, rate limits, or what happens when no views exist. It neither contradicts annotations nor enriches them, so a baseline score of 3 is appropriate.

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, efficient sentence that states the core purpose without any fluff. The action is front-loaded, and every word earns its place. This is an example of optimal conciseness for a simple 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?

For a simple list operation with pagination parameters, the description is minimally adequate. It does not specify what fields are returned, whether sorting or filtering is available, or how to interpret the response, but these are often implicit for list tools. Given the lack of an output schema and the tool's simplicity, a score of 3 reflects that it is complete enough for basic use but leaves some operational details unspecified.

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%, with both 'page' and 'per_page' already documented in the schema. The description adds no extra context about parameter usage, defaults, or constraints beyond what the schema provides. As a result, it meets the baseline but does not exceed it.

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 'List views in Zendesk' clearly states a specific verb (list), resource (views), and scope (Zendesk). It distinguishes this from sibling tools like get_view (which retrieves a single view) and create_view/update_view/delete_view (which mutate views), leaving no ambiguity about the operation.

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. It does not mention that get_view is for retrieving a single view, nor does it explain any filtering or sorting capabilities that might differentiate it from other list operations. An agent must infer usage from the name alone.

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 and openWorldHint=true, and the description adds no further behavioral context such as pagination limits, result shape, or whether the search spans multiple object types. There is no contradiction, but the description contributes nothing beyond the 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 short sentence with no filler or redundant content. It is efficiently front-loaded, though it errs on the side of being too thin rather than 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?

For a generic search tool with five parameters and no output schema, the description is far too sparse. It omits supported resource types, query syntax expectations, default pagination behavior, and the distinction from search-related siblings, so an agent would struggle to 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?

Schema description coverage is 100%, so the schema already documents all parameters including query, pagination, and sorting. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and a broad resource ('Search across Zendesk data'), so it is not a tautology. However, it does not specify what kinds of Zendesk data are searched or how this differs from sibling tools like search_articles, leaving the purpose vague.

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 on when to use this tool instead of alternatives. The sibling list contains search_articles and export_tickets, but the description says nothing about which search scope or use case each covers.

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 carry readOnlyHint and openWorldHint, covering the safety profile, so the bar is lower. The description adds genuinely useful behavior beyond that by stating it returns only 'titles, links and matching snippets' rather than full text, which sets expectations about output richness. 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?

Two sentences with zero filler; every clause earns its place. The front-loaded opening states both operating modes, and the subsequent clauses add distinct value: return format, then routing to get_article.

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 no output schema, the description compensates by disclosing the return contents and both operating modes, while the schema fully documents parameters and annotations cover the read-only safety profile. Minor gaps remain — no mention of pagination behavior and no differentiation from list_articles/search — but nothing essential to making a correct call is missing.

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

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

Schema description coverage is 100%, with every parameter already documented (e.g., 'Page number for pagination,' 'Only articles in this category'), so the baseline of 3 applies. The description's 'search by keyword, or list articles in a category/section/label' phrasing reinforces the OR-relationship between query and the filter params, but adds little meaning beyond the schema's own note that query is optional when filters are given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb-resource pair ('Search Help Center articles by keyword, or list the articles in a category, section or label') and discloses what it returns (titles, links, matching snippets). It explicitly distinguishes from get_article via a routing note, though it does not clarify how this differs from the sibling list_articles or the generic search 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?

Provides an explicit when-not instruction: 'use get_article for an article's full text,' which routes the agent to the right alternative for fuller content. However, it gives no guidance on when to prefer list_articles or the generic search tool for the listing mode, leaving part of the sibling overlap unaddressed.

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 and openWorldHint=true, and the description's 'Get information' is consistent with these. However, the description adds no additional behavioral context such as authentication requirements, rate limits, or the nature of the returned data. With annotations covering the safety profile, a 3 is appropriate as it adds minimal value beyond the 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 unnecessary words. It is front-loaded and appropriately sized for a tool with no parameters. Every word contributes to conveying 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?

With no parameters and no output schema, the description is the sole source of information about what the tool returns. The term 'configuration' is broad and does not clarify what specific settings or data will be provided, which could leave an agent uncertain about whether this tool answers a particular question. Given the openWorldHint, it may be acceptable, but the description lacks enough detail to be fully complete.

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 zero properties, so there are no parameters to describe. The description does not need to compensate for schema gaps. Baseline for zero parameters is 4, and the description does not introduce any ambiguity regarding 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 states the action (Get) and the resource (information about Zendesk Support configuration), which distinguishes it from sibling tools focused on specific entities like tickets or users. However, it does not specify what aspects of configuration are included, making it somewhat vague. It is not a tautology and conveys a distinct purpose.

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. The description does not mention that it pertains to global configuration or how it relates to other support tools. An agent would need to infer its applicability from the tool name and context, which is insufficient.

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=false and destructiveHint=true, and the description simply repeats the update action without adding context. It does not mention what gets overwritten, whether partial updates are supported, or any side effects beyond the annotation's basic safety profile.

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 with no wasted words. However, it is so brief that it borders on under-specification, providing only the bare minimum of information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters and no output schema, the description should explain the update semantics (e.g., selective field updates, overwrite behavior, locale handling). The current description does not address these, leaving the agent to infer from the schema alone.

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 coverage is 100%, so all parameters are documented in the schema. The description adds no parameter-specific meaning, but per the baseline for high coverage, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb (update) and resource (Help Center article), distinguishing it from siblings like create_article and delete_article. It is not a tautology, but it lacks additional context that would differentiate it from other update tools in the set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as create_article or update_ticket. The description does not mention prerequisites, exclusions, or conditions that would help an agent decide between tools.

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=false and destructiveHint=true, and the description's 'Update' is consistent with those. However, the description adds no behavioral context beyond annotations, such as whether existing fields are overwritten, whether the automation must already exist, or what side effects occur.

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 extremely concise with no filler, front-loading the action and resource. It is efficient, though it is so terse that it offers minimal value beyond the tool name itself.

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?

Although the schema covers parameters and annotations cover behavioral hints, the definition lacks update semantics such as partial versus full replacement, merge behavior for nested actions and conditions, and return value expectations (no output schema exists). An agent needs more context to invoke this tool 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 for all 5 parameters, so the schema carries the burden of explaining parameter meanings. The description adds no parameter-specific detail, but the baseline of 3 is appropriate because the schema is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Update') and resource ('existing automation'), making the core operation clear and distinct from sibling create/get/delete tools. It is somewhat generic and does not list updatable fields, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as create_automation or delete_automation. It also does not indicate whether it supports partial updates or full replacement, relying entirely on the tool name and sibling list.

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 and readOnlyHint=false, so the mutation behavior is known. The description adds no additional behavioral context such as reversibility, required permissions, or effects on related data. It is neutral but uninformative.

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 extremely brief, which is appropriate for a simple tool. It is a single clause with no fluff, and the purpose is front-loaded. However, the brevity borders on under-specification.

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 and only 3 parameters, the description should at least mention typical use cases or outcomes. It does not explain what happens on success, error handling, or any prerequisites. The annotations cover the destructive nature, but the description is too sparse for an agent to fully assess invocation 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 100%, so all three parameters (id, name, description) are fully documented in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb (Update) and resource (group), distinguishing it from create/delete/get group tools by the 'existing' qualifier. However, it essentially restates the tool name without adding specificity about what can be updated or any scope constraints.

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. The name implies the purpose, but the description does not explicitly mention that this should be used for modifying existing groups rather than creating new ones, nor does it reference sibling tools.

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 provide readOnlyHint=false, destructiveHint=true, and idempotentHint=true, but the description adds no behavioral detail. It does not disclose whether the update is partial or full replacement, or what happens to unspecified fields, so the description provides no value beyond the 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, front-loaded sentence with zero wasted words. It is concise, though under-specified; this is not a penalty because it is not rambling.

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 an update tool with 4 parameters and no output schema, this description is too thin. It does not explain update semantics (e.g., optional fields, partial vs full replacement), and the schema alone does not make the behavior obvious. An agent would need to infer critical details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions no parameters, but the schema fully documents id, title, actions, and description, leaving no gap for the description to fill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Update') and resource ('existing macro'), making it clear this applies to an existing macro. It doesn't explicitly differentiate from create_macro/delete_macro beyond the verb, but the resource is distinct among siblings.

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 given on when to use this tool versus alternatives like create_macro or delete_macro. There are no conditions, exclusions, or implied context for choosing it.

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 communicate the key safety traits: readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds no behavioral context beyond the verb, and it never states whether omitted fields are left untouched or reset, but it does not contradict the 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 active sentence with no wasted words and is easy to parse. However, it is nearly identical to the tool name and contributes little informational content, making it concise but under-specified.

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 description leaves important update semantics unexplained, especially whether omitted fields are preserved or overwritten. There is no output schema, so the agent also cannot infer what the tool returns, and the description does not clarify behavior for a tool marked destructiveHint=true.

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

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

All six parameters are described in the input schema (100% coverage), so the description does not need to repeat parameter details. The description adds no additional semantic explanation beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a clear verb ('Update') and resource ('existing organization'), so the agent can identify this as the modification operation for organizations. It distinguishes itself at a basic level from create/get/delete operations on the same resource, though it does not mention which fields are updatable.

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 word 'existing' and the verb 'update' imply this tool should be used for modifying an already-created organization, not for creating, reading, or deleting one. No explicit alternatives or when-not conditions are named, so usage guidance is only implicit.

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 annotations already indicate destructiveHint=true and readOnlyHint=false, so the mutation behavior is conveyed. The description adds no extra behavioral context (e.g., partial vs. full replacement, comment appending, or error cases) but does not contradict annotations. With annotations covering the safety profile, this is adequate but not rich.

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 zero filler. It states the purpose directly and relies on the schema for details. This is an appropriately sized description for a CRUD tool where the schema is rich.

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 9 parameters and no output schema, the description is incomplete. It doesn't clarify whether the update is partial or full, what happens to unspecified fields, whether the comment is appended or replaces existing comments, or what the return value is. The description alone does not equip an agent to use the tool correctly beyond knowing it mutates a ticket.

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 each parameter already has a clear description. The tool description adds no parameter-level information, but the baseline of 3 applies because the schema carries the semantic load. The description does not need to restate parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('update') and resource ('existing ticket'), which clearly distinguishes it from create, get, and delete siblings. It is concise and unambiguous, though it doesn't enumerate which fields can be updated—that detail is left to the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like create_ticket or delete_ticket. There is no mention of prerequisites (e.g., ticket must exist) or scenarios where this is preferred. The agent is left to infer usage from the name and schema.

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 communicate mutation, destructiveness, and idempotency, so the description's job is to add context such as whether omitted fields are preserved or reset and whether actions/conditions replace the existing set. The description provides none of this, leaving the core update semantics ambiguous.

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 only one sentence and has no wasted words, but it is under-specified rather than usefully concise. Given the nested actions/conditions and update behavior, a sentence of this length cannot carry the necessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With five parameters, nested objects, and no output schema, a one-line description is insufficient for an agent to invoke the tool correctly. It leaves unresolved whether the update is partial or wholesale, what happens to existing actions/conditions, and what the response looks like.

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 for all five parameters, so the schema carries the parameter documentation burden. The tool description adds no parameter information, but the high coverage justifies the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the verb and resource ('Update an existing trigger'), so an agent can tell this modifies a trigger rather than creates or deletes one. However, it essentially restates the tool name and gives no details about what can be updated or how it differs from neighboring update_* 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?

There is no guidance about when to use this tool instead of get_trigger, create_trigger, delete_trigger, or update_automation/update_macro. It also does not state whether this is a partial update or a full replacement, which is essential routing information.

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 no behavioral context beyond what annotations already state. Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered. However, the description does not clarify whether the update is partial or full, what happens on nonexistent IDs, or whether fields not provided are reset. Given the destructive nature, this is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short phrase, which is concise but almost under-specified. It front-loads the verb and resource, but it lacks any additional context or structure. It is not verbose, but it does not earn its place by adding value beyond the name.

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 8 parameters, a required id, and no output schema, the description is incomplete. It does not explain the update semantics (e.g., partial vs. full), error behavior, or idempotency implications. The schema covers parameters, but the tool's behavior remains ambiguous, making it difficult for an agent to predict outcomes without additional knowledge.

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 each parameter has a clear description in the input schema. The tool description itself adds no parameter-specific information, which is acceptable since the schema carries that burden. Baseline 3 is appropriate here because the description does not need to repeat what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Update') and resource ('an existing user'), which distinguishes it from create/delete/list operations at a basic level. However, it does not mention any specific fields or scope, relying entirely on the schema for that. It is not a tautology, but it is minimal.

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 on when to use this tool versus alternatives like create_user or delete_user. The description does not mention prerequisites (e.g., user must exist) or when to prefer this over other user operations. With siblings like get_user, create_user, and delete_user, an agent would need to infer usage from the name alone.

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 annotations already declare this as a mutation (readOnlyHint=false) and destructive (destructiveHint=true), so the description is not inconsistent. However, the description adds no behavioral context beyond the annotations, such as whether updating conditions is a merge or replace operation, or whether existing values are cleared when omitted. The bar is lower given annotations, but zero additional disclosure is provided.

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, but it is under-specified; it restates the name without adding operational detail. It is not overly verbose, but it is too lean to be genuinely useful. This is closer to a label than a functional description.

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 — nested conditions object, four optional fields, no output schema — the description is too brief to be fully complete. It does not clarify update semantics (e.g., partial vs full replacement), which is critical for an agent to invoke it correctly. The schema and annotations cover structure and safety, but the behavioral contract is left implicit.

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 provides 100% description coverage for all four parameters, each with its own description. The tool description adds no further parameter semantics, but the baseline of 3 applies because the schema thoroughly documents the fields. The description does not clarify interactions between parameters, such as whether omitting 'title' leaves it unchanged.

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 verb 'Update' and the resource 'view', making the core action unambiguous. It distinguishes from sibling tools like create_view, delete_view, and list_views by the operation name. However, it omits any specific details about what updating entails, but the schema provides those fields.

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 about when to use this tool versus alternatives such as update_ticket or create_view. There are no exclusions, prerequisites, or context about typical use cases. The description is purely a restatement of the tool's name and offers no decision support.

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