get_price

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the tool performs a live lookup via CoinGecko and returns several market data fields, which is useful. However, it does not mention rate limits, failure behavior, or response formatting, though those are less critical for a simple read-only price lookup.

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 sentence, front-loaded with the primary action and scope. Every phrase adds relevant information: the live price, fiat support, additional market fields, and the CoinGecko data source. There is no filler or redundancy.

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?

For a simple two-parameter tool with a well-covered schema, the description provides enough context: what data is returned, which currencies are supported, and what external source is used. It does not explain ambiguous coin symbols or output shape, but these are minor given the tool's simplicity and the schema's clarity.

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?

The input schema already documents both parameters clearly with examples: coin accepts ids or symbols like btc/bitcoin, and vs_currency accepts fiat codes with a default of usd. Schema description coverage is 100%, so the description adds little beyond the general claim of 'any fiat' and does not meaningfully extend the schema's parameter explanations.

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 uses a specific verb ('Get') and resource ('live price of any cryptocurrency in any fiat') and lists additional returned data such as market cap, volume, rank, and ATH/ATL. It is clear and self-contained, though it does not explicitly differentiate itself from siblings like historical_price or convert beyond the word 'live'.

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 a current-price use case through 'live price' but never explicitly states when to use this tool versus siblings such as historical_price, convert, or compare_coins. There is no clear when-not guidance or alternative routing, so the agent must infer usage context from the tool name and sibling list.

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