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

The description discloses rich behavior beyond the annotations: the dual routing path, the full verdict vocabulary (confirmed, approximately_correct, refuted, inconclusive, unsupported, could_not_verify), and the critical caveat that could_not_verify means the check failed (includes verification_error) and must not be treated as evidence. This adds substantial context that annotations alone do not capture.

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 every part serves a purpose: trigger phrases, routing examples, verdict list, and important caller warnings. It is front-loaded and structured well, with the 'IMPORTANT for callers' clause emphasizing the critical could_not_verify pitfall. Slightly dense, but no wasted words.

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?

For a complex tool with no output schema, the description covers the return verdicts, evidence/citation format (pipeworx://), reasoning, and the distinction between could_not_verify and unsupported. It also explains the tolerance override behavior. This gives an agent enough to select and invoke correctly without missing key edge cases.

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%, so the baseline is 3. The description adds extra meaning for tolerance_pct by explaining its default (implied by claim wording, capped at 5%) and recommending 1–2% for hallucination detection. This goes beyond the schema definitions and justifies an above-baseline score.

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 trigger phrases and states 'natural-language claim verification against authoritative sources.' It clearly distinguishes this tool from sibling research/search tools by targeting fact-checking of a user's claim. The specific verb+resource combination is 'verify claim' plus a clear scope of what it does.

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?

Explicitly states 'Use whenever the agent needs to check whether something a user said is factually correct.' It also differentiates two internal routing paths (SEC EDGAR structured vs grounded pipeline) based on claim type. However, it does not name alternative tools for open-ended research or other contexts, so exclusions are implied rather than explicit.

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