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

Beyond annotations that mark this read-only and idempotent, the description discloses the beta/experimental nature, that candidate routing improvements are live only when under test, that no candidate is currently active, and that behavior therefore currently matches ask_pipeworx exactly. It also clarifies 'Falls back to nothing' to prevent the agent from assuming a degraded fallback.

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, front-loaded with the definition and behavioral state. The parenthetical tool/argument/response details and retirement date are slightly redundant but each sentence carries useful routing or usage information.

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 the rich annotations, full parameter documentation, and explicit pointer to ask_pipeworx for usage/response details, the definition covers what an agent needs. It doesn't spell out the response shape itself, but it states it is identical to ask_pipeworx, which is sufficient in context.

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 coverage is 100% and every parameter is documented as an alias for question, so the description adds little parameter-level value beyond saying the arguments are identical to ask_pipeworx. Baseline 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?

Description opens with 'Beta version of ask_pipeworx: identical universal router' and names the sibling, specifying it routes to 6,045 tools. It distinguishes this experimental variant from ask_pipeworx, so an agent can tell when this is the intended tool.

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?

Explicitly says 'Use it exactly like ask_pipeworx when you want the newest routing' and notes results are compared against the stable router to decide merges. This gives a concrete selection condition and names the alternative.

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