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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, yet the description still adds substantial behavior: it reads only material in the call with no network request, fetch, money movement, message, sharing or external write, states the price (0.10 USDC on Base via x402 exact with 10 signed-wallet free calls per rolling 30 days), the auth requirement (X-Wever-Wallet-Proof bound to the exact JSON arguments and route), and that the result carries an Ed25519 signed receipt plus named verdicts. Nothing contradicts the annotations, and idempotentHint=false is consistent with per-call metered payment.

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 critical scoping and sibling-routing content is front-loaded and the payment, auth and return information all earn their place. However, the first two sentences are long run-on constructions with nested parenthetical lists that are hard to parse in one pass, and some of the verdict/pricing detail could be tightened without 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?

With no output schema, the description carries the return-value burden well: it names the four verdicts (receiver_guesses, transfer_gaps, transfer_unverified, context_travels), describes the part-by-part report and the fix for each gap, and points to the contract and human page. Complete enough to call correctly; the only soft spot is that report structure is described prose-style rather than enumerated.

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 and the schema already defines fields, carries, required and receiver_fills. The description does restate the semantic intent of the model (which parts of context a field carries, whether the format refuses a handoff without it, and the four receiver fallbacks) but adds no new constraint, format, or edge-case guidance beyond what the schema properties already spell out.

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 action on a specific resource: submit a handoff format (its fields, what each carries, whether required, and how the receiver fills gaps) and receive a signed report of what travels versus what is reconstructed or assumed. The core purpose is clear and explicitly differentiated from wever_job-handoff-pack, wever_handoff-record-check and wever_context-sharing-check. It loses a point only because the opening sentence is so long and clause-heavy that the essential 'check a handoff format's context transfer' idea must be assembled by the reader.

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?

Explicitly separates scope from three named alternatives with the condition that selects each: this reads the format every handoff uses, not one job's state (that is wever_job-handoff-pack), the record of handoffs made is wever_handoff-record-check, and consent for sharing is wever_context-sharing-check. The only guidance left implicit is when-not to use the tool at all, which is minor given the sharp sibling routing.

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