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

Annotations cover only readOnly/openWorld, but the description adds the charging contract that actually governs agent behavior: only final outcomes are billed, not-found/unvalidated transactions are not charged, bad input and ledger outages are free, and a payment watch is billed from the first call. It also discloses the data provenance (validated ledger only) and the output artifact, which annotations cannot express.

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-loads what the tool returns before the pricing and charging rules, and the dense sentences each carry distinct information. It runs long for a tool description, but no sentence is pure filler given the payment model it must explain.

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?

There is no output schema, so the description correctly compensates by enumerating the receipt contents, image dimensions, and explorer QR code. Combined with the charge policy, an agent has what it needs to call and interpret results; only the semantics of the optional expectation-check parameters remain under-explained.

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 7 parameters and only 57% schema description coverage, the description is the only place some semantics could be filled in, and it largely is not. It gestures at the optional filters via "optional expectation checks" and echoes destination tag/ledger/result, but never explains how amount, issuer, currency, destination, or destination_tag constrain matching against the transaction. Baseline 3 for partial coverage with marginal added meaning.

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 concrete verb and artifact: it produces a verified payment receipt image (1200x675 PNG) for an XRP Ledger payment, and enumerates the fields rendered into it. That distinguishes it from read-only siblings like payment_check or ledger_moment by output format and use case, though it never names an alternative directly.

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 a clear triggering context ("Useful for showing a person proof that a payment arrived") and pricing conditions that affect when to call (first call each day free, ~$0.02 after). It does not name sibling alternatives or explicitly say when NOT to use it versus a plain payment check.

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