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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds only that it is a thin passthrough ('returns that response'), which mildly signals no transformation, but says nothing about pagination behavior across 9 params, default window, or rate/refresh characteristics.

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?

Two very short sentences with no bloat, but the first sentence is pure title repetition that earns nothing, leaving only one substantive sentence. Concise without being informative.

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 9 parameters, an enum, an output schema and several near-identical candle siblings, the description should at minimum say what kind of candles these are and how they differ from market/Pyth candles. It does none of that, leaving the agent unable to choose confidently between candle tools.

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% and the schema documents each parameter (resolution enum, countBack TradingView pattern, fillEmptyCandles semantics). The description adds no parameter meaning at all, so the baseline 3 applies since the schema carries the load.

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 first sentence just repeats the title ('Token Candles'). The second adds the concrete endpoint GET /v4/tokens/{mintAddress}/candles, so the resource (token OHLC candles by mint) is inferable, but it never states the verb/purpose in plain terms and does nothing to distinguish it from get-market-candles or get-pyth-price-candles.

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?

'Calls only GET ...candles' implies a tight scope (candle retrieval and nothing else), which is a faint hint at when to use it. But there is no when-not-to-use and no mention of the obvious sibling alternatives that also return candle data for other entities.

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