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

The description discloses extensive behavioral traits beyond annotations: the two-path processing, the exact verdict set, the special meaning of 'could_not_verify' (check did not happen, not evidence) and 'unsupported' (no source exists), and the return of citations with reasoning. It does not contradict the readOnly/openWorld/idempotent annotations; instead it adds critical nuance about failure modes and result interpretation.

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 highly structured: it opens with trigger phrases, then states the use case, explains the two verification pipelines, lists the verdicts, and closes with important caller caveats and efficiency benefits. Every sentence provides necessary information, so it is not bloated, though it is lengthy for a tool description.

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 (two pipelines, six verdicts, error handling), the description covers everything needed for correct invocation: when to use, what to expect, how to interpret ambiguous verdicts, and why it is more efficient than sequential calls. It adequately describes all return semantics and edge cases, even without an output schema.

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 the description repeats the parameter descriptions almost verbatim (e.g., tolerance behavior, default capping at 5). The claim examples in the description mirror those in the schema, adding no new meaning beyond what the schema already provides. Baseline 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 identifies a specific verb ('verify'/'fact check') and a specific resource: natural-language claim verification against authoritative sources. It clearly distinguishes itself from sibling tools by focusing on fact-checking and even describes the two distinct pipelines (SEC EDGAR for company-financial claims, grounded pipeline for other claims), making its purpose unambiguous.

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 says 'Use whenever the agent needs to check whether something a user said is factually correct,' providing clear context. It does not explicitly name alternative tools or when not to use it, but it does imply that it replaces multi-step sequential lookups, giving a strong sense of when it is appropriate.

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