Reconcile three ledgers — what was ordered, what was delivered, what was paid — with every variance naming its direction

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the bar is lower. The description does add real value beyond them: the x402 payment requirement (0.50 USD on base/eip155:8453) and the concrete POST route, which tells the agent this call costs money and needs payment handling. It says nothing, however, about non-idempotency or how tolerance thresholds affect matching.

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?

Two short blocks with the reconciliation purpose front-loaded and transport/pricing kept as a separate clause. No filler; slight deduction because the parenthetical '(PAID $0.50)' duplicates the price restated in the following sentence.

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?

An output schema exists, so return values need no explanation. But for a 5-parameter tool with zero required fields and 0% schema coverage, the description leaves out how the three ledgers are joined, what happens when an order_id appears in only one ledger, and what the tolerance parameters control — gaps an agent must guess at.

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 0%, so the description must compensate and largely does not. The three ledger names map roughly onto orders/deliveries/payments, but amount_tolerance and quantity_tolerance — the parameters that most change results — are never mentioned, nor are units, defaults, or the fact that order_id is the join key.

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 names a specific verb (reconcile) and its exact resources — the ordered, delivered and paid ledgers — plus the output trait that variances carry direction. It is unambiguous about what the tool produces, though it does not distinguish itself from nearby tools such as v1_bio_labassets_reconcile or v1_spend_ledger_attest.

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?

Three-way matching implies its own use case, so the context is inferable, but there is no explicit 'use when...' or statement of when a sibling (e.g. a settlement or attestation tool) is the better choice. The only routing information given is the transport endpoint and price, not the decision criteria.

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