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

Even with readOnly/op enWorld/idempotent annotations, the description adds substantial behavioral transparency: it discloses that extraction uses ONLY tool result content, enumerates the exact refusal reasons and output shape, and states the extra LLM call cost. This goes well beyond the annotations and gives the agent a realistic model of the tool's behavior and failure modes.

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 dense but every sentence earns its place: purpose, mechanism, output/refusal contract, use case, and cost trade-off. It is front-loaded with the key differentiator ('Hallucination-resistant answer mode') and remains structured enough to be easily parsed.

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 fully compensates by detailing the success response fields and all possible refusal_reason values. Combined with the annotations and parameter schema, an agent has all necessary context to invoke the tool correctly and interpret its results.

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 already documents 100% of parameters, including the question field and its aliases, so the description doesn't need to add parameter details. The description does not provide any additional parameter-based semantics beyond what the schema covers, which aligns with the baseline of 3 for high schema coverage.

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 states a clear, specific purpose: a hallucination-resistant answer mode that extracts answers using only tool results. It explicitly contrasts itself with ask_pipeworx, naming the sibling and distinguishing its grounded extraction behavior, so an agent can readily tell them apart.

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 explicit when-to-use guidance: 'Use whenever an answer will be quoted, cited, or acted on, and the agent must not invent facts,' with concrete examples like financial verdicts, legal claims, medical lookups, and public statements. It also gives a when-not-to-use rule and alternative: 'prefer ask_pipeworx for casual lookups' because of the extra LLM call cost.

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