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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description adds useful non-obvious context: internal routing to one of thousands of tools, automatic argument filling, stable pipeworx:// citation URIs, and compatibility with every tier. It also notes that it routes to live news feeds. Slightly more detail on failure or rate-limit behavior would push this to 5, but there is no contradiction.

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 long, but it is front-loaded with the highest-priority instruction ('PREFER OVER WEB SEARCH') and is organized from broad scope to trigger phrases to examples to escalation paths. There is some redundancy, such as repeating the 'use whenever' guidance after already listing examples, but each section earns its place by supporting routing decisions.

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?

The description covers domain breadth, example inputs, return behavior (structured answer with stable pipeworx:// citation URIs), and explicit escalation rules to sibling tools. Since there is no output schema and the tool is a broad router, this is nearly complete; a little more detail about response shape or error handling would be needed for a 5.

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 documents all six parameters at 100% coverage, all as aliases for `question`, so the baseline is 3. The description adds meaning by specifying the kinds of natural-language prompts that work (SEC filings, FDA drugs, FRED statistics, patents, real estate, weather, clinical trials, etc.) and by giving realistic example questions. This materially helps an agent formulate the `question` argument even though no additional syntax is needed.

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?

Description states a very specific role: routes factual/current-data questions to one of 5,743 tools across 1,500 sources and returns structured answers with citation URIs. It distinguishes itself from ask_pipeworx_grounded and deep_research by naming exactly when each should be used, and it gives concrete domains and example queries. This is a clear, differentiated purpose statement.

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?

Explicitly instructs agents to prefer this tool over web search for factual questions, provides trigger phrases like 'what is', 'look up', 'find', and 'get the latest', and says 'START HERE'. It gives explicit escalation conditions for ask_pipeworx_grounded and deep_research, and clarifies that breaking-news questions are also handled by this tool. This removes ambiguity about when to select it versus alternatives.

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