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

Annotations give only broad non-read-only, non-destructive hints, so the description carries most of the behavioral burden. It adds useful context: the receipt is signed with HMAC-SHA256, stamping costs $0.05, there is no inbox step, and merchants verify via meter_verify_stamp. It does not disclose whether a chain write occurs, whether fees are deducted from the wallet, or whether the receipt is reversible.

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?

At roughly 55 words it is short, but it is a jumble of sentence fragments and pricing phrases rather than a structured explanation. The useful information (signed receipt, verification sibling) is buried behind 'Buy looks_20 pack...' and 'No inbox.' The title front-loads the purpose, but the description does not.

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?

For a financial tool with 7 optional-looking parameters, no output schema, and low schema coverage, the description omits essential calling details: required relationships among parameters, what the signed receipt contains, and what triggers a fee or transaction. It names the verification sibling, but an agent would not be able to construct a correct call solely from this text.

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 only 14%—only decision has a description—so the description needed to explain to, chain, wallet, cap_usd, value_usd, and pass_token. It does not: the text mentions an address, USDC, and allow/stop, but the mapping to parameters is speculative. It especially fails to clarify the optionality rule stated in the schema: decision is optional if value_usd and cap_usd are set.

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 title and phrases like 'Signed allow|stop receipt' and 'Stamp ticket' indicate the tool issues a signed allow/stop receipt. However, the description is dominated by opaque pricing language ('Buy looks_20 pack ($0.20)', 'Stamp ticket $0.05', 'stamp_tx $0.05') and never states cleanly what the tool does. It names meter_verify_stamp as a downstream verifier, which provides some sibling differentiation, but the core purpose remains hard to extract.

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 description implies a workflow: stamp a receipt before merchants accept agent USDC, then verify with meter_verify_stamp. It does not explicitly state when an agent should call meter_stamp rather than alternatives such as meter_buy_pass, meter_preflight, or check_transfer. No exclusions or when-not conditions are provided.

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