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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the tool reports (configuration and cache statistics) and its diagnostic purpose, but does not delve into any potential limitations or edge cases. Still, for a read-only diagnostic tool, this is sufficient and adds value beyond the annotations.

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 two sentences that immediately state the tool's primary function and follow with a crisp usage recommendation. No redundant words or filler.

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 the tool's simplicity (no parameters, output schema exists), the description is complete. It explains when to use the tool, what it does, and what it reports. The presence of an output schema means return values need not be described here.

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 tool has zero parameters, so the baseline is 4. The description does not need to elaborate on parameter semantics, and there is nothing further to add.

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 states the tool verifies CoinGecko API reachability and reports server configuration and cache statistics. This is a specific verb-resource pairing that distinguishes it from the sibling coin-data tools.

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 explicitly instructs to use this tool first when other tools fail, and explains it helps differentiate upstream outages from configuration problems. This is strong situational guidance that goes beyond merely describing the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds 'at the current rate' to indicate real-time data, but doesn't cover error behavior or fallback rates. This matches the baseline for annotation-covered read tools.

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?

One sentence plus an example, no fluff. It is front-loaded and every word contributes to understanding the tool.

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 conversion tool with three well-described params and an output schema (not shown but present), the description is nearly complete. The only minor gap is not explicitly contrasting with get_coin_price, but the example indirectly does this.

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% with per-parameter descriptions. The example '2.5 ETH in USD' adds a concrete mapping to amount, coin_id, and vs_currency, slightly enriching the schema baseline of 3.

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 states the tool converts a crypto amount to another currency at the current rate, with a concrete example ('2.5 ETH in USD'). This distinguishes it from siblings like get_coin_price (which probably returns price only) and historical tools.

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 example and wording imply this is for live conversion of a specific amount, which is enough contextual guidance. It doesn't explicitly exclude alternatives but the use case is clear relative to siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by detailing what data the 'full profile' includes (e.g., supply figures, all-time high, 24h/7d/30d price changes), which goes beyond the structured annotations. It does not contradict annotations and enriches the agent's understanding of the tool's behavior.

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, tightly-packed sentence that front-loads the main purpose ('full profile for one coin') and immediately lists the included data. Every element contributes directly to understanding the tool's output. There is no redundancy or filler, making it highly concise and well-structured.

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 the tool's simplicity (2 parameters, both documented), the presence of an output schema, and annotations covering safety, the description provides sufficient context. It clearly sets expectations for the breadth of data returned without needing to explain return formats (handled by output schema). The description is complete 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?

The input schema provides 100% coverage with descriptions for both parameters (coin_id and vs_currency). The description does not add significant new parameter semantics; it mentions market data and price changes, which aligns with vs_currency but is already implied by the schema. Baseline 3 is appropriate since the schema handles the heavy lifting.

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 states the tool's purpose: 'Get a full profile for one coin' and enumerates specific data categories (description, homepage, categories, supply figures, all-time high, and price changes). This distinguishes it from sibling tools like get_coin_price (which only returns price) and get_market_chart (which returns chart data). The verb 'get' plus the resource 'coin' and the detailed scope make the 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 implies usage when a comprehensive profile is needed, but it does not explicitly state when to use this tool versus alternatives. It lacks explicit 'when not to use' guidance or references to siblings such as get_coin_price for simple price queries. The context is clear but implied rather than directly stated.

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

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

Annotations already declare this a read-only, non-destructive operation, and the description adds the batching efficiency hint. However, it does not disclose potential rate limits, response size limits, or error behavior for invalid coin IDs. With annotations covering safety, the description contributes moderate context beyond the structured data.

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 two sentences with no fluff. The first sentence states the core purpose, and the second gives a key usage hint. It is front-loaded and every word earns its place.

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 the output schema exists and annotations provide safety, the description sufficiently covers the tool's purpose and the key batching behavior. For a simple read-only price look-up with all parameters documented, it is complete enough for correct selection and 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 100%, and each parameter already has meaningful descriptions (e.g., comma-separated CoinGecko ids). The description's mention of optional market cap, volume, and change mirrors the boolean parameters but does not add syntax or format details beyond what the schema provides. Baseline of 3 is appropriate.

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 states a specific verb ('Get') and resource ('current prices for one or more coins in one or more currencies'), and lists optional data dimensions (market cap, 24h volume, 24h change). This distinguishes it from sibling tools like get_market_chart (historical) and get_coin_details (static info).

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 provides explicit guidance to batch multiple coins into a single call rather than making one call per coin, which is a clear when-to-use directive. It doesn't explicitly name alternatives or exclusions, but the purpose and batching instruction make the intended usage context clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds valuable context by specifying the exact metrics returned (market cap, volume, BTC/ETH dominance, counts). This goes beyond the basic safety profile, though it does not disclose potential limitations or rate limits. No contradiction with annotations.

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 that is concise, information-dense, and front-loaded with the core purpose. It lists all key outputs without unnecessary verbosity.

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 the tool's low complexity (one optional parameter, output schema provided, annotations present), the description is complete enough. It clearly states what the tool does and the specific data it returns, meeting all needs for agent selection and 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?

