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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses critical behavioral nuances: the meaning of 'could_not_verify' (check did not happen, must not be shown as evidence) versus 'unsupported' (no source found), the response format with citations, and the internal fallback logic. This significantly enhances the agent's ability to interpret results correctly.

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 every sentence contributes valuable information: trigger phrases, use cases, dual-path behavior, return values, error semantics, and efficiency justification. It is well-structured, starting with examples and ending with the rationale for its existence, with 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?

Given the tool's complexity (two routes, multiple verdicts, error conditions) and no output schema, the description is remarkably complete. It enumerates all possible verdicts, explains the verification_error payload, and clarifies ambiguous outcomes, leaving little room for misinterpretation.

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?

Although the schema already covers both parameters, the description adds essential semantics: examples for the claim parameter, and for tolerance_pct it explains the default (implied by wording, capped at 5), the allowed range (0.5–50), and when to override (e.g., 1–2 for hallucination detection). This goes well beyond the schema descriptions.

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 provides specific trigger phrases ("Is it true that…", "fact check") and explicitly distinguishes the two processing paths (SEC EDGAR fast path for company-financial claims, grounded pipeline for all others), making it distinct from any sibling 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 gives explicit usage guidance: "Use whenever the agent needs to check whether something a user said is factually correct." It also explains which claims take which path, and notes that it replaces 4–6 sequential calls, providing clear context for when this tool is the efficient choice.

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