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

Annotations already declare readOnlyHint=true and openWorldHint=false; the description adds value beyond that by spelling out exactly what 'reads only' means (no fetch, money movement, message, sharing, configuration change or external write) and by disclosing the commercial and auth layer: 0.10 USDC per call on Base via x402, 10 signed-wallet free calls per rolling 30 days, X-Wever-Wallet-Proof bound to the exact JSON arguments and route, and an Ed25519-signed receipt. It does not state failure or validation behavior, keeping it at 4.

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 by domain but delivered as one long run-on paragraph with repeated 'and ... and ...' chains that force re-reading. Sentences largely earn their place, but the exhaustive enumeration of fact types duplicates schema enums and could be compressed without information loss.

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 nested six-parameter tool with no output schema, the description carries the return side itself: the four readiness pieces, the verdict vocabulary (not_ready, implied_readiness, readiness_unverified, ready_for_agent_buyers), the signed receipt, and pointers to the contract and human page. Only edge-case behavior on malformed or partial input is left unstated.

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?

With schema description coverage at 33%, the description compensates well: it explains the semantics of disclosure timing (before payment, in the 402 challenge, after payment or not at all), the stated-versus-implied distinction, the four pricing models with quote binding and cap, the rehearsal taxonomy, and the refund routes — mapping closely onto the pricing, disclosure, rehearsal and reversal objects. It says little about the provider object's name/endpoint fields, which remain undocumented.

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 verb and resource — submit a provider's public purchase facts and receive a signed readiness report — and explicitly disambiguates from four siblings (wever_recovery-readiness-check, wever_payout-readiness-check, wever_adoption-readiness-check, wever_public-surface-check). It does not distinguish against nearby single-fact siblings such as wever_rehearsal-check, wever_refund-path-check or wever_price-truth-check, and the opening clause is buried in dense prose, so it falls short of a 5.

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 routes the agent explicitly: readiness for recovery, payouts and adoption go to named alternatives, and a summary sample is offered at a specific URL. What's missing is a when-not-to-use rule for the overlapping single-fact checks, but the alternative mapping is clearer than most.

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