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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses detailed behavioral semantics: the full verdict vocabulary, that evidence is returned with pipeworx:// citations, and the crucial distinction between could_not_verify (a failed check, not evidence) and unsupported (no source found). It also explains the internal pipeline stages, giving the agent an accurate mental model of what happens.

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 long but densely informative, front-loading usage examples and then layering routing, verdicts, and error semantics. Every section adds value, though a few phrases like 'routed to the right live source, answered with verbatim evidence, then judged' could be tightened without losing meaning.

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 and lack of an output schema, the description is remarkably complete: it specifies all possible verdicts, explains what evidence and reasoning are returned, clarifies error handling with verification_error{stage,detail}, and even notes the tool replaces multiple sequential calls. No critical behavioral aspect is left unexplained.

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 coverage is 100% and both parameters are well-documented in the schema, so the description does not need to add parameter syntax. The description adds context about 'exact percent-delta math' and the tolerance default, but this is marginal beyond the schema's existing description of tolerance_pct overriding claim wording.

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 concrete natural-language examples and clearly defines the tool as claim verification against authoritative sources. It distinguishes itself from siblings by explaining the two routing paths (SEC EDGAR/XBRL for company-financial claims, grounded pipeline for everything else) and by noting it replaces 4–6 sequential calls.

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?

It explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct,' which is clear usage guidance. It also provides routing details for company-financial vs. other factual claims, but does not explicitly name alternative tools or state when not to use this tool.

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