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

Annotations already declare readOnly and non-destructive, and the description still adds substantial undisclosed behaviour: no page fetch, no registry or chain lookup, no counterparty contact, and no payment signed or moved. It also discloses the commercial and auth model — 0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days, and the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments and route — and states the return carries an Ed25519 signed receipt. That is exactly the context annotations cannot carry.

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 purpose is front-loaded in the first clause, and the later sentences carry non-redundant operational facts (endpoint, pricing, auth binding, receipt). It is dense and long, and the gap list partially repeats the field list, but no sentence is pure filler. Slightly tighter grouping of the payment and auth details would improve it.

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 still describes what comes back — a report restating the arrangement in order, naming each gap plainly, with an Ed25519 signed receipt — plus the endpoint, contract and human page. For a paid, signed, closed-world read tool, an agent has everything needed to decide and invoke 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 baseline is 3. The description names the six field elements and says a field takes precedence contextually ('the arrangement's own words'), but it does not explain the format enum's text/html behaviour, the label parameter, or the precedence rule that the schema already spells out. It therefore adds only marginal meaning beyond the schema.

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 and resource: it produces a short brief of an operator's succession arrangements, and it enumerates what the brief restates (successor, trigger, key/account transfer, timeline, receives) plus the gaps it names. That is far more concrete than the title alone. It does not, however, distinguish itself from plausible siblings such as wever_continuity-check, wever_handover-check or wever_recovery-readiness-check, so an agent cannot route between them from this text.

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?

Usage is implied rather than stated: it is 'agent preflight round 2' and accepts text, fields or both, which tells an agent the input shape but not the situation that selects this tool over a neighbouring check. There are no explicit when-not conditions and no named alternatives. The 'reads only the material in the call' sentence usefully rules out expecting it to verify anything externally, which is the closest thing to a usage boundary here.

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