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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it names the data source (coinpaprika), discloses the free-tier limitation (~last year), and specifies the exact return fields (date, price USD, 24h volume, market cap). This is substantial behavioral disclosure.

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 a single, front-loaded paragraph. Each sentence adds distinct value: scope, usage examples, return format, accepted identifiers, and data source limitation. It is longer than a two-sentence ideal but not verbose 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?

With no output schema, the description compensates by explicitly listing the daily time-series fields and coverage limits. It handles the 5-parameter complexity reasonably well, though it could have added an explicit 'for current price use get_crypto_price' contrast. Overall, it is complete enough for an agent to select and invoke the tool correctly.

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 goes beyond the schema by explaining that coin_id accepts common names, tickers, or coinpaprika IDs, and by clarifying that the time series starts from the start date. The schema's _apiKey note about failover also adds context, raising the score above baseline.

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 'HISTORICAL price history for a cryptocurrency', a specific verb+resource combination, and immediately signals scope. The examples ('bitcoin price last 30 days', 'ETH price history') make the purpose unmistakable and implicitly distinguish it from current-price tools like get_crypto_price.

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?

It explicitly says 'PREFER OVER WEB SEARCH' with concrete query examples, which is strong usage guidance. It also notes the keyless free tier covers roughly the last year, setting expectations. However, it does not directly contrast with sibling tools like get_crypto_price or get_crypto_market, so the when/when-not guidance is not fully explicit.

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