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

Beyond the readOnly/openWorld annotations, the description discloses that only the material in the call is read, with no network fetch, money movement, message, sharing, configuration change, or external write. It also adds material operational facts the annotations cannot convey: the 0.10 USDC x402 price on Base, the ten free signed-wallet calls per rolling 30 days, the X-Wever-Wallet-Proof binding requirement, and an Ed25519-signed receipt.

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, but the body is a single dense run-on paragraph with chained colons and semicolons covering inputs, verdicts, pricing, auth binding, and links. Every element is relevant, yet the lack of paragraph or bullet structure makes the agent work harder to separate purpose from payment and provenance details.

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 characterizes the return value (a signed report naming every element that can outlive its source, every stale-context decision, and the closing invalidation rule, plus the verdict set). Pricing, authentication binding, and a contract link are also supplied, leaving nothing essential for a correct call unstated.

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 already 100%, but the description adds relational meaning the schema does not: cached elements are linked to what changes underneath them (feeds) and to the decisions made from them (reads), and it spells out that each element needs what it holds, its TTL, and the events that clear it. This explains the design model rather than merely restating field names, though the individual syntax of fields like ttl or apply_within is left to 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: submit a caching design for agent context or instructions and receive a signed staleness report. It further enumerates the required design elements and the verdicts returned (outlives_changes, freshness_unverified, invalidated_on_change), and explicitly distinguishes itself from the sibling wever_memory-design-check, which handles agent memory stores instead.

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 context is clear: use this when you have cached context or instructions whose staleness against source changes must be audited, and route memory-store designs to wever_memory-design-check. However, no explicit 'when not to use' is given, and other freshness-adjacent siblings such as wever_answer-freshness-check or wever_docs-freshness-check are not distinguished.

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