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

The annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description still adds meaningful context the annotations cannot convey: the computation is pure and offline via blocktools, nothing is fetched or stored, and the data provenance is a public explorer check with a date plus a library version. It stops short of describing response size or ordering, but for a static lookup that is a minor omission.

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 with the returned fields, then the parameter behavior, then the no-side-effects guarantee — a sensible order with little waste. The trailing sentence promoting swapchan_playbook workflow names is somewhat tangential and inflates length, but it is at least actionable.

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 does the work of enumerating the return fields, and it covers the offline/pure computation behavior and parameter defaults. What remains thin is the overlap with sibling tools like get_supported_chains and chain_params — an agent could still pick the wrong one, though the tool's own contract is adequately described.

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 description coverage is 0%, so the description must carry the burden. It does: it explains that 'chain' accepts a name or ticker and that omitting it returns all chains, which fully specifies the single optional parameter's behavior. It omits the 16-character max length and doesn't address ambiguous name/ticker collisions, but the semantic meaning is otherwise clear.

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 resource (chains known to the address tools) and enumerates the metadata returned: name, ticker, title, SLIP-44, verified flag, explorer with date, and library version. That is concrete and distinguishable in content, but it never acknowledges or contrasts with the nearby siblings get_supported_chains, chain_params, or get_supported_tokens, so an agent has no explicit cue for choosing between them.

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 clear parameter-level usage ('chain=<name or ticker> for one, omit for all') and points to swapchan_playbook for workflows, which is real guidance. However, it never says when this tool should be preferred over get_supported_chains or chain_params, and there is no when-not-to-use condition, so the routing guidance is only partial.

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