The schema fully describes the only parameter (vs_currency) with a clear description and default value, so the description does not need to add parameter details. The baseline of 3 applies given the high schema coverage.

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 states the tool's purpose with a specific verb ('Get') and resource ('aggregate statistics for the whole crypto market'), and enumerates the specific metrics returned. This distinguishes it from sibling tools that focus on individual coins or lists, such as get_coin_details or list_top_coins.

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 usage for market-wide aggregate statistics but does not explicitly state when to use this tool instead of alternatives like list_top_coins or get_coin_price. There are no explicit exclusions or alternative recommendations, so the guidance remains implicit.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses important behavioral traits: the exact time (00:00 UTC), the data fields (price, market cap, volume), and the plan/API key requirement and failure mode. This adds substantial context for the agent, especially the authentication limitation and the exact point-in-time semantics, which are not captured in annotations.

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 exactly two sentences and front-loads the core purpose first, then provides the alternative and caveat. Every sentence earns its place: the first states the primary action, the second gives usage guidance and a warning. There is no wasted wording or redundant repetition of schema information.

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 the presence of a rich output schema (not described here but inferred from structured context) and complete annotations, the description covers all essential operational context. It explains what data is returned, the exact temporal scope, the access restrictions, and the alternative for broader ranges. No significant gaps remain for an agent to invoke this 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?

The input schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds meaningful semantic detail for the 'date' parameter ('00:00 UTC' and 'past calendar date') and clarifies the output fields, which aligns with the schema's parameter meanings. While most parameter documentation comes from the schema, the description enriches the date's temporal interpretation.

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 states the specific action: 'Get a coin's price, market cap, and volume as of 00:00 UTC on a past calendar date.' It distinguishes from the sibling get_market_chart by explicitly noting the difference between a single date and a range of dates. The verb 'get' and the resource (coin's price, market cap, volume) are specific and 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 guidance on when to use this tool ('For a range of dates use get_market_chart instead') and provides a critical prerequisite: 'CoinGecko restricts this endpoint to Demo and Pro plans — without an API key it fails.' It also notes that get_market_chart covers history on the public tier, offering a clear alternative for public-tier users.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds valuable behavioral details: long windows are down-sampled to max_points evenly spaced observations, and change_percent is always computed from the full series. This goes beyond the annotation safety profile, explaining the data processing behavior.

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 two well-structured sentences that are front-loaded with the primary purpose and immediately add important caveats about down-sampling. No redundant information or filler.

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 the moderate complexity (5 parameters) and the presence of an output schema, the description is complete enough. It covers the core behavior, down-sampling, and the change_percent calculation. It does not explicitly mention the paid-plan limitation for some intervals, but that is already in the schema parameter description, so no major gap exists.

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 meaning by clarifying the interplay between 'days' and 'max_points' via the down-sampling note, and explains that change_percent is computed from the full series, which affects understanding of the output. This is extra value beyond the schema definitions.

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 names the exact resource: 'historical price, market cap, and volume series for a coin over a look-back window.' This clearly distinguishes the tool from siblings like get_historical_price or get_ohlc_candles by emphasizing the multi-series market chart output.

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 the intended use case: obtaining historical market chart data for a coin. It does not explicitly mention alternatives or exclusions, but the phrase 'market chart' and the mention of down-sampling provide clear context for when this tool is appropriate.

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

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

The description adds meaningful behavioral context beyond the annotations (readOnlyHint=true, destructiveHint=false) by explaining CoinGecko's candle width selection logic and noting that the chosen width is reported in the result. This is valuable non-obvious behavior that helps the agent interpret the response.

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 two sentences, front-loaded with the core purpose, followed by the necessary candle width behavior. There is no wasted text 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?

