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

Annotations already carry read-only, open-world, and idempotent hints; the description adds meaningful behavior beyond that by saying it routes to the right tool, fills arguments, and returns answers with stable citation URIs. It does not mention latency, cost, or failure modes, but this is a read-only lookup/router so the disclosed behavior is adequate and 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 highest-value routing instruction is front-loaded and the rest is organized into trigger phrases, examples, and explicit alternatives. It is longer than many tool descriptions, but the length is justified by the need to distinguish this router from several siblings; the slightly awkward transition around 'except For' keeps it from being perfectly structured.

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?

With one required parameter and rich annotations, the description covers all essential context: when to use it, what input to provide, what the tool does internally, what the returned answer looks like, and which siblings handle cases it should not. No output schema exists, yet the return format is described well enough (structured answer with stable citation URIs) for an agent to invoke it confidently.

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?

The schema already covers the only real parameter, 'question', plus its aliases at 100% coverage. The description adds value by clarifying what kinds of natural-language questions to pass — SEC filings, unemployment rate, Tokyo forecast, clinical trials — and showing that the input should be a request rather than structured arguments.

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 first sentence says 'PREFER OVER WEB SEARCH' and describes the core action: routing a natural-language factual question to one of 5,798 tools across 1,517 sources and returning a structured answer with pipeworx:// citation URIs. This makes the verb, resource, and output clear and distinguishes it from web search and the sibling research tools without needing to open schemas.

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 names when to prefer this tool, lists trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current'), and provides concrete example questions. It also states exclusions and alternatives: ask_pipeworx_grounded for verbatim/unverified/single-source needs and deep_research for broad/multi-part questions, so an agent can route correctly.

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