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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, and the description adds rich behavioral nuance. It explains the meaning of each verdict, crucially clarifying that could_not_verify means the check did not happen and must not be treated as evidence. It also discloses the two pipeline paths (structured vs. grounded) and the citation behavior, going well beyond annotation metadata. 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?

Though longer than a one-liner, the description is dense and front-loaded with trigger phrases. Every sentence contributes: usage guidance, pipeline routing, return format, verdict semantics, and the replaced-call benefit. No fluff or repetition; the structure makes a complex tool understandable quickly.

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 has no output schema, the description compensates by explicitly listing all possible verdicts, explaining the error payload, and clarifying the difference between could_not_verify and unsupported. It also covers both financial and non-financial domains, making it complete for a verification tool of this scope. The complexity is high, but the description gives enough context for an agent to invoke and interpret results.

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%, so the baseline is 3. The description adds value by explaining how tolerance_pct interacts with the claim wording, including the concrete use case "set 1–2 for hallucination detection where any material error must be refuted." It also gives examples for the claim parameter, enhancing understanding beyond the schema's standard description.

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 clear natural-language trigger phrases and states the core action: "natural-language claim verification against authoritative sources." It distinguishes itself from sibling tools by focusing on fact-checking/claim verification, with a concrete verdict-based outcome. The return format is specific (verdict + value + citation + reasoning), making the tool's purpose unmistakable.

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," giving clear when-to-use context. It also describes the internal routing (SEC EDGAR fast path vs. grounded pipeline) and notes it replaces 4–6 sequential calls. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 5.

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