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

The annotations mark the tool readOnly, non-destructive, closed-world and non-idempotent, and the description reinforces this with concrete detail: no network request, no wallet or merchant lookup, no order, payment or external write. It also discloses things the annotations cannot: the 0.10 USDC x402 price per call on Base, the shared 10 signed-wallet free calls per rolling 30 days, the X-Wever-Wallet-Proof binding to the JSON arguments and route, and the Ed25519 signed receipt in the response.

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 front-loaded with what the tool does and what the verdicts are, then moves to the sibling alternative, then to transport, pricing and auth. It is dense but every block earns its place for a paid, wallet-bound tool. It is nonetheless long: the contract URL and the human page could be consolidated, and the payment boilerplate occupies several sentences.

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?

No output schema exists, yet the description states the return shape it needs to: a report containing a signed receipt and a verdict of mismatches_found, gaps_found or complete, plus the enumerated exception lists. Payment, authentication and the readiness of the call are all covered, so nothing an agent needs in order to call it correctly 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%, so all five top-level parameters and their nested fields are already documented, which sets a baseline of 3. The description adds meaning beyond that schema by explaining how job_reference, payment reference and the per-payment job_reference fields interact, and by naming the exception classes it reports, such as names-another-job, payment without receipt and receipt without payment.

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 states a specific verb and resource: submit a job reference with the payments and receipts you hold, and the signed pack reconciles them against the job. It also distinguishes this tool from its sibling wever_receipt-verify, which verifies a single Wever signed receipt, so an agent can tell the two apart 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?

The description gives clear conditions for use: it says to submit every payment and receipt for one job, and it routes single-receipt verification to wever_receipt-verify. It does not state when this pack is unnecessary, for example how small or large a set of records must be, and it names no other alternatives beyond that one sibling.

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