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

The description goes well beyond the readOnlyHint/destructiveHint annotations by explaining the v4 backend behavior, the meaning of 'chainsNotCovered', and the semantic difference between a chain not being reachable versus a chain with zero swappable tokens. This gives the agent crucial interpretation guidance that annotations alone cannot provide.

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 dense and informative but not bloated; every sentence adds meaningful context. The opening sentence is slightly indirect because it starts with version/backend context rather than a direct statement of the tool's purpose, but the overall structure is efficient and front-loaded with important behavioral details.

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 output schema, the description carries the full burden of explaining return semantics, and it does so thoroughly: counts vs token lists, chainsNotCovered, zero-token chains, and the get_markets alternative. For a single-optional-parameter read-only tool, nothing essential is missing.

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 schema already fully describes the single optional chainIds parameter with 100% coverage. The description adds extra value by noting that chainIds can also be used to ask about chains not reached by the initial sweep, and clarifies that omission returns counts rather than token lists.

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 states the tool gets swappable chains and tokens, and explains it returns either a chain sweep with token counts or an actual token list for given chain ids. It differentiates itself from get_swap_quote and get_markets by explicitly positioning this as the pre-quote discovery tool.

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 explicitly says to call this before get_swap_quote, and specifies when to omit chainIds versus when to pass them. It also tells the agent that get_markets returns 'canSwapFrom' per reserve as an alternative source of the same information.

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