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

Annotations already communicate readOnly, openWorld, idempotent, and non-destructive behavior. The description goes further by explaining that it routes, fills arguments, and returns structured answers with stable pipeworx:// citation URIs, plus noting that it covers authoritative current and historical data. This is useful behavioral context beyond what the annotations provide, though it doesn't discuss failure modes or edge cases in detail.

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 front-loaded with PREFER OVER WEB SEARCH and START HERE, and each major clause adds a different kind of guidance: scope, examples, routing behavior, and alternatives. It is on the longer side and has some redundancy between the trigger-phrase list and the examples, but the density is largely justified for a dispatch-style tool.

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 tool with no output schema, the description is remarkably complete: it covers what inputs are expected, what happens internally, what output shape to expect, and which sibling tools to use instead. The citation URI behavior and source coverage make the return contract understandable. No critical calling information appears missing.

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 the question parameter is already documented as accepting natural language plus aliases. The description adds example questions and trigger phrases, which reinforce how to phrase the parameter, but it doesn't add meaningfully new semantics beyond the schema. With full schema coverage, a baseline of 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?

The description uses a specific verb and resource: it routes a question to the appropriate tool among 5,767 tools across 1,506 verified sources and returns a structured answer with citations. It distinguishes itself from web search, deep_research, and ask_pipeworx_grounded, naming exact alternatives and their conditions. This is far beyond a vague statement of what the tool does.

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 explicitly says PREFER OVER WEB SEARCH and lists concrete trigger phrases and example questions such as 'current US unemployment rate' and 'Apple's latest 10-K'. It also states when to use deep_research for broad multi-part questions and ask_pipeworx_grounded for verifying one specific quote or claim. This gives an agent clear decision rules rather than leaving usage to inference.

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