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

The description goes far beyond the readOnlyHint/idempotentHint annotations by disclosing the internal routing (SEC EDGAR vs. grounded pipeline), the exact verdict return set, the meaning of 'could_not_verify' (including that it must not be shown as evidence), and the meaning of 'unsupported'. It also reveals edge-case behavior with verification_error{stage,detail}. No contradiction with annotations.

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 lengthy but densely packed with necessary information. It front-loads with natural-language trigger phrases, then progressively covers usage, routing, output, and caveats. Every sentence adds value—even the final 'Replaces 4–6 sequential calls' communicates efficiency. No filler.

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 must explain return values, and it does: the verdict enums, the grounded/structured value with citation, and reasoning. It also covers error semantics and routing, making the tool fully understandable without further lookup. This is a complete picture for a complex NLP-based tool.

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 describes both parameters with 100% coverage. The tool description adds crucial usage nuance for tolerance_pct—explaining that it overrides the wording-implied tolerance, with a default capped at 5, and suggesting 1–2 for hallucination detection. The claim param is also exemplifed in the schema, so semantics are fully fleshed out.

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 explicit natural-language triggers and states the tool's core function: 'natural-language claim verification against authoritative sources.' It also distinguishes from sibling tools by noting it replaces 4–6 sequential calls, making it a dedicated claim-checking tool rather than a generic research or ask 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 states when to use: 'Use whenever the agent needs to check whether something a user said is factually correct.' It also explains the routing logic for financial vs. other claims, giving clear context. However, it does not explicitly name alternative tools for when not to use this one.

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