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

Annotations already cover read-only/open-world/idempotent, but the description adds substantial behavioral context: the SEC EDGAR fast path, the automatic fallback for other claims, the complete verdict enum, and the crucial warning that could_not_verify means the check did not happen and must not be treated as evidence. It also discloses that it replaces 4-6 sequential calls, providing a clear performance expectation.

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 moderately long but front-loaded with example queries and organized into clear sections (what it is, how it routes, what it returns, caller warnings). Each sentence earns its place, though the opening list of phrasings could be slightly trimmed. Overall it is dense and well-structured without being wasteful.

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 fully explains return values: verdict types, actual value with pipeworx:// citation, and reasoning. It also explains the two pipeline paths, the error condition (could_not_verify vs unsupported), and the distinction between them. This is complete for a complex fact-checking 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?

Schema coverage is 100% with detailed descriptions for both claim and tolerance_pct, so the baseline is 3. The description itself adds no parameter-level meaning beyond the schema; however, the schema already includes important guidance (e.g., tolerance_pct override and hallucination detection use case). The description does not need to compensate.

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, with specific example phrasings like 'fact check' and 'verify the claim.' It distinguishes itself from siblings by describing the unique two-path routing (SEC EDGAR for company financials, grounded pipeline for all else) and positioning as a single-call replacement for multi-step verification.

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' and provides context on when the two internal paths apply. However, it does not name alternative tools or explicitly state when not to use it, so it falls short of the full when/when-not/alternatives requirement.

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