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

The description adds substantial context beyond the annotations: caller cost ($0.25 USDC), the service's own spend cap ($0.1 from its own wallet), payment rail (Base), async job-id behavior, the free polling follow-up, and a signed EIP-191 receipt bound to the arguments. One tension: readOnlyHint=true while the description frames the operation as 'not a reading but a purchase' that spends funds and may POST, so the annotation understates the side effects even though the text is honest about them.

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 price and the key reframing ('not a reading but a purchase') are front-loaded, and each sentence carries distinct information (cost, mechanism, prerequisite, follow-up, receipt). It is dense rather than bloated, though the receipt sentence and the 'Same as GET /api/v1/delivery-check' remark could be trimmed for a selection-time blurb.

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?

For a paid, asynchronous, open-world tool, everything an agent needs is present: cost, prerequisites and refusal conditions, the async job-id pattern, the free status tool to poll, and the receipt guarantee. An output schema also exists, so return-value detail is not the description's burden.

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 both parameters are already documented, and the description adds little beyond the schema: it restates that the url must be someone else's and payable in USDC on Base, and says nothing about the method parameter or the GET-then-POST default. Baseline 3 is appropriate when the schema carries the parameter semantics.

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+resource: it buys an x402 endpoint once, checks the response against the declared output schema, and measures the on-chain charge. It is clearly distinguishable from sibling diagnostics (x402_preflight, x402_quick_check, x402_diagnose, x402_delivery_status) because it is the one that actually pays the endpoint, not just inspects it.

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?

It gives real preconditions ('The endpoint must get a "go" from the pre-payment check and be payable in USDC on Base; otherwise it is refused before payment') and routes the agent to the free follow-up (x402_delivery_status). What is missing is an explicit statement of when to prefer this over e.g. x402_quick_check or x402_diagnose, so the agent must infer that this is the paid, definitive check.

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