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

Annotations already declare readOnly/openWorld=false, but the description adds material beyond them: the paid URL and price (0.10 USDC on Base via x402), the shared 10 free signed-wallet calls per 30 days, the X-Wever-Wallet-Proof binding to exact JSON args and route, and an Ed25519 signed receipt in the return. It also explicitly rules out network requests, messages, money movement and external writes. That is the permission, cost and side-effect profile an agent needs before calling.

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?

It is one dense paragraph mixing purpose, a long enumerated summary of report findings, sibling routing, verdict values, transport, pricing, auth binding and links. Most content earns its place given there is no output schema, but the run-on enumeration of gap categories ('every step resting on memory, a last move no step confirms, a stated holder the records do not show…') is hard to parse and could be structured. Better front-loading of the purpose sentence would help.

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 provenance-audit tool with no output schema, the description supplies the return shape (a signed report laying steps end to end plus the classes of findings), the four verdict values (custody_unreconstructable, custody_gaps, custody_unverified, custody_traced), and pointers to the contract and human page. Cost and auth requirements are also covered, so an agent has everything needed to call it 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 100%, so the schema already documents each field; the description nonetheless adds relational meaning — that hops must be 'each step in order', and that evidence is 'a record written at the time, the holder's own report or someone's memory'. It also clarifies current_holder as 'where the task sits now as stated', implying the value is an assertion rather than verified fact. This is above the baseline 3 because it explains how the fields are interpreted together, not just what they are.

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: it reads one task's custody across several agents and lays handoff steps end to end. It also names three siblings it is not (wever_handoff-record-check, wever_incident-evidence-check, wever_handover-check), so an agent can separate it from the closest alternatives. The core statement ('This reads one task's custody across several agents') is buried mid-paragraph behind a long list of report contents, which weakens front-loading.

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?

Gives explicit routing: separate handoff records go to wever_handoff-record-check, incident claims against a timeline to wever_incident-evidence-check, and key/account custody in an operator handover to wever_handover-check. That maps this tool's niche to each neighbour by subject matter rather than leaving the agent to infer. No when-not-to-use condition is stated, but the alternatives cover the realistic confusion cases.

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