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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds the critical caveat that 'ALLOW is policy only, never wallet authority' and that it returns a signed portable allowance artifact. This is meaningful behavioral context an agent cannot derive from annotations. It does not, however, describe deny/block behavior or what the artifact is consumed by.

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?

Three tight, front-loaded sentences with no filler; the caveat sentence is deliberately punchy. Minor deduction for unexplained jargon ('OCD', 'signed portable allowance artifact') that costs the reader without adding immediate clarity.

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 tool with a deeply nested policy schema, no schema descriptions, and no output schema, the description omits almost all policy semantics and the meaning of the returned artifact. It nails the purpose and timing but leaves too much of the invocation contract unstated.

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% with three nested-object parameters (action, policy, options) containing many subfields and enums. The description only loosely maps 'approve or revoke' to the intent enum and 'Base USDC' to token/network, leaving policy fields (allowed_tokens, unlimited_allowance, max_allowance_atomic, revoke_only, acknowledge_unconstrained) and options entirely undocumented.

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 (preflight/evaluate) and resource (Base USDC ERC-20 allowance approve/revoke action), and pins the timing 'BEFORE an agent asks its wallet to approve or revoke'. It is clearly distinguishable from siblings like inspect_allowance (read state) and preflight_payment (different resource).

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 'Call BEFORE an agent asks its wallet to approve or revoke' gives an explicit trigger condition, effectively telling the agent when this tool belongs in the flow rather than inspect/observe. It stops short of naming an alternative for reading current allowance state or stating when-not to call.

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