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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds substantial context beyond them: pricing (0.10 USDC per call on Base via x402 exact with 10 free signed-wallet calls per 30 days), the auth model (X-Wever-Wallet-Proof bound to exact JSON arguments and route, plus Payment-Signature for paid calls), and the Ed25519-signed receipt in the response. It also reassures that standing jobs never move money or change state, which matters for an agent deciding whether to call.

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 payload enumeration is front-loaded, which is good, but the body then stacks endpoint path, pricing, auth, receipt and two links into one dense block. Some of it (human page URL, contract path) is marginal for an agent and could be trimmed; the sentence 'Standing jobs check and report' is awkward filler.

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 only two params, no output schema and read-only annotations, the description still covers return contents, payment mechanics, auth prerequisites and the signed receipt, which is more than enough for correct invocation. It lacks only pagination/volume limits for the 'recent windows' list.

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 both digest_id and window_index are already documented in the schema. The description only echoes the window_index fallback ('the latest, or window_index') and adds the ownership scope (owned by the calling wallet), which the schema does not express. Baseline 3 is appropriate when the schema carries the weight.

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 names the resource (a digest owned by the calling wallet) and enumerates what the report contains: schedule, closed windows, empty-posted/skipped windows, items waiting, recent delivery outcomes, and one full signed digest report. That is specific enough to distinguish it from wever_digest-create and wever_digest-cancel, though it never explicitly contrasts itself with those siblings.

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 only implied: 'Standing jobs check and report' and the read-only framing tell the agent this is the inspection call for an existing digest. There is no explicit when-to-use versus when-not guidance and no named alternative (e.g. 'use wever_digest-create to make a new digest').

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