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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, and the description adds substantial context beyond them: experimental status, live candidate switching, the inactive state with a retirement date (2026-07-26), equivalence guarantees, and the fact that queries feed comparison against the stable router. The description also clarifies 'Falls back to nothing — this IS a full working router,' ruling out a common misconception. No contradiction with the annotations; a routing query is non-mutating and repeatable.

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?

Four sentences with no fluff, front-loaded with the core identity and beta nature in the first sentence. Each sentence earns its place: identity, current status, usage guidance, and a misconception-clarifying fallback statement. It is slightly dense but justified by the experimental nuance that needs explaining.

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 single-required-param router with a fully documented schema and rich safety annotations, the description covers purpose, current behavior, temporal state changes, and response shape ('same response shape'). The experimental caveat ('whenever one is under test') is disclosed without needing to enumerate hypothetical routing changes. Slight gap: no hint about how an agent would detect that a candidate is active, but the tool itself handles that.

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% — all six parameters (question plus aliases q, text, input, query, prompt) are documented in the schema. The description only adds 'same arguments' equivalence with ask_pipeworx, which is a marginal complement. With complete 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 states a specific verb+resource: it is an 'identical universal router (same 5,798 tools, same arguments, same response shape)' explicitly positioned as the beta/experimental edge of ask_pipeworx. It differentiates from siblings by framing itself as the candidate-testing variant and clarifying the current state (no active candidate, matches ask_pipeworx exactly). An agent can tell it apart from ask_pipeworx and ask_pipeworx_grounded.

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?

'Use it exactly like ask_pipeworx when you want the newest routing' provides an explicit selection condition. The current-state disclosure ('No candidate is active right now... so this currently matches ask_pipeworx exactly') tells the agent how it behaves right now, and 'results are compared against the stable router' explains the evaluation context. However, it does not explicitly state when not to use it versus alternatives like ask_pipeworx_grounded.

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