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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: read from the index, a 15-second per-token read throttle, a cost of 1 unit, and a refusal error when the address is not a known token.

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?

Front-loads the purpose and ordering rule, then packs return fields, behavior, cost and errors into compact labeled clauses. Every sentence carries distinct information; nothing is redundant with the name or title.

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 enumerates the returned fields (token, pools[] with pool/pair/quote/swapFeePct/etc., pairsThatExist), so the agent knows exactly what it gets back. It also covers the rate limit, unit cost and the error case, which is complete for a one-parameter read tool.

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 fully documents the single parameter (address with a 0x40-hex pattern at 100% coverage), so the schema carries the semantics. The description does not add format or syntax detail beyond what the schema already provides, making the baseline 3 appropriate.

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 (Lists) and resource (the pools of one token a paper position can go in) plus the ordering semantics (in the order the site offers them). It also explicitly equates the result to the sibling ladder_pools, letting the agent distinguish the two without opening either schema.

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?

Gives an explicit sequencing rule: 'Use before arena_open to choose a pool; the first is the default.' That tells the agent both when to call it and how to interpret the returned order, and it ties the tool to the sibling that consumes its output.

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