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

Beyond the annotations (read-only, open-world, idempotent, non-destructive), the description discloses the refusal behavior with exact refusal reasons ('not_in_source','no_tool_match','tool_error','data_truncated','llm_error') and the success return shape including evidence as a verbatim quote. It also reveals the internal routing to 5,724 tools and the extra LLM call cost. No annotation contradiction exists.

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?

Every sentence is information-dense and purposeful: the opening phrase defines the tool, the middle explains routing plus extraction, the next details the return and refusal objects, and the closing gives usage guidance and a cost comparison. It is front-loaded with the core purpose and avoids fluff or repetition.

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 the tool's complexity (routing across thousands of tools, refusal handling, return type), the description fully covers what an agent needs: success response shape, refusal reason enum, when to prefer the sibling, and the cost tradeoff. With no output schema available, the description compensates by spelling out the exact return payload, making the tool safely invocable.

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%, with aliases and a clear description of 'question' as natural language input. The description adds no parameter-level detail beyond the schema, which is acceptable but not extra value. Baseline 3 is appropriate because the schema already carries the parameter documentation burden.

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 'Hallucination-resistant answer mode for high-stakes reads,' clearly stating the specific behavioral promise. It then explicitly contrasts with 'Same routing as ask_pipeworx' while explaining the key difference: it extracts answers using ONLY tool result content. This distinguishes it from sibling ask_pipeworx and ask_pipeworx_beta without ambiguity.

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 usage criteria: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts' with concrete examples like financial verdicts and legal claims. It also provides a strong exclusion: 'prefer ask_pipeworx for casual lookups' with the cost rationale of one extra LLM call. This gives the agent clear decision rules versus the alternative.

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