Get crypto price

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

Annotations only say readOnlyHint, openWorldHint, destructiveHint. The description adds critical behavioral context beyond these: it accepts both tickers and ids, reports unknown names back rather than failing the whole call, and clarifies prices are 'near-real-time but not exchange-official.' It also names the data source (CoinGecko), giving the user a full picture of behavior and limitations.

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 four sentences long, front-loaded with the primary purpose, and every sentence earns its place: purpose, usage alternative, input format/behavior, and boundary/alternatives. There is no fluff or redundancy. It is dense with useful information while remaining readable.

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?

Even though there is no output schema, the description lists the return fields (spot price, 24h change, market cap, 24h volume), covers input formats, error behavior, data source and freshness, and defines boundaries with alternative tools. It fully equips the agent to select and invoke the tool correctly, making the lack of an output schema non-problematic.

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 coverage is 100%, but the description still adds significant meaning beyond the schema. It explains the `coins` parameter accepts common tickers or CoinGecko ids, and clarifies how unknown names are handled ('unknown names are reported back rather than failing the whole call'). This goes beyond the schema's `e.g. ["btc", "eth", "solana"]` example, providing real-world usage semantics.

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: 'Spot price, 24h change, market cap, and 24h volume for specific cryptocurrencies you name, from CoinGecko.' This clearly states what the tool does and distinguishes it from get_crypto_market, naming the sibling tool and the difference in use case. The purpose is unmistakable.

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?

Usage guidance is explicit: 'Use this when you know which coins you want; use get_crypto_market instead to rank the market or discover the largest coins.' It also states exclusions: 'Stocks and FX are not available here — use get_stock_quote and get_fx_rate.' This gives clear when-to-use and when-not-to-use guidance with named alternatives.

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