Get All Queues

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

The annotation readOnlyHint=true already indicates this is a read-only operation. The description adds that it returns queues 'available to the user', which is useful scope context. However, it does not describe pagination behavior, potential large payloads, or sorting, but the parameter descriptions cover some of this. The description does not contradict the annotation and adds minor value beyond it.

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 that quickly states the purpose and includes a helpful parenthetical definition of 'queue'. It has no unnecessary words and is structured well 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?

The tool is a straightforward read-only list operation. The annotation and output schema cover safety and return shape, and the schema parameter descriptions provide pagination and field-selection guidance. The description explains the concept of a queue. This is sufficient context for the tool's complexity, though it could have briefly mentioned handling large result sets.

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 detailed descriptions for all three parameters (page, fields, per_page). The tool description adds no additional parameter semantics, but the schema itself provides strong guidance, including recommendations for using 'fields' to avoid context pollution and clarifying pagination resets. Baseline 3 is appropriate given the 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 clearly states the tool's function: finding all Yandex Tracker queues available to the user. It uses a specific verb ('find') and resource ('queues'), and the parenthetical clarifies what a queue is. This distinguishes it from sibling tools that target individual queues (e.g., queue_get_metadata) or other entities.

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

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

The description implies usage: use this tool to retrieve all queues for the user. It does not explicitly contrast with alternatives like queue_get_metadata or mention when pagination should be used, though the schema provides some guidance. There is no exclusion or alternative named, so the guidance is implied rather than explicit.

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