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

With no annotations, the description carries the full burden. It usefully discloses the gating behavior (returns 'full unredacted' deliverables) and the accepted proof types, but says nothing about auth requirements, failure modes for an invalid or reused tx_hash, idempotency, or whether unlocked content persists.

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?

A single dense sentence that front-loads the verb and the verification evidence, then states the payoff. No filler or repetition.

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, so the description must describe returns, and it does name the unredacted deliverables plus a 6-file download pack. It is thin on error/edge behavior for a payment-verification gate, but the core call contract is covered.

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 baseline is 3. The description does reinforce that tx_hash can be a tx hash, wallet address, or order reference and ties plan_price to the paid amount, but adds no format, range, or validation semantics beyond the schema.

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 precise compound action (verify payment + unlock deliverables) with the exact payment rails (Base USDC/USDT, Tonkeeper TON/USDT-TON) and the accepted lookup keys. It is clearly distinguishable from siblings like audit_domain and get_package_manifest without opening any 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?

Usage is only implied: an agent can infer this is the post-payment unlock step, but the description never says when to call it (e.g., after a successful submit_buyer_offer) or when not to. No alternative tool is named or excluded.

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