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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description adds substantial behavioral context on top: the honesty contract ('never a guessed verdict'), error isolation ('reports its error in place without sinking the rest of the batch'), ordering ('results come back in input order'), and strict-source fallback behavior. This goes well beyond what annotations convey.

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 front-loaded with the core purpose and sibling distinction, then adds dense, non-redundant behavioral and usage details. Every sentence earns its place: batching rationale, verdict engine equivalence, honesty contract, batch limits, ordering, and error isolation are all useful and specific.

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?

The description covers what the tool does, when to use it, how to batch claims, error behavior, fallback semantics, and output characteristics. Since an output schema exists, detailed return-value explanation is unnecessary, and nothing essential for correctly selecting or invoking this tool is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining the claims array's purpose ('extract every checkable macro claim from the text'), the rationale for the 15-item cap ('free-tier subrequest budget'), and the batch behavior tied to strict_source. It does not deeply redefine each parameter, but it enriches the schema's already strong 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 states a specific verb and resource: 'Fact-check a whole draft or report in one call' and explicitly contrasts itself with verify_stat by saying 'instead of calling verify_stat once per figure.' This clearly differentiates the batch tool from its sibling and tells an agent exactly what it does.

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?

It gives explicit when-to-use guidance by naming verify_stat as the alternative and explaining the batch approach. It also provides concrete usage limits and splitting instructions: 'Accepts 1–15 claims per call' and 'Split larger drafts into multiple calls of up to 15.'

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