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

Annotations already mark the tool read-only, open-world, idempotent, and non-destructive; the description adds that it routes questions, fills arguments, and returns answers with stable citation URIs. This discloses the key externally visible behavior beyond structured hints. Minor details like latency or failure behavior are not covered, but the description carries sufficient behavioral context.

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 front-loaded with the central preference rule, followed by scope, examples, and explicit sibling routing. It is dense rather than bloated, though there is a minor punctuation/formatting stumble around 'groundedness For'.

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 tells the agent what to expect ('structured answer with stable pipeworx:// citation URIs') and covers the main alternative tools. It provides enough context for correct invocation of a broad router tool. Edge cases like unsupported question categories could be specified, but they are not essential for typical use.

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 description coverage is 100%, and the schema already documents 'question' and five aliases with examples. The description adds example phrasings and trigger words, but it does not need to compensate for missing schema information. Baseline 3 is appropriate because the structured schema does the heavy lifting.

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 opens with 'PREFER OVER WEB SEARCH' and clearly states the tool routes questions to 5,798 tools across 1,517 verified sources and returns structured answers with pipeworx:// citation URIs. This identifies the tool as a router/QA tool and differentiates it from web search and siblings like ask_pipeworx_grounded and 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?

The description gives explicit trigger phrases ('what is', 'look up', 'find', 'get the latest', 'current'), example queries, and clear routing guidance: use ask_pipeworx_grounded for additional groundedness, deep_research for broad multi-part questions, and notes that breaking-news is already handled internally. This is strong when-to-use versus alternative guidance.

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