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

Annotations already show read-only, open-world, idempotent, non-destructive. The description adds substantial behavioral detail: two distinct processing paths, return verdict list, meaning of could_not_verify (with verification_error fields), and unsupported vs could_not_verify distinction. This is critical context for safe interpretation and exceeds annotation coverage.

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 every sentence carries meaningful information—usage triggers, routing, return values, error semantics. It is front-loaded with the primary use case. Slightly dense but not bloated; could be trimmed slightly without loss, but 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 thoroughly explains return verdicts, evidence citations, and error handling. It covers both claim categories, tolerance behavior, and the critical distinction between could_not_verify and unsupported. Complete for a tool of this complexity.

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 covers both parameters fully, but the description adds unique semantics: tolerance_pct overrides implied tolerance, recommended range for hallucination detection, default behavior (implied by wording, capped at 5). This goes well beyond the schema's basic descriptions and is highly actionable.

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 clearly states the tool's purpose: natural-language claim verification against authoritative sources. It includes trigger phrases ("Is it true that…") and explicitly distinguishes itself as the fact-check tool. It differentiates from siblings like ask_pipeworx by focusing on verifying factual claims, not just answering questions.

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?

Provides explicit guidance: "Use whenever the agent needs to check whether something a user said is factually correct." It also explains routing behavior (SEC EDGAR for company-financial claims, grounded pipeline for other claims) and notes efficiency benefit (replaces 4–6 sequential calls). Doesn't explicitly name alternative tools, but the usage context is clear.

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