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

The description goes far beyond the readOnly/openWorld/idempotent annotations by disclosing the routing behavior (financial vs non-financial), the full verdict vocabulary and their meanings, the distinction between 'could_not_verify' (no evidence) and 'unsupported' (no coverage), and the inclusion of citations. It also explicitly warns callers not to treat 'could_not_verify' as evidence for or against a claim, which is critical behavioral nuance.

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 thorough but verbose, at over 200 words for a simple 2-param tool. It front-loads the purpose and includes valuable behavioral details, but the many example phrases, routing details, and caller warning could be tightened into a more concise structure while preserving the necessary nuance.

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 explains return values: verdict, actual value with pipeworx:// citation, and reasoning. It also clearly details error semantics ('could_not_verify' with verification_error) and the distinction from 'unsupported', ensuring an agent can safely invoke and interpret results without additional external documentation.

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 input schema already fully describes both parameters, including the claim example and the tolerance_pct semantics, default, and override guidance. The tool description adds little beyond inline examples already covered by the schema; with 100% schema description coverage, a baseline score of 3 is appropriate.

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 clear, specific purpose: 'natural-language claim verification against authoritative sources' and lists example query phrasings to anchor it. It distinguishes itself from siblings by describing the structured SEC EDGAR/XBRL fast path for company-financial claims and automatic fallback to a grounded pipeline for any other factual claim, making clear it is the dedicated fact-checking tool.

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 explicitly instructs 'Use whenever the agent needs to check whether something a user said is factually correct' and explains coverage of both company-financial and non-financial claims. It does not explicitly name when-not-to-use alternatives, but the statement 'Replaces 4–6 sequential calls' gives a strong strong indication to prefer this tool over manual multi-step lookups.

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