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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new context by stating the call is free and describing the state machine (awaiting_payment, queued, done) plus what a completed job yields. It omits non-happy-path behavior such as what happens for an unknown, expired, or unpaid id.

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?

One sentence, front-loaded with the cost signal ('Free') and the core purpose, then the state and result enumerations. No filler or repetition of the tool name.

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 an output schema present, the description does not need to enumerate return fields, yet it does so helpfully; the prerequisite link to x402_delivery_check and the free/paid distinction are the key unknowns an agent would have, and both are covered. Only polling/retry expectations and error states are 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 coverage is 100% and the single id parameter is documented in the schema (including its 10-char pattern). The description corroborates the id's origin (it comes from x402_delivery_check) but adds no format or validation detail beyond the schema, so the baseline 3 applies.

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 resource (status of a delivery check) tied to a named sibling (x402_delivery_check), so the agent can tell it apart from x402_quick_check or x402_preflight without reading schemas. It also enumerates the lifecycle states and the terminal result payload, making the scope unambiguous.

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?

Clearly establishes the prerequisite context — the check must first be ordered with x402_delivery_check (or the equivalent HTTP endpoint) — which is the primary when-to-use signal. It stops short of explicit exclusions or guidance on how to distinguish this from other status-like siblings such as check_payment_proof or verify_receipt.

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