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

Even with no annotations, the description fully discloses key behavioral traits: the ticket is consumed at settle, never authorizes a second purchase, and only applies to the next matching payment. It also specifies the signature type (EIP-191 from the owner) and that it carries no keys and signs nothing.

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 description is well-structured and front-loaded with the primary purpose. It uses clear labels like 'Goal:' and 'Success means:' to organize information. Every sentence carries essential value without unnecessary fluff.

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 the tool's complexity (a single signed confirmation with multiple internal fields and single-use semantics), the description covers all essential aspects: the data structure, the signing requirements, the settlement behavior, and the one-time use guarantee. An output schema exists, so return values need not be explained.

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?

The input schema is minimal (an open object with no defined structure), but the description compensates completely by detailing the required structure: signed_confirm with fields type, agent, amountUsdc, resource, expires, nonce, and signature. This provides far more semantic meaning than the schema alone.

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 clearly states the specific verb ('Publish'), resource ('owner's confirmation'), and scope ('one over-threshold purchase'). It further clarifies the exact goal of authorizing exactly one purchase, which distinguishes it from broader authorization tools like publish_spend_authority_grant.

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 provides clear context for when to use the tool: when an owner needs to confirm a single purchase above the agent's no-confirm threshold. However, it does not explicitly mention alternatives or exclusion cases, such as when to prefer publish_spend_authority_grant instead.

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