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

Beyond the readOnly/openWorld/idempotent annotations, the description adds critical behavior: the list changes without notice, must never be cached or answered from memory, Polygon is the only fast default, no rate is included, and `acao` error codes map to concrete actions. No contradiction with annotations.

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 front-loaded and every section has a purpose, but it is dense: the freshness warnings overlap ('never hard-code it, never cache it... never answer from memory'), and the error-code section is terse. It is not bloated, but tightening those parts would improve it.

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, open-world list call with one optional parameter, the description covers authentication, freshness constraints, expected timing, the pricing exclusion, and error handling. No output schema is present, but the return content is adequately described as assets and networks with limits and timing.

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 already covers the single optional `network` parameter at 100%. The description enriches it by identifying Polygon (USDT/USDC) as the default and connecting network choice to settlement timing, which gives agents useful meaning beyond the schema's bare filter example.

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: 'Lists the assets and networks that can settle right now, with limits and expected timing.' It also clearly separates itself from pricing tools with 'Do not use it to price anything', which makes its role distinct among the siblings.

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?

'Call it before quoting whenever the user names an asset or a network you have not already confirmed in this session' is an explicit, actionable trigger. It also gives a clear exclusion ('Do not use it to price anything'), but it does not name the alternative tool for pricing, so it stops just short of a full 5.

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