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

Annotations already indicate read-only/idempotent behavior, but the description adds depth by explaining verdict semantics, the meaning of `could_not_verify` (check did not happen, not evidence), and `unsupported` (no source found). It also flags that `could_not_verify` carries a `verification_error` and must not be treated as a verdict. This surpasses annotation-only transparency.

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 longer than typical, but every sentence adds vital information: trigger phrases, routing, verdict list, error-handling instruction, and efficiency claim. It is front-loaded with the key purpose and usage, making the initial scanning easy.

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 no output schema, the description compensates fully by listing the verdict values, the presence of a citation, reasoning, and the error payload. It covers the two routing paths and explains edge cases. The tool's complexity is high, and this description addresses all key aspects an agent needs to invoke it correctly.

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?

Although the schema already fully describes both parameters, the description adds crucial semantic nuance: `tolerance_pct` overrides the tolerance implied by the claim wording and that it defaults to wording-based (capped at 5). It also gives a concrete example of the `claim` parameter, clarifying natural-language format beyond the schema.

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 natural-language phrasing and clearly states the tool's function: 'natural-language claim verification against authoritative sources.' It distinguishes itself from siblings by describing its two-pipeline behavior (SEC EDGAR for company-financial claims, grounded pipeline for everything else) and explicitly notes it replaces 4–6 sequential calls, making the unique value proposition obvious.

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.' It further gives granular guidance on when the structured SEC path applies versus the grounded fallback, and warns what `could_not_verify` means for callers. This is strong when-to-use guidance with clear routing logic.

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