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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond this: it is a beta with candidate routing improvements that may be enabled live, current state is identical to ask_pipeworx, and it is a full working router rather than a fallback. This directly addresses potential uncertainty about experimental behavior. 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 moderately long but each sentence contributes: it identifies the tool, clarifies the current state (no active candidate), gives usage guidance, and reassures about full functionality. The key point 'identical universal router' is front-loaded. The date reference is specific and informative. It is not overly verbose given the complexity of a beta router.

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?

The description covers what the tool is and when to use it, but it omits details about the response shape and any limitations (e.g., request size, rate limits). It references 'same response shape' but does not describe it, relying on the sibling ask_pipeworx to provide that. For a tool that routes across 5,724 tools, the absence of any output format specifics is a gap, though not critical for deciding whether to call it.

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% (all parameters described in the schema). The description reinforces that the parameter is 'Your question or request in natural language' and lists the aliases. This mirrors the schema but does not add substantially new information beyond a usage hint that it is natural-language input. Baseline of 3 is appropriate since the schema already documents the parameters thoroughly.

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 states it is an 'identical universal router (same 5,724 tools, same arguments, same response shape)'. This establishes a specific purpose: a question-answering router with experimental routing improvements. It also distinguishes itself from the sibling 'ask_pipeworx' by noting it is the beta/experimental edge, so an agent can tell it apart.

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 'Use it exactly like ask_pipeworx when you want the newest routing', providing a clear usage trigger and referencing the primary alternative. It also notes that results are compared against the stable router, implying that for stable results one should use the non-beta version. The phrase 'Falls back to nothing' clarifies it is a full router, not a wrapper that delegates. This gives solid guidance without explicit exclusions.

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