Given the tool's complexity (three parameters, one required) and the presence of annotations and an output schema, the description is sufficiently complete. It covers the core purpose and the critical candle width nuance, while the schema handles parameter details and the output schema handles return format.

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% for all three parameters, so the description does not need to elaborate on parameter semantics. The tool description adds context about how 'days' relates to candle width, but this is behavioral rather than parameter-specific meaning. Baseline 3 is appropriate.

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 states 'Get open/high/low/close candles for a coin', using a specific verb and resource. It distinguishes itself from sibling tools like get_coin_price (single price) and get_market_chart (market chart data) by focusing specifically on OHLC candlestick data.

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 usage for obtaining OHLC candlestick data, but does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative tools, so the usage guidance is only implied rather than explicit.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description adds the meaningful context that the list reflects attention over the last 24 hours, not price performance. This clarifies the tool's semantic behavior beyond the safety annotations.

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 two short sentences with no redundancy. Every word earns its place, succinctly conveying the list scope and the metric it reflects.

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 zero-parameter, read-only tool with an output schema, the description is complete enough. It specifies the time window (24 hours) and clarifies the data's meaning, leaving no ambiguity about what the agent will receive.

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 tool has zero parameters, and the schema is fully covered by the empty properties definition. Per the baseline rule, a zero-parameter tool receives a baseline of 4 since no parameter clarification is needed.

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 states the tool lists the most searched coins on CoinGecko in the last 24 hours, using a specific verb ('List') with a clear resource and time frame. It also differentiates the tool from siblings by emphasizing attention rather than price performance, making its purpose distinct.

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 implicitly provides usage context by noting it reflects attention, not price performance, which signals when this tool is appropriate compared to price-focused siblings. It does not explicitly name alternatives, but the boundary is clear enough for an agent to decide.

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

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

Annotations already declare this as a safe read-only operation, so the description's main contribution is specifying that the list is exhaustive ('every currency code') and includes both fiat and crypto categories. This adds behavioral context beyond the annotations without contradicting them.

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?

A single sentence that front-loads the action and includes concrete examples for currency types. Every word contributes necessary information; no filler. It is appropriately sized for the tool's simplicity.

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 zero-parameter list tool with a full output schema and safety annotations, the description covers the essential purpose and scope. It doesn't need to explain return values because the output schema exists. It is fully self-contained for an agent to decide when to call it.

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?

There are zero parameters, and the schema has 100% coverage of that (an empty object). The description doesn't need to explain parameter semantics, and it doesn't provide any misleading information. Baseline for zero params is 4.

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 states a specific action ('List every currency code') and scope ('accepted as a vs_currency by the other tools'), clearly distinguishing it from price or coin-list tools. Examples of fiat and crypto add concrete meaning. It fully addresses what the tool does.

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 phrase 'accepted as a vs_currency by the other tools' provides clear context that this is the reference list for currency validation in sibling tools. While it doesn't explicitly name alternatives or say 'use this before other tools', the intent is unambiguous given no sibling tool covers this function.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that each coin includes price and 24-hour change, which is a mild behavioral detail, but it doesn't disclose potential caveats like rate limits or pagination behavior. Since annotations carry the safety profile, this is adequate but not rich.

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?

Two sentences, front-loaded with the action and purpose, no fluff. Every sentence contributes meaning, making it highly concise and well-structured.

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 the moderate complexity (4 optional params), rich annotations, and an output schema, the description is sufficiently complete. It conveys the core function and use case without needing to repeat return details that the output schema already covers. The only minor gap is not explicitly distinguishing from similar list tools, but the context is adequate.

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%, so the parameters are fully described in the schema. The description reinforces that ranking can be by market cap, volume, or id, which aligns with the order parameter but doesn't add new meaning beyond the schema's own description. Baseline 3 is appropriate.

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 states the tool lists coins ranked by market cap, volume, or id, with price and 24-hour change. It differentiates from siblings by framing it for market overviews and 'top N' questions, which is distinct from get_trending_coins or get_global_market_overview.

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: 'Use this for market overviews and top N questions.' It doesn't name alternatives or state when not to use it, but this clear context implies appropriate scenarios without needing exclusions.

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

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

Annotations already indicate read-only, non-destructive behavior. The description adds useful behavioral context: it returns CoinGecko ids and clarifies that other tools expect slug format, which is important for correct downstream use. No contradictions with annotations.

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?

Two sentences, each earning its place. The first states the action and output; the second provides essential usage guidance about when to call and the slug/symbol distinction. No filler.

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 a rich schema, output schema present, and helpful annotations, the description fills the remaining need: explaining the tool's role in the broader workflow (id lookup). It is complete for a simple search 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 coverage is 100% with clear descriptions for both 'query' (name or ticker, with examples) and 'limit' (max matches, range). The description itself doesn't add parameter detail, but the schema already does the heavy lifting, so baseline 3 is appropriate.

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?

Description uses a specific verb ('Find'), names the resource (coins), and states the output (CoinGecko ids). It sets this tool apart from siblings by explaining its role as an id-lookup helper, noting that every other tool expects the slug rather than the symbol.

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?

Provides an explicit trigger: 'Call this whenever you are unsure of a coin id'. Clearly distinguishes from other tools by referencing the slug-vs-symbol convention, but does not explicitly state when not to use it or name an alternative tool for the same purpose.

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