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

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description adds useful context beyond them: per-call pricing, free daily quota, log-return methodology, and the exact computed stats. It does not need to restate safety traits, and it provides meaningful operational detail.

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 compact and front-loaded, but the second sentence partially repeats the statistics already listed in the first sentence. It still earns its place by adding 'with dates' and 'from log returns,' so the redundancy is minor and the overall structure remains efficient.

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?

Given that this is a read-only data tool with no output schema, the description adequately covers what the agent will receive: the price series and the specific stats. It also includes cost and free-tier information. Exact output field names and chain resolution details are not fully specified, but the schema and the reference to crypto_price cover enough for correct invocation.

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 high at 75%, so the baseline is 3 even without much parameter detail. The description adds useful semantics about asset resolution and the hour/day interval, but the phrase 'hourly or daily, up to 365 days' is ambiguous because the schema restricts hourly data to 30 days. This prevents the description from adding fully reliable parameter guidance.

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 clearly identifies the resource (historical USD prices for any crypto asset), the output (price series plus statistical metrics), and the available granularity/horizon. It also distinguishes itself from the sibling crypto_price tool by noting the same asset resolution while focusing on history and volatility.

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 implies this tool is for historical price data and derived volatility statistics, but it never explicitly says when to prefer it over alternatives such as crypto_price or price. The reference to 'same asset resolution as crypto_price' hints at a related tool but does not provide concrete when-to-use/when-not-to-use guidance.

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