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

Beyond the annotations (which already cover readOnly/non-destructive/non-open-world), the description adds substantial operational context: it reads only the material in the call, with no network request, fetch, money movement, message, sharing, configuration change or external write. It also discloses the paid URL, the x402 exact price of 0.10 USDC on Base, the 10 free signed-wallet calls per rolling 30 days, and the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments and route.

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 content is front-loaded with the purpose in the first sentence, but that sentence is extremely long and packs seven distinct fields into one clause. Pricing, wallet-proof binding, endpoint path, contract link and human page are appended in the same undifferentiated block, making the description hard to scan despite little outright waste.

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 no output schema, the description carries the return burden well: it enumerates the four verdicts and describes what the signed report names, including the Ed25519 signed receipt. Combined with the read-only guarantees, pricing, and wallet-proof auth requirement, an agent has everything needed to call this nested-object tool 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 coverage is 67%, and the description adds meaning beyond the schema by mapping the evaluable fields to their purpose: when liability is agreed, who pays per error case, the liability cap, the dispute path (forum, decider, window), the standing of the payment record, and every way a purchase can proceed. The only parameter it does not touch is 'label', which is minor. This compensates well for the coverage gap.

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 resource and scope: it takes the pre-purchase terms between an agent's operator and a seller/platform and evaluates the liability arrangement. It also differentiates the resource from sibling checks by saying 'The refund rule is wever_refund-rule-check and a dispute over one payment is wever_dispute-open.' The opening verb 'submit' is slightly at odds with a check-style tool, but the enumerated fields and the stated verdicts make the actual purpose unmistakable.

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?

Timing is clearly implied and partly explicit: the terms are 'pre-purchase' and the verdict 'agreed_before_purchase' signals the intended moment of use. Sibling routing hints are provided for refund rules and per-payment disputes, which tells the agent this is not those tools. What is missing is an explicit 'do not use this when X' statement, so it falls short of a full when/when-not statement.

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