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

It discloses substantial behavior beyond annotations: it routes across 5,908 tools, fills arguments, fetches data, extracts answers only from the result, returns a detailed structured payload with evidence and confidence, returns explicit refusal reasons, and costs an extra LLM call. The annotations are consistent with the description, and the description adds useful operational 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 organized and front-loaded: purpose, behavior/return contract, usage conditions, and cost tradeoff follow in logical order. Every sentence earns its place, and the length is justified by the tool's complexity and high-stakes use case.

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?

With no output schema, the description fully specifies the success and refusal return shapes, the refusal reasons, and the conditions under which to invoke the tool. It also covers the cost/alternative tradeoff, making the description complete for an agent selecting and invoking this tool.

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 input schema has 100% coverage, documenting 'question' as the natural-language query and 'system' as an alias, so the schema carries the parameter semantics. The description does not add further parameter-level meanings, but no compensation is needed because the schema is sufficient.

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 identifies this as a hallucination-resistant, grounded answer mode that routes through the same underlying tool as ask_pipeworx but differs by extracting answers only from fetched tool results. It uses a specific verb+resource ('Ask Pipeworx — Grounded') and distinguishes it from ask_pipeworx and ask_pipeworx_beta by its refusal behavior and evidence output.

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 explicitly states when to use this tool: whenever an answer will be quoted, cited, or acted on and when the agent must not invent facts. It also provides the alternative by saying to prefer ask_pipeworx for casual lookups, giving clear selection guidance relative to siblings.

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