list_payable_assets

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the dynamic nature of the list ('price-confidence gated') and guarantees certain entries ('ALGO and USDC always included'). It also prevents false expectations by clarifying that metadata is not part of this response. It does not explicitly state read-only behavior, but the verb 'list' implicitly conveys this.

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 two sentences, about 35 words, and immediately front-loads the core purpose. The second sentence adds valuable cross-reference for metadata without redundancy. Every word earns its place; no filler.

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 simple no-argument list tool, this description is complete: it states what the list includes, the gating behavior, the guaranteed entries, and where to retrieve metadata if needed. There is no output schema, but the description compensates by clarifying the nature of the response. The agent can confidently select and invoke this tool with no ambiguity.

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 tool has zero parameters, so the input schema is vacuous. Per the rubric, 0 params receives a baseline score of 4. The description adds context about what the returned list represents, but no parameter-specific guidance is needed. It appropriately references where to find metadata, which helps the agent understand the tool's output semantics.

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 defines the resource and scope: 'Assets accepted as payment inputs for pay_x402_invoice and credit top-ups.' This uses a specific verb (implicitly 'list') and distinguishes it from siblings such as get_balance or get_quote. The qualifiers 'price-confidence gated' and 'ALGO and USDC always included' further specify the exact set.

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 when to use the tool: to discover which assets are accepted for specific payment flows. It also provides a clear pointer for when not to use it: 'Asset metadata is on get_quote responses or GET /assets.' However, it does not explicitly name alternative tools for the same listing purpose or state 'use this when...' explicitly, so it falls short of a perfect 5.

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