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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds meaningful behavioral detail: no API key needed, ~5min caching, ascending time order, prices in QUOTE currency, and a described error path for unknown symbols. These go well beyond the annotation hints and make the tool's behavior predictable.

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 longer than the bare minimum but well-structured with Args, Returns, Examples, and Errors sections, and every section adds practical value. Some repetition of defaults from the schema exists, but the examples and error guidance justify the length.

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?

The description is complete for a read-only data-fetching tool: it documents all six parameters, output shape, ordering, currency, caching, and error handling. Even with an output schema present, the explicit return structure and natural-language examples leave little room for an agent to misinvoke the 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?

Schema description coverage is 100%, so the baseline is 3. The description adds extra value through natural-language examples that map user intents to parameter values, explains the 'since' semantics as 'exchange returns candles from this date forward,' and clarifies response_format behavior. This is above baseline but the schema already documents most parameter meanings.

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 opens with a specific verb and resource: 'Fetch OHLCV candlestick data (open/high/low/close/volume) for a crypto pair.' It clearly distinguishes itself from the sibling get_crypto_ticker by explicitly saying it should not be used for a single current price. This makes the tool's purpose unambiguous.

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 gives explicit usage context through concrete natural-language-to-parameter examples and an explicit exclusion: 'Don't use for a single current price — use get_crypto_ticker.' It also notes exchange-specific behavior and common error cases, so an agent knows when and how to invoke it.

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