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

Annotations already establish read-only, idempotent, open-world behavior. The description adds meaningful behavioral context beyond that: it routes to one of 5,743 tools, fills arguments, returns structured responses with pipeworx:// citation URIs, works on every tier, makes one fast call, and handles breaking news. This goes well beyond the annotation profile.

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?

Although fairly long, every sentence earns its place: primary directive is front-loaded, followed by scope, examples, default status, and step-up alternatives. The structure makes it skimmable and decision-oriented rather than bloated.

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-parameter routing tool, the description is complete: it covers when to use it, what it returns, how it differs from alternatives, and typical query forms. Even with no output schema, the description explicitly states the response format — a structured answer with stable citation URIs.

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% and all parameter aliases are documented, so the baseline is 3. The description adds value by explaining what kinds of questions are acceptable, providing concrete examples, and noting that the tool fills arguments itself, so the caller only needs to supply a natural-language question.

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 concrete action — route a factual question to the right source tool — and gives an explicit resource scope: SEC filings, FDA data, FRED/BLS, patents, real estate, news, and more. It clearly differentiates from siblings like ask_pipeworx_grounded and deep_research by specifying when each is appropriate.

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 is explicit about when to use this tool: prefer it over web search, use it for common factual phrasings like 'what is' and 'look up', and start here as the default entry point. It also states exclusions and alternatives, routing to ask_pipeworx_grounded for hallucination-resistant single answers and deep_research for broad multi-part questions.

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