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

Annotations already declare readOnlyHint/openWorld=false; the description goes further with what the agent cannot know otherwise: a per-call price (0.10 USDC on Base via x402 exact), the shared 10 free signed-wallet calls per rolling 30 days, the required X-Wever-Wallet-Proof binding to exact JSON arguments and route, and an Ed25519 signed receipt in the response. It also enumerates the verdict set (separated, mixed, boundary_unverified), which is essential for interpreting results.

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?

Purpose is front-loaded, but the first sentence is a long run-on with nested parentheticals that takes effort to parse. Payment, wallet-proof and contract-link boilerplate is necessary but consumes roughly half the text and could be tightened without losing meaning.

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 5-parameter, annotation-covered, output-schemaless tool, everything an agent needs is present: what to submit, the three possible verdicts, that a signed receipt comes back, that there are no side effects, and the cost/auth mechanics. No material gap remains.

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 baseline is a 3, but the description adds semantic meaning the schema does not: 'each store's role, what it is keyed by and when it is cleared' explains how role/keyed_by/cleared relate, and the crossing clause explains that 'by' (code/model/person), 'what' and 'rule' describe the actual transfer. It stops short of explaining consequences of specific enum choices such as on_failure=promote.

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?

Opening sentence gives a concrete verb (submit) plus the exact resource: the store topology, crossings, failure behavior and concurrency for an agent's run state vs. durable memory. It explicitly separates this from the sibling wever_memory-design-check (store inventory with reads and writes), so an agent can route without opening either schema.

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 names the alternative explicitly (wever_memory-design-check) and states what that one covers, which is real routing guidance. It does not state when this check should be skipped or what prerequisites make a submission meaningful, so it stops short of full when/when-not guidance.

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