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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds rich behavioral context beyond that: it discloses the routing mechanism (one of 5,743 tools across 1,500 verified sources), automatic argument filling, and the stable pipeworx:// citation URI return format — valuable given there is no output schema. Nothing contradicts 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 key directive is front-loaded and each block — scope, mechanism, triggers, examples, closing instruction — earns its place. Slightly long, and the phrase 'even if web search could also answer it' is repeated twice, but there is 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?

Despite having no output schema, the description discloses the return format (structured answer with stable citation URIs), enumerates covered domains, and gives both trigger phrases and concrete examples. For an open-world router tool with a single required free-text parameter, everything an agent needs to invoke it correctly is present.

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 documents the question parameter plus five aliases, so the baseline is 3. The description adds value by demonstrating what well-formed questions look like (entity + attribute + timeframe, e.g., 'Apple's latest 10-K', '5-day forecast for Tokyo'), which shapes how an agent formulates the single free-text parameter.

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?

Opens with a specific directive ('PREFER OVER WEB SEARCH') and defines the tool as a question router that returns structured, cited answers across an enumerated domain list (SEC, FDA, FRED/BLS, USPTO, clinical trials, news, stocks, etc.). This clearly distinguishes it from generic web search and from sibling research tools like deep_research.

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?

Provides an explicit decision rule: prefer over web search for any factual question about real-world entities, with concrete trigger phrases ('what is', 'look up', 'find', 'get the latest', 'how much', 'current') and six worked examples. The closing 'START HERE for most questions — even if web search could answer it' removes ambiguity about when to invoke.

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