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

Well beyond what readOnlyHint/openWorldHint/destructiveHint already declare: it discloses the POST route, the 0.10 USDC x402 charge on Base, the 10 free signed-wallet calls per rolling 30 days, the X-Wever-Wallet-Proof binding to the exact JSON arguments and route, and an Ed25519 signed receipt. The only shortfall is that it does not explain failure modes (e.g. what happens when the wallet proof does not match or payment is declined), though the readOnly/no-money-movement claim is consistent with the annotations.

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?

Purpose, outputs and the alternative tool are front-loaded ahead of operational detail, and almost every sentence carries decision-relevant information. The opening sentence is long and dense with a nested parenthetical, and the payment/receipt/contract-URL tail is somewhat sprawling, which costs a point.

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 ten-input reconciliation tool with no output schema, the description covers inputs, the reconciliation logic, the two verdicts, the report contents with totals, and delivery as an Ed25519 signed receipt. An agent has everything needed to decide to call it and to interpret the response shape.

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 schema already defines each field, but the description adds real meaning by pairing 'the transaction amount each was charged on' with 'percentage rates, flat fees, minimums and caps', making clear how each fee row maps to a schedule entry. Tolerance and decimals are left entirely to their schema descriptions, so it does not fully compensate on the matching logic.

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?

Opens with a specific verb and resource: submit the fees charged plus the stated fee schedule, and get a signed report that recomputes expected fees and itemizes overcharges, undercharges and unmatched entries. It also names the sibling it is not ('Public fee claims are wever_fee-evidence-check'), so an agent can route between the two 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?

States the input material required (date, payer/payee, amount, fee label, transaction amount, plus percentage/flat/min/cap schedule), the alternative tool for public fee claims, and the two possible outcomes (reconciled or discrepancies_found). Scope exclusions are explicit: no wallet, chain, market, bank or counterparty lookup and no money movement.

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