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

Annotations already declare readOnlyHint and openWorldHint=false, but the description adds substantial non-structured behavior: no page fetch, no account access, no counterparty contact, no money movement, an Ed25519 signed receipt on the response, per-call cost of 0.10 USDC via x402 exact, ten free wallet-signed calls per rolling 30 days, and the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments and route. These are real invocation constraints an agent cannot derive from annotations alone.

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 and comparison semantics are front-loaded, then payment/contract details, with no repeated filler. The trailing contract path, human page URL, and marketing framing ('Commerce Assurance', 'Diligence-checks') are the least load-bearing sentences but are short enough not to bury the core.

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 nested-object, no-output-schema, paid endpoint, the description covers what the report contains (itemized differences plus verdict plus signed receipt), the auth mechanism, and the cost model, which is the information an agent needs before spending money. It stops short of describing error behavior or what happens when optional receipt fields conflict with the payment.

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?

With only 50% schema description coverage, the description compensates well by enumerating which fields are actually compared (amount, currency, payer, payee, reference, date) and clarifying edge semantics such as a payment before issue or after the due date and name-versus-account payee differences. It does not explain the optional 'label' field or the receipt's role beyond 'optional', leaving a small gap.

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 ('submit one invoice, one payment or transfer record and an optional receipt') and then defines the comparison surface precisely: amount, currency, payer, payee, reference, date, with verdicts exact/partial/mismatch. That comparison contract separates it cleanly from sibling tools like wever_invoice-check or wever_payment-instruction-check without needing schema access.

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?

Usage is implied by the input contract (one invoice plus one payment, receipt optional) and by 'Reads only the material in the call,' which tells the agent no external lookup is needed. However, it never names an alternative tool or states when a different sibling should be chosen instead, so an agent must infer that this is the reconciliation option among the invoice/payment family.

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