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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely new behavior context: no API key required, that the route-quote data is cached and frequently empty, and how fee_on=customer shifts the invoice fee to the payer. It doesn't cover freshness/staleness of the quotes or response shape details, but for a read-only reference endpoint that is a minor gap.

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?

Two tight sentences, front-loaded with what it charges, then split into 'pricing:' and 'data:' buckets with comma-separated field names. Every clause carries information (auth, fee formula, cross-tool pointers, emptiness caveat) and nothing is padded.

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?

There is no output schema, and the description compensates by enumerating the pricing fields an agent will receive (invoice_fee_percent, min/max USD, static address and payout service fees) and by flagging that the cached quote list may be empty. Combined with the cross-references to preview_payout and list_assets, an agent has enough to call it and interpret the result.

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 100% and the schema already explains route and the two asset_id codes, so the baseline is 3. The description only adds that route/asset filter the cached-quote portion; most of its text documents returned fields rather than parameter meaning.

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 concretely that this returns SnapEX Pay's fee schedule (invoice, static address, payout service fees) plus cached route fee quotes, and it explicitly separates static pricing from the dynamically quoted network fee. It names the sibling tools that cover the parts this tool doesn't, so an agent can distinguish it from preview_payout and list_assets immediately.

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 gives real routing guidance: network fees come from preview_payout, per-coin minimums come from list_assets, and the cached quote section is 'often empty'. It stops short of a crisp 'call this first, then preview_payout' ordering or saying when the cached data is worth querying at all, but the alternatives are named explicitly.

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