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

Beyond the annotations, the description transparently discloses that the tool is experimental, that routing improvements are enabled live only when a candidate is under test, that the last candidate was retired on 2026-07-26, and that it currently matches ask_pipeworx exactly. It also clarifies the 'falls back to nothing' behavior by stating this is a full working router. No contradiction with the readOnlyHint/idempotentHint 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 little long but every sentence earns its place: it defines the beta relationship, states the current no-candidate status, gives explicit usage guidance, and clarifies fallback behavior. It is front-loaded with the core identity in the first sentence and uses the remaining sentences to resolve likely agent uncertainty. The date and parenthetical details are slightly verbose but add precision.

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 rich annotations, the description covers the essential context: what it is, how it differs from the stable router, when to use it, current experimental status, and that it is a fully working router. The absence of an output schema is partially mitigated by saying the response shape is identical to ask_pipeworx, but it does not independently describe the response format. Overall complete enough 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?

Schema description coverage is 100%, so the schema already fully documents the question parameter and its aliases. The description only adds 'same arguments' as a pointer to ask_pipeworx, which is helpful contextually but does not independently explain any parameter semantics. 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 identifies the tool as 'Beta version of ask_pipeworx' and an 'identical universal router' with the same 5,767 tools, arguments, and response shape. It differentiates itself from the stable ask_pipeworx sibling by emphasizing its experimental routing role, so an agent can understand exactly what this tool is and how it relates to 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 explicitly says to 'Use it exactly like ask_pipeworx when you want the newest routing' and notes that results are compared against the stable router. It also clarifies the current state ('No candidate is active right now'), which tells the agent when behavior matches the stable version. It does not explicitly state when NOT to use it, such as 'use ask_pipeworx for stable/production behavior', so it stops just short of a perfect 5.

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