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

Goes well beyond the annotations (destructive=true, non-idempotent, openWorld) by disclosing pricing (2.00 USDC per mandate, 10 free signed-wallet calls over a rolling 30 days, only issue_mandate billed), the money-back-launch waiver, per-mode credentials (X-Wever-Operator-Key vs X-Wever-Agent-Key, Idempotency-Key), single-use grant semantics with a 300s ceiling, and that revocation preserves committed records. Consistent with the annotations: writes and grant consumption are durably recorded, which matches destructive/non-idempotent.

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?

Key facts (price, then purpose) are front-loaded and no sentence is purely filler, but the text restates the same pricing and credential facts three or four times ('Only issue_mandate is billed', 'Mandate issuance costs 2 USDC', 'Issuance costs 2.00 USDC per issued mandate'), and repeats the 'no execution/delivery/payment' disclaimer in two places. At roughly 350 words for a one-parameter tool, tightening would materially help.

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?

Given a single mode parameter with a large nested oneOf schema and no output schema, the description covers the pieces an agent must know before calling: cost, credentials per stage, idempotency keys, grant TTL, immutability, and the AP2 special case. Return shapes are delegated to the per-mode schema branch descriptions, which is acceptable, though a one-line note on what inspect modes return would close the loop.

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?

There is a single `mode` parameter with 9 enum values and no top-level property description, so the schema coverage is effectively 0% at that level, though each oneOf branch carries its own per-mode description. The prose describes the lifecycle stages and their credential requirements but never enumerates or maps to the mode names (read_control_plane, draft_mandate, inspect_mandate, read_audit, ...). It compensates partially, leaving the caller to reconcile flow stages against enum values.

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+resource pair: 'Issue signed mandates and approve an exact action... create an immutable work-order record,' and explicitly delineates what it does not do ('does not execute the recorded work, deliver results, or authorize payment'). That boundary implicitly separates it from the wever_workorder-* and payout siblings, but no sibling is ever named, so differentiation is by description of scope rather than by routing.

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 lays out the actual call sequence (operator issues mandate -> approves grant <=300s -> agent consumes once -> inspect until final), which tells an agent the order of operations. It also redirects execution/delivery/payment to 'their own service.' It never names an alternative tool or an explicit case in which a caller should prefer a different Wever tool.

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