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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real value beyond them: the three return statuses (PASS, MISMATCH with difference in cents, NOT CHECKABLE when a value is missing) and the use of integer cent math. It could go further on edge behavior (e.g. how multiple mismatches are reported, or partial-line failures), which keeps it from a 5.

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?

Front-loaded with the trigger condition, then results, then exclusions — a logical order with no filler sentences. The parenthetical field list is somewhat long, but each clause still carries distinct information.

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 annotations, a full output schema, and 100% parameter coverage already supplied, the description covers everything remaining an agent needs: the trigger, the checks performed, the status vocabulary, and the scope boundaries. Nothing essential to correct invocation 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%, including per-field examples and the decimal_mark enum, so the schema carries the parameter burden. The description restates the field families (quantities, unit prices, line amounts, subtotal, discount, tax, shipping, total) but adds no format or parsing guidance beyond what the schema already says; integer cent math is the only real addition.

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?

States a specific verb and resource ('check whether the invoice adds up') and enumerates the exact three arithmetic checks performed. It also names the sibling it is not ('does not read files (use read_invoices for PDFs)'), so an agent can separate it from read_invoices without opening either schema.

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?

Gives an explicit trigger ('when the user types or pastes invoice amounts... and wants to know whether the invoice adds up') plus explicit exclusions: no file reading, no tax-rate computation, no payment or sending. The alternative tool for PDFs is named directly.

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