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

The annotations declare that the tool only reads data and is not destructive, and the description goes well beyond them: it discloses the x402 exact payment in USDC on Base, a 0.10 USDC per-call price, a 10-call free tier per rolling 30 days for signed wallets, the X-Wever-Wallet-Proof binding to JSON args and route, and an Ed25519 signed receipt. It also discloses that the tool reads only the public Transfer log. The annotations already imply idempotentHint=false, so the description does not need to repeat that. Note that repeated, paid calls are cumulative in cost.

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 description is front-loaded: it states purpose first, then inputs, then outputs, then access mechanics. The single dense paragraph packs in a lot without filler. The trailing 'Human page' URL is marginally useful, but overall the description earns its space.

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?

There is no output schema, so the description must carry the return shape, and it does: it states totals in and out, net flow, largest transfers, counterparty count with top counterparties by volume, and the exact window covered. It also covers auth, payment, and integrity (signed receipt) plus a contract endpoint for verification. Nothing material for correct invocation 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?

Schema coverage is 100%, and the schema already documents the address checksum handling and the window_days range and default. The description's mention of 'address and optional window_days (default 30, maximum 90)' repeats the schema without adding meaning. Baseline 3 applies because the structured schema does the heavy lifting.

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 concrete verb and resource: a plain-language summary of a Base address's recent USDC flows from public on-chain Transfer logs, and it lists exactly what the tool returns. It is clearly distinct from tools such as wever_counterparty-brief and wever_treasury-flows, but it never names those siblings, so an agent must infer the boundary itself.

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 is implied by the output description (recent-flow totals, top counterparties, exact window), but there is no explicit when-to-use or when-not-to-use guidance. With siblings like wever_counterparty-brief and wever_treasury-flows available, a sentence naming the alternative and the condition that selects it would remove real ambiguity. The pricing and free-tier limits tell the agent about cost, not about routing.

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