List supported chains

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavioral context — TORPC tier-2 compression behavior, which chains pass through unchanged, and that suiChains are shaped in-server with _meta.tier/tier_source indicating what was applied and by whom. That is genuine value beyond the annotations, though much of it covers sibling tools rather than listChains' own output.

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 opening sentence is well front-loaded, but the body drifts into extended detail about raw-RPC reach, suiChains, and TORPC compression tiers that belongs more to those sibling tools than to a chain-listing call. It is informative but overlong relative to the simplicity of a no-argument discovery 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 input/output schema, the description must carry the meaning of the return values, and it does so by defining exactly which chains appear and how they relate to the rest of the server. An agent has enough to decide whether to call it and how to interpret the list, even if the tier/compression detail is more than the tool strictly needs.

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 takes zero parameters, so there are no argument semantics to document; the baseline for a 0-param tool is 4. Nothing in the description contradicts or omits parameter information.

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?

States a specific verb+resource: returns the chains where the Ankr Advanced API indexer is available (token balances, NFTs, holders, transfers, prices). This scope is concrete and lets an agent distinguish it from searchChain and the raw-RPC siblings. The core purpose is slightly buried under later caveats, but it is clearly stated.

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 clarifies what the list governs (indexer/Advanced-API support) versus what it does not (getTransaction, getLogs, getBlock, rpcCall reach 200+ chains regardless), which routes the agent correctly. It gives clear context for when to consult this list, though it stops short of an explicit 'use this when you need to know whether a chain supports getTokenHolders' style instruction.

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