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

Adds material behavioral context beyond the read-only annotations: the beta may change routing candidates live, no candidate is currently active, and this is a full working router with no fallback. This prevents the agent from assuming it is a stub or that a fallback to ask_pipeworx is needed. It does not contradict the 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 longer than minimal but each sentence earns its place: beta status, identity with the stable tool, current active-candidate state, and routing comparison purpose. The key usage instruction comes near the end but is clearly marked ('Use it exactly like...'). No filler.

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-parameter router, the description covers current behavior, relationship to the stable version, experimental nature, and the absence of fallback. There is no output schema, but the description references the same response shape as ask_pipeworx, which is enough for selection. It could add an example question, but the schema already defines the input.

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%, with every alias (q, text, input, query, prompt, question) documented. The description adds only that the arguments are identical to ask_pipeworx, which is consistent but not additional semantic detail. Baseline 3 applies.

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?

Clearly identifies the tool as a beta universal router with the same 5,798 tools and arguments as ask_pipeworx, so an agent knows it handles arbitrary questions by routing them. It distinguishes itself from ask_pipeworx by being the experimental edge with candidate routing improvements. A direct verb like 'routes' is implied by 'router' and 'use it exactly like ask_pipeworx'.

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 to use it exactly like ask_pipeworx when the newest routing is desired, and explains that results are compared against the stable router. It also states that when no candidate is active it matches ask_pipeworx exactly, telling the agent the behavior is the same right now. It stops short of listing when-not-to-use conditions, but the alternative is clear.

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