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

With readOnlyHint and openWorldHint already declared, the description adds genuine value by naming fields it does NOT return (pool depth, slippage) and disclosing the data source ('coingecko'). It goes beyond the annotations without contradicting them, though it doesn't discuss rate limits or freshiness/latency of the market data.

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, then uses labeled sections ('Note', 'Use when', 'Not for', 'Returns', 'Example response') that are scannable and each earn their place. Slightly verbose for a 2-param read tool, but nothing is wasted or redundant.

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?

No output schema exists, yet the description enumerates the return fields and provides a concrete example response including the source field, fully compensating for the missing output schema. An agent has everything needed to call and interpret results.

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 100%, so both token_a and token_b are already documented in the schema; the description only implies the pair semantics. Baseline 3 applies since the schema carries the parameter burden.

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 ('Get market cap, 24h volume, ATH, and price change for any token') and explicitly distinguishes itself from siblings token_price and orderbook_depth. An agent can identify the tool's scope without consulting the 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?

Uses explicit 'Use when' and 'Not for' sections that name the alternatives (token_price for spot price, orderbook_depth for pool depth/slippage) along with the conditions selecting each. Routing guidance is complete and actionable.

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