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

Annotations already declare destructive=true, openWorld=true, idempotent=false, readOnly=false, so the bar is lower — yet the description adds genuinely new context: per-call pricing on Base, 10 free signed-wallet calls per rolling 30 days, wallet authentication, requirement for existing credentials/mandates, and the explicit disclaimer that the adapter grants no authority and never supplies server credentials. What it does not disclose is the destructive footprint itself (what a revoke destroys, whether grants are recoverable) or the return shape of an evaluate decision.

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?

Pricing and operating boundary are front-loaded, which is the right ordering, and no sentence is pure filler. But the prose is dense and partly redundant ('This adapter grants no authority and never supplies server credentials' restates the operating boundary), and the pointer to /api/operations-contract pushes essential schema knowledge out of the definition.

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?

This is a destructive, wallet-authenticated, paid, multi-mode mutation tool with 13 parameters, zero schema descriptions, and no output schema — the highest-burden combination. The description covers billing and credentials well but leaves mode dispatch, idempotency semantics, expiration behavior, pagination, and what evaluate returns entirely unexplained, so an agent cannot safely call it from the definition alone.

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 description coverage is 0% across 13 parameters and a four-branch oneOf, so the description must carry the load and largely does not. It gestures at subject/action/resource and the grant/revoke distinction, but never explains mode selection, idempotency_key, the synthetic/operational usage enum, expires_at, grant_id, reason, or the offset/limit pagination bounds — all of which are non-obvious and undocumented elsewhere.

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 opening sentence gives a specific verb-and-resource pair: persist wallet-scoped permission grants/revocations and evaluate a subject/action/resource triple against them. That is far more precise than the title alone. It does not, however, distinguish this from adjacent authority tools among the siblings (wever_delegated-authority, wever_payment-authority-inspector, wever_agent-allowance-console), so an agent cannot tell which of those to pick from the description.

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 'Operating boundary' paragraph implies usage — record a grant/revocation, then query the records to make an access decision — which is real guidance about the intended workflow. But there are no explicit when-not conditions and no named alternatives, and the 'list' mode is never described at all, so the agent must infer it from the schema's mode enum.

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