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

Annotations already cover readOnly/idempotent/openWorld=false, but the description adds substantive behavior beyond them: no network call, no payment link required, native coins are exact-out with a price that only holds until quoteExpiresAt, a $3500 per-invoice cap and $1 minimum for native ETH on Ethereum. It also discloses the ZEC non-support and redirect, which prevents a whole class of wrong calls.

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 core answer is front-loaded in the first clause, which is good. However, a large middle block on native exact-out pricing, FX spread, quoteExpiresAt and per-invoice caps describes ordering behavior that belongs to create_deposit_order/quote_invoice rather than a static coin list, which bloats an otherwise simple lookup tool.

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?

With no parameters and no output schema, the description correctly supplies the coverage and acceptance rules an agent needs before calling. The return value is only summarized in one line ('chain id, token symbol and token decimals'), leaving the actual response shape underspecified, but the usage and limitation coverage are otherwise strong.

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?

Zero parameters, so the baseline is 4; nothing in the schema can be contradicted or clarified. The description goes slightly beyond by naming what comes back (chain id, token symbol, token decimals), though it does not describe the response's shape or ordering since no output schema exists.

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 states a specific verb and resource — answering which cryptocurrencies and chains can pay an OpenRouter credit top-up or Coinbase payment link through Rozo Checkout — and enumerates the concrete chains/tokens covered. It is immediately distinguishable from siblings like quote_invoice (invoice-specific acceptance) and create_deposit_order (order creation).

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?

It explicitly says this is a static list that 'needs no payment link and makes no network call,' and names the alternative: 'quote_invoice reports which of these a specific invoice accepts.' It also gives a when-not: ZEC is not available here and callers should be sent to an external URL. That is explicit routing plus an exclusion.

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