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

With only readOnlyHint and openWorldHint supplied, the description carries real behavioral weight: it states nothing posted is stored, that share=true converts a contradicted claim into hash-based evidence on the seller's record, that the price is $0.01 USDC per call, the three payment channels, and that failed calls are not charged. Those are exactly the side-effect, cost, and failure-mode facts an agent needs before calling. The share=true evidence write sits in mild tension with readOnlyHint, but the description discloses it explicitly rather than hiding it.

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 trigger and the return contents, then payment terms, then storage and billing caveats — a sensible order. It loses a point for redundancy: the $0.01 price is stated twice in adjacent sentences, and the payment sentence is long and parenthetical.

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?

There is no output schema, so the description compensates by enumerating what comes back (flagged passages, hidden characters, exfiltration links, example mismatch, claim verdict). Combined with the disclosed cost, privacy behavior, share semantics, and failure billing, an agent has everything needed to decide and call correctly.

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 documents body, spans, share, seller, and kyapay-token in comparable detail — the description's 'post the body, or passages of it' restates the schema's 'Or: passages of the body'. The payment-channel explanation adds some framing the kyapay-token field alone doesn't (header vs argument vs x402), but no format or validation detail beyond that. 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?

The description names a concrete operation on a concrete object — take a paid x402 response body (or spans) plus the seller URL and return instruction-like passages, hidden characters, exfiltration links, a mismatch against the declared output example, and whether the 'data, never instructions' claim held. The trigger condition ('when a buyer agent is about to act on a paid x402 response') implicitly separates it from pre-purchase siblings like check_offer or buyer_check, so an agent can place it in the lifecycle without opening the 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?

The opening clause gives an explicit use trigger tied to a lifecycle moment (about to act on a paid response), which is stronger than most definitions. It also spells out the payment options — x402 inside the call, a Skyfire/kya-pay token via header or argument — so the agent knows how to invoke it. It does not state when not to use it or name an alternative tool for overlapping cases, which keeps it below 5.

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