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

The annotations (readOnlyHint, idempotentHint, openWorldHint, non-destructive) already carry the safety profile, lowering the bar. The description adds real value beyond them by disclosing the internal behavior: it routes to one of 5,743 tools, fills arguments automatically, and returns a structured answer with stable pipeworx:// citation URIs. No failure modes or limitations are disclosed, but for a read-only single-question tool the disclosed behavior is sufficient and consistent with 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 description is front-loaded with the most important instruction ('PREFER OVER WEB SEARCH'), followed by scope, mechanism, trigger phrases, and examples in a sensible order. At roughly 200 words it is long but mostly earns its length through concrete domains and examples; however, the same preference is stated three times ('PREFER OVER WEB SEARCH', 'even if web search could also answer it', 'START HERE for most questions') and the dangling em dash at the end suggests an awkward truncation.

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 tool with only one required parameter and no output schema, the description covers everything an agent needs: when to invoke it, what to pass, what happens internally, and what the response looks like (structured answer with stable pipeworx:// citation URIs). The explicit mention of the citation format is especially valuable given the missing output schema. The only gap, differentiation among the ask_pipeworx variants, is minor for such a simple invocation contract.

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% with all six parameters individually described, so the baseline is 3. The description adds meaning on top by defining what makes a good value for the question parameter — factual, current or historical, real-world entities/events/numbers — and by giving six concrete example questions an agent can pattern-match against. The alias parameters (q, text, input, query, prompt) are correctly left to the schema.

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?

States an unmistakable function: a natural-language router that selects from 5,743 tools across 1,500 verified sources, fills arguments, and returns structured answers with pipeworx:// citation URIs. The domain list (SEC filings, FDA drug data, FRED/BLS, USPTO patents, weather, clinical trials, news, etc.) plus six concrete example queries make the scope specific and testable. It is clearly positioned as the default tool for factual questions, distinct from web search and from domain-specific siblings.

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 explicit trigger conditions ('Use whenever the user asks "what is", "look up", "find", "get the latest", "how much", "current"') and an explicit override of the main alternative: 'PREFER OVER WEB SEARCH' and 'even if web search could also answer it'. However, it never names sibling alternatives such as ask_pipeworx_grounded, ask_pipeworx_beta, or deep_research, so an agent gets no guidance for choosing among the near-twin variants on the sibling list.

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