Verify a batch of claimed statistics (fact-check a whole draft)

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

The description explains that the same verdict engine as verify_stat is used, that unverifiable claims return cannot_verify with reasons (never a guessed verdict), and that errors in individual claims are reported in place without sinking the rest of the batch. It also describes strict_source mode and result ordering, adding substantial context beyond the readOnly/idempotent hints.

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 every sentence contributes pivotal information: it front-loads the primary use case, then layers constraints, behavior, and error handling. It is efficiently structured for the tool's complexity, avoiding fluff.

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 a rich output schema and full annotations, the description still manages to cover batch limits, result ordering, error handling, the relationship to verify_stat, and the honesty contract. It is fully sufficient for an agent to decide when and how to invoke the 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%, so the baseline is 3. The description adds contextual meaning for the claims array (max 15, input order, error isolation) and for strict_source (fallback behavior, reproducibility mode), enriching the schema's already detailed property 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 it fact-checks a whole draft or report in one call, distinguishing itself from verify_stat by operating on a batch of claims rather than a single figure. It specifies the extraction of indicator + country + period + claimed value, making the tool's purpose unambiguous.

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?

Explicitly instructs to use this tool instead of calling verify_stat once per figure for whole-draft fact-checking, and gives a concrete limit of 1–15 claims with guidance to split larger drafts. This clearly contrasts with the single-claim sibling and provides actionable when-to-use guidance.

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