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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description goes well beyond them: scheduling stops at once, an in-flight check is discarded, already-recorded fires persist and remain readable, and the ended-watch case returns the final state rather than erroring. It also discloses auth mechanics (X-Wever-Wallet-Proof bound to exact JSON arguments and route), payment terms (0.10 USDC on Base via x402, 10 signed-wallet free calls per rolling 30 days), and that a signed receipt is returned — all context an agent cannot get from the annotations.

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 behaviour is front-loaded in the first three sentences and the operational details (endpoint, payment, auth headers, contract, human page) follow in a predictable block. It is dense and slightly over-packed with plumbing references (POST /api/watch-cancel, /api/watch-contract, human page URL) that an agent may not need in every call, but nothing is genuinely redundant.

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 destructive, paid, authenticated mutation with no output schema, the description supplies the outcome semantics, the paid/free call accounting, the auth requirements, the receipt return, and a pointer to the contract document. Nothing an agent needs in order to invoke it safely 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?

With a single required parameter at 100% schema description coverage, the schema already explains watch_id and its pattern, so the description adds nothing parameter-specific. It does not restate the format or note any constraints on the identifier, which is fine but earns only the baseline.

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 — 'cancel a watch owned by the calling wallet' — with an ownership scope that immediately frames the operation. Siblings wever_watch-create, wever_watch-list and wever_watch-status are implicitly distinguished by the verb and by the note that recorded fires remain readable via wever_watch-status.

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 description explains what to expect in the edge case (cancelling an ended watch returns its final state) and redirects read access to wever_watch-status, which is real routing guidance. It stops short of an explicit 'use this only when X' / 'use wever_mandate-halt instead' style rule, so it is clear context without full exclusions.

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