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

Annotations already declare readOnly/openWorld/idempotent, but the description adds critical behavioral context beyond that: it explains that 'could_not_verify means the check did not happen' and carries verification_error{stage,detail}, explicitly warning it must not be shown as evidence. It also clarifies the difference between 'could_not_verify' (check not performed) and 'unsupported' (no source found), which is not inferable from annotations alone.

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 relatively long but every sentence earns its place: example queries, routing rules, verdict meanings, caller warnings, and efficiency claim are all operationally relevant. It is front-loaded with the purpose (started with natural-language triggers) and ends with a practical note about error handling. Structure is logical, moving from general to specific.

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 and lack of an output schema, the description thoroughly covers return values (verdicts, actual value with citation, reasoning), error semantics (could_not_verify vs unsupported), routing behavior, and usage scope. It also mentions the exact percent-delta math for financial claims, leaving little ambiguity about behavior or 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 description coverage is 100%, so the baseline is 3. The schema already fully documents the 'claim' string and 'tolerance_pct' number with examples and default behavior. The description does not add additional parameter-level details beyond mentioning tolerance in the context of percent-delta math, which is already covered in the schema. No deduction or upgrade is warranted.

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 examples ('fact check', 'verify the claim that…') and clearly defines the tool as claim verification against authoritative sources. It distinguishes itself from siblings by specifying two routing paths: structured SEC EDGAR for company-financial claims and a grounded pipeline for all other factual claims. The verb 'verify' and resource 'claims' are explicit and non-tautological.

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 states 'Use whenever the agent needs to check whether something a user said is factually correct.' It distinguishes between company-financial claims and any other factual claim, indicating the fallback behavior. It also notes that the tool 'Replaces 4–6 sequential calls,' implying when it is more efficient than alternative multi-step approaches.

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