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

Beyond the annotations (readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false), the description adds substantial behavioral context: verdicts are recomputed every call, nothing is stored, later filings can restate numbers, and editing changes a figure's identity. It also clarifies the semantic distinction between not_checkable and untraced, and what scope means for wrong citations. This goes far beyond the structured annotations and no contradiction exists.

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 clause earns its place — it packs verdict semantics, workflow sequencing, error handling, and caveats. It is front-loaded with the core action and verdict definitions, then moves to procedural guidance. While dense, the length is justified given the tool's complexity; it avoids redundant 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?

For a complex verification tool, the description is exceptionally complete. It explains not only what the tool returns (verdicts) but also how to interpret each outcome, what to do next, what not to do, and the tool's stateless, recompute-on-call behavior. The existence of an output schema further relieves the need to document return structure, and the description covers all remaining operational context an agent needs.

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?

The single parameter report_id already has 100% schema description coverage, including its source formats and the authoring constraint. The description reinforces this by stating 'Only the report's author can verify it' but does not add new format or syntax details. Per the rubric, when schema coverage is high, the baseline is 3, and the described behavior matches the schema without adding further parameter-level meaning.

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 begins with a specific verb and resource: 'Check EVERY number in one of your own reports against the filing it cites, in one call.' It enumerates the three verdict types (matches, differs, not_checkable), making the tool's function unmistakable. It also differentiates itself from related workflow tools by explicitly naming publish_report, update_report, and save_figure_review, and its focus on report figures vs. generic fact checking is clear from the sibling context.

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 when-to-use guidance: 'CALL THIS BEFORE publish_report OR sign_off_report' and explains the consequence of not doing so (publish_report REFUSES an unreviewed differs). It also provides clear post-conditions and alternatives: use update_report to fix a differs, save_figure_review for human disposition, and do NOT retry on not_checkable. The author-only constraint and free-tier note further refine usage.

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