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

Annotations already cover read-only, idempotent, open-world and non-destructive, so the bar is lower; the description still adds real context by disclosing that results are compared against the stable router to decide merges, that there is no degraded fallback path, and that the behavioral difference is currently nil. It stops short of describing response structure or latency, but the core behavioral traits are disclosed.

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 routing scope and the live-candidate status are front-loaded, and the sentences are purposeful. There is mild redundancy in restating that it matches ask_pipeworx exactly and then again that it 'IS a full working router', but the text remains short and readable.

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 router with no output schema, fully documented parameters and complete safety annotations, the description supplies the remaining context an agent needs: it is experimental, currently identical to the stable router, and never fails over to a degraded mode. Only the response envelope (e.g. _meta fields) is left unexplained, which the 'same response shape' clause largely covers.

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%, and all nine parameters – including the seven aliases and the packs scoping argument – are documented in the schema itself, so the description carries no burden. It only says 'same arguments', adding nothing about alias precedence or pack-scoping semantics beyond what the schema already states, which is the expected baseline 3.

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 concrete verb and resource (a universal router that answers a natural-language question by selecting among 7,181 tools) and explicitly positions it against its sibling ask_pipeworx rather than leaving the agent to guess. The 'same arguments, same response shape' framing makes the distinction between the two routers unambiguous.

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?

It gives a clear selection rule – use this one 'when you want the newest routing' – and implicitly routes stability-seekers to ask_pipeworx. The caveat that no candidate is currently active and it therefore matches ask_pipeworx exactly is honest and useful, but it never states a when-not-to-use case directly, and it omits the other sibling ask_pipeworx_grounded as an alternative.

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