get_issues_for_translation

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, lowering the bar. The description adds valuable behavior details: how exclude_translated works via tags and bilingual structure detection, and how the delimiter signals already-translated state. This goes beyond the annotations to explain internal filtering logic.

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

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

The description is well-structured, leading with a single-purpose sentence followed by an organized Args block. Each line adds essential information without redundancy. It is appropriately sized for the tool's complexity.

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 an output schema exists, the description needn't explain return values. It covers all parameter semantics, default behaviors, and the collaborative workflow with apply_translations. No critical information for correct invocation appears missing, making the description 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 description coverage is 0%, but the Args section thoroughly explains every parameter: query, include_comments, max_results, exclude_translated, delimiter, and instance. It provides defaults, semantic meaning, and cross-dependencies (e.g., delimiter must match apply_translations), fully compensating for the schema's lack of descriptions.

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

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

The description clearly states it fetches issues with non-ASCII text specifically for translation, using the verb 'Fetch' and a specific resource scope. This distinguishes it from generic issue tools like get_issues or search_issues, making its purpose unmistakable.

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

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

The description explicitly instructs to 'Call apply_translations with results,' providing a clear usage context and workflow. While it doesn't explicitly list alternatives or exclusion criteria, the targeted purpose effectively implies when to use this tool over general issue fetchers.

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