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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive traits. The description adds useful behavioral context beyond that: it routes to a large tool chain, fills arguments, returns structurally formatted answers with stable pipeworx:// citation URIs, and works on every tier with one fast call. It does not mention failure modes or latency details, but those are not necessary for basic invocation.

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 dense but intentionally structured: the most important routing instruction is front-loaded, followed by domain scope, trigger phrases, examples, default-use guidance, and graded alternatives. Every sentence earns its place; the length is justified by the tool's role as a universal starting point.

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 rich annotations and clear sibling differentiation, the description is largely complete. It explains the input, the routing behavior, the output style (structured answer with citations), and when to escalate. It lacks an explicit 'what if the question is unsupported' note, but the tool is designed to route broadly enough that this is a minor gap.

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%, so the schema already documents the question parameter and its aliases. The description nonetheless enriches meaning by specifying what kinds of questions are appropriate, providing domain examples (SEC, FDA, FRED, patents, weather, clinical trials) and illustrating natural-language phrasing. This goes beyond the schema's bare examples.

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 names a specific verb (routes/returns) and resource (5,724 tools across 1,497 verified sources) and clearly distinguishes itself from siblings ask_pipeworx_grounded and deep_research. The opening 'PREFER OVER WEB SEARCH' plus concrete examples leave no ambiguity about what this 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 gives explicit when-to-use guidance ('START HERE for most questions', 'default entry point'), lists triggering query phrasings, and names step-up alternatives with precise conditions ('hallucination-resistant single answer' → grounded, 'broad/multi-part question' → deep_research). No other tool in the sibling set is left confused with it.

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