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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, and the description is consistent with them while adding real detail: no network request, fetch, money movement, message, sharing or config change. It also discloses cost and auth (0.10 USDC on Base via x402, 10 signed-wallet free calls per rolling 30 days, X-Wever-Wallet-Proof bound to the exact JSON arguments and route) and that a signed Ed25519 receipt is returned. The only minor omission is any mention of idempotentHint=false implications, i.e. whether resubmitting the same limit set yields a different 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 lead sentence establishes scope well, but the middle sentence is an extremely long run-on that re-enumerates the same observation axes as a list of report findings, largely restating the parameter semantics. The pricing/auth/contract URL tail is efficient, but overall the prose is denser and more repetitive than needed for a two-parameter tool.

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 carries the return-value burden and does: a report with an Ed25519 signed receipt, the four possible verdicts, and links to the contract and human page. For a stateless, read-only check with fully documented params, nothing an agent needs to call it correctly 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%, so the baseline is 3, but the description earns above baseline by unpacking the enum meanings in prose: what the agent can read (limit plus headroom, limit only, nothing) and when (before acting, only on refusal, after acting), what the owner sees and when (before money moves, after settlement, periodic report, on breach), and the headroom source options (live count, cached copy, estimate). That supplies semantics for enums like agent_sees_when that the schema leaves undescribed.

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 ("submit a limit set") and a precise question it answers: whether limits are seen before they are hit. It further names the two nearest siblings (wever_budget-controls-check for spend records readable by a person, wever_limit-substrate-check for where a limit is enforced), so an agent can separate the three without opening schemas.

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?

Explicit exclusions are given with the condition that selects the alternative: budget record readability goes to wever_budget-controls-check, enforcement location goes to wever_limit-substrate-check. The verdict set (limits_learned_by_hitting, visibility_gaps, visibility_unverified, visible_before_acting) also tells the caller what outcome space to expect before invoking.

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