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

Annotations already communicate read-only, open-world, and idempotent behavior, so the bar is lower. The description adds genuinely non-obvious behavioral detail: this is a meta-tool that routes to thousands of sub-tools, automatically fills arguments, and returns citations as pipeworx:// URIs. No contradiction with the annotations was found.

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 opening directive is well front-loaded and useful, but the description is bloated by verbatim repetition: the 'Use whenever' trigger list and the same six example queries appear multiple times. The content could be cut to roughly half without losing information, so it does not meet the 'every sentence earns its place' standard.

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?

Given that the tool has one required parameter and no output schema, the description comprehensively covers supported domains, trigger phrases, example inputs, routing behavior, and output/citation format. It is materially complete for an agent to invoke the tool correctly, though it does not specify the exact structure of the returned answer beyond 'structured answer with 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?

The schema is fully self-descriptive: all six parameters are aliases for `question`, and every alias has its own description. The tool description reinforces natural-language phrasing with examples and trigger words, but it does not add meaning beyond what the schema already provides. The baseline of 3 is therefore appropriate.

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 clearly states that this tool accepts a natural-language question, routes it to one of 5,743 tools across verified sources, fills arguments, and returns a structured answer with stable pipeworx:// citation URIs. This makes its core function easy to grasp. However, it does not differentiate itself from the sibling tools ask_pipeworx_beta and ask_pipeworx_grounded, so it stops short of a 5.

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 strong, explicit usage guidance: 'PREFER OVER WEB SEARCH', 'Use whenever the user asks "what is", "look up", "find", "get the latest"', and 'START HERE for most questions'. It also provides concrete example queries. The only gap is that it never explains when to choose this tool instead of its sibling variants ask_pipeworx_beta or ask_pipeworx_grounded.

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