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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: this is an experimental edge whose routing may change live under test, results are compared against the stable router, and it 'falls back to nothing' — it is a fully functional router, not a degraded preview. The last-retired date gives concrete current-state evidence. 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 front-loaded with the core identity and differentiator, and every sentence earns its place: beta relationship, current no-candidate state, explicit usage instruction, and the 'falls back to nothing' clarification that prevents a misinterpretation. There is mild redundancy between 'identical universal router,' 'matches ask_pipeworx exactly,' and 'this IS a full working router,' which keeps it from a 5.

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, 100% schema coverage, and four safety annotations, the description is nearly complete: it covers identity, current operational state, usage conditions, the experimental live-testing behavior, and the merge-decision purpose. The response shape is not detailed, but the description explicitly defers to 'same response shape' as ask_pipeworx, which is sufficient given the sibling definition is available to the agent.

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% — question and all five aliases are fully documented in the schema itself, including the note that question 'Accepts query, q, prompt, text, input as aliases.' The description adds only the pointer 'same arguments' as ask_pipeworx, which is marginal. Per the baseline rule, when the schema carries full parameter documentation, 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 resource ('universal router over 5,798 tools') and immediately differentiates it from siblings: it is the beta version of ask_pipeworx with candidate routing improvements. The phrase 'identical universal router (same 5,798 tools, same arguments, same response shape)' pins down exactly what it does and how it relates to the stable version, so an agent can distinguish it from ask_pipeworx and ask_pipeworx_grounded without opening schemas.

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?

Explicit guidance is given: 'Use it exactly like ask_pipeworx when you want the newest routing' names both the condition and the alternative. It also discloses the important current state — no candidate is active, so it 'currently matches ask_pipeworx exactly' — which tells the agent when behavior is identical and when it may diverge. The results-comparison purpose ('decide what merges') further clarifies why an agent would pick this over the stable router.

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