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

Annotations already declare read-only, idempotent, non-destructive and open-world behavior, so the description's job is to add economic and procedural context — and it does: $0.003 per call, settled over x402 with USDC on Arc/Base/Solana or XNT on X1, and the two-step terms-then-pay handshake. It also explains the verification semantics (balance-change based, so program-sent payments count; confirmed vs finalized), which annotations cannot convey. What it omits is failure behavior (expired or already-consumed payment payloads) and whether a failed verification still incurs the charge.

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 rhetorical opener front-loads the purpose in six words, and the remaining sentences carry pricing, rails, verification semantics and the payment handshake with little waste. The middle sentence is long and packs several ideas (confirmation level, memos, fee, expectation check) into one clause chain, but nothing is expendable.

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?

With five parameters, one required, no nested objects and no output schema, the description covers what an agent needs before calling: the cost, the payment protocol, what the verification is based on, and roughly what gets reported back (payer, received amount, confirmation level, memo, fee, expected-vs-actual). The absence of any statement about the response shape is the main residual gap, partially compensated by the enumerated check items.

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 the schema already defines every parameter and the baseline is 3. The description adds some real meaning — that omitting `mint` means native XNT, that amounts are compared against an expected value, and that `payment` carries the signed base64 payload that completes the purchase inline — but it does not clarify units, formatting, or how `expect` and `to` interact with the balance-change result.

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 concrete verb-and-resource: verify that a specific X1 transaction's payment actually landed, reporting payer, amount received by a named wallet in XNT or any SPL token, confirmation level, memos and fee. It is scoped to X1 so it is distinguishable from the Arc-oriented siblings, but it never explicitly contrasts itself with payment_verify, arc_payment_check, or x402_payment_test, so an agent must infer the split from the chain name alone.

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 context is clear: you have a signature (and optionally an expected recipient, mint and amount) and you want to confirm what actually arrived. It also documents the required invocation sequence — call once without `payment` to get terms, sign with your own wallet, call again with `payment` — which is genuine when-to-call guidance. It stops short of naming alternatives or stating when not to use it.

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