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

Annotations only declare the generic safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description adds far more: the two-call challenge/retry flow, that the server holds no keys and never signs or settles, non-refundable probe fees, no-charge-if-assessment-fails, and reading amount from accepts[0]. The only small gap is that it doesn't say whether repeated identical calls are billed repeatedly, which is implied but not stated. No contradiction with annotations: spending money with no signing/settling is consistent with readOnly=false, destructive=false, idempotent=false.

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-loaded with the selection condition before the mechanics, and nearly every clause carries decision-relevant information. It is a single dense block of ~250 words; splitting the payment flow, probe behavior, and caveats into separate sentences/sections would improve scanability without cutting content.

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, yet the description specifies what is returned (the report, a base64 PAYMENT-RESPONSE settlement receipt, and an optional probe_report with verdict and truncated extracts, never the verbatim third-party body). For a two-call paid tool with a nested probe object, nothing an agent needs to call it correctly is 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 already 100%, so the baseline is 3, but the description adds real meaning: payment_signature_b64 is a retry-only argument produced by signing accepts[0], and probe changes the price to $0.25 plus the endpoint price X and adds a probe_report block. It doesn't restate field limits, which the schema already handles.

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 verb and resource (buys one fresh AI assessment of a shortlist, priced in USDC) and explicitly distinguishes itself from x402_search_services, x402_find_best_service, and x402_get_service. An agent can tell exactly what it gets here versus the free siblings 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?

Gives an explicit precondition chain: 2-8 finalists held, stored fields insufficient for the stated need, and cost of a wrong choice exceeding a quarter. Names the alternative path for the non-qualifying case (free cached reads via x402_get_service), so both when-to-use and when-not-to-use are covered.

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