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

Annotations already cover readOnly/openWorld/idempotent/non-destructive, and the description adds substantial behavior beyond that: answers are extracted ONLY from tool result content, refusals are explicit with a full reason enum (including data_truncated and tool_error), and a verbatim-quote evidence field is always returned. It also discloses the reliability-relevant trade-off (extra LLM call). No contradiction 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?

Four sentences, and every clause earns its place: purpose/differentiator, complete return contract, when-to-use, and when-not-to-use with cost rationale. The key differentiator is front-loaded in the opening phrase. The density is justified by the tool's complexity — no output schema exists, so the return-shape documentation is necessary, not padding.

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 compensates by specifying the exact success shape {answer, evidence, confidence, source, fetched_at, refusal_reason:null} and every refusal reason. The single required parameter is documented in the schema, safety is covered by annotations, and sibling routing is clarified against ask_pipeworx. Nothing needed to invoke this tool correctly is missing.

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% — the schema fully documents the single conceptual parameter 'question' as natural-language text with five aliases listed. The description adds context about what the question triggers (routing across 5,798 tools, argument filling, data fetch) but no parameter-specific syntax or format details. Per the rubric, baseline 3 applies when the schema carries the load, which it fully does.

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 a specific, differentiating phrase: 'Hallucination-resistant answer mode for high-stakes reads' — a distinct mode with a concrete guarantee. It identifies the resource (Pipeworx, same 5,798-tool routing as ask_pipeworx) and explicitly distinguishes itself from the sibling ask_pipeworx by the grounded-extraction behavior. The return contract (success shape vs. refusal shape) makes what this tool does unambiguous.

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 an explicit when-to-use rule: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with concrete domains (financial verdicts, legal claims, medical lookups, public statements). It also gives an explicit when-NOT-to-use rule and names the preferred alternative: 'prefer ask_pipeworx for casual lookups,' citing the concrete cost driver (one extra LLM call).

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