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

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds substantive behavioral context: two distinct execution paths (SEC EDGAR/XBRL fast path vs. grounded pipeline), enumerated verdict values, output composition ('grounded or structured actual value with pipeworx:// citation'), and critical semantics distinguishing could_not_verify (with verification_error) from unsupported. No contradictions.

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. It leads with trigger phrases, then quickly covers usage, behavior, return values, and caller cautions. The wording is efficient and avoids redundancy with the schema or annotations.

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 covers return values and their semantics, including verdict list and error handling. It also explains the two routing paths and the tool's efficiency advantage over sequential calls. This is sufficient for an agent to correctly select and invoke the tool, and to interpret results properly.

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%, with clear parameter descriptions. The description adds value beyond the schema by explaining tolerance_pct's override behavior and its intended use for hallucination detection ('set 1–2 for hallucination detection'), and by implying the claim parameter's natural-language form with examples.

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 clearly states the tool's purpose: 'natural-language claim verification against authoritative sources' with specific trigger phrases. It distinguishes itself from siblings by describing a combined pipeline that 'Replaces 4–6 sequential calls' and by explicitly partitioning claim types (company-financial vs. other).

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 says 'Use whenever the agent needs to check whether something a user said is factually correct' and gives concrete examples. It does not explicitly name alternative tools or state exclusions, but the routing logic ('any other factual claim automatically falls through to the grounded pipeline') provides clear contextual guidance.

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