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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description reveals important behavioral traits: the two routing paths, the meaning of each verdict, and especially the critical caveat that 'could_not_verify means the check did not happen... and must not be shown as one.' This is exactly the kind of edge-case transparency that helps an agent act correctly, and it does not contradict any annotation.

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 dense but well-organized: it starts with trigger examples, then usage, then the two-path logic, then return values, then critical caveats, and ends with a performance note. Every sentence carries substantive information, and the most important operational warning (about 'could_not_verify') is set off with 'IMPORTANT for callers.'

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?

Despite no output schema, the description lists all possible verdicts and explains the difference between 'could_not_verify' and 'unsupported.' It specifies the data sources, the tolerance-based grading, and the citation format (pipeworx://). For a tool with only two parameters and read-only semantics, this is remarkably complete—an agent can confidently 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%—both 'claim' and 'tolerance_pct' have clear descriptions with examples and defaults. The tool description itself does not add direct parameter detail beyond mentioning 'exact percent-delta math' and 'tolerance implied by wording,' which is light. Since the schema already provides robust semantics and the baseline for full coverage is 3, this is appropriate, though the description could have reinforced the role of tolerance_pct more explicitly.

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 concrete trigger phrases ('Is it true that…', 'fact check', 'verify the claim') and states the core function: natural-language claim verification against authoritative sources. It sharply distinguishes this tool from generic research/query siblings by specifying two distinct pipelines (SEC EDGAR for company-financial claims, grounded pipeline for everything else) and enumerates the exact verdict types returned.

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,' which is a clear when-to-use directive. It also clarifies that company-financial claims go through a fast path and any other factual claim uses the grounded pipeline, effectively covering all factual claims. However, it does not name alternative tools or state when NOT to use it (e.g., for open-ended research), though the context implies this.

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