CoinPaprika

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful context that this is an introspection/metadata endpoint and not a data-fetching tool, but it does not reveal additional behavioral traits beyond what the annotations already convey.

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?

Three sentences, each earning its place: the first states what the tool returns, the second gives explicit usage triggers, and the third prevents confusion with data tools. It is front-loaded with the most important information and contains 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?

For a single-parameter read-only introspection tool with a rich output schema and strong annotations, the description covers purpose, usage timing, and disambiguation. Nothing needed to invoke the tool correctly is missing.

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 for the only parameter, 'rationale', with a detailed explanation, length constraints, examples, and privacy guidance. The tool description does not need to add parameter-level detail since the schema already carries the full burden.

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: the server's capabilities, supported workflow patterns, validation rules, and recommended tool sequences. It also explicitly disambiguates from the sibling data tools by stating 'This describes the MCP server itself, not crypto 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 gives concrete trigger conditions: use FIRST to onboard as an agent, or when asked 'what can this server do', 'how should I chain these tools', 'what are the parameter rules'. It also provides a clear exclusion ('not crypto data'), routing agents away from using it for data retrieval.

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 readOnly and idempotent hints, and the description reinforces this with 'Read-only'. It adds valuable context beyond annotations: pagination behavior for page/limit, the requirement for a Starter+ CoinPaprika key, and the plan-required error response without a key.

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?

Three purposeful sentences: what the tool returns, when to use it, and the operational details (read-only, pagination, auth). No filler or redundant repetition of the schema.

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 paginated read-only listing tool, the description covers purpose, usage triggers, pagination, auth requirements, and error behavior. The output schema exists, and the rationale parameter is fully documented in the input schema, so nothing critical is missing.

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 low (33%), but the description compensates by explaining that page and limit paginate the feed with defaults. The required rationale parameter is not mentioned in the description, but the schema provides a thorough explanation for it, so the agent is not left without 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 names a specific verb and resource: 'Get the ids of recent changes to CoinPaprika's coin and exchange listings (additions, renames, delistings)'. It clearly distinguishes this from the many other getter tools by focusing on changelog IDs for sync purposes.

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 lists canonical use cases: 'what changed recently', 'new or delisted coins', 'listing changelog'. It does not name alternatives or exclusions, but none of the sibling tools appear to offer the same changelog capability, so the guidance is sufficiently 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 declare readOnly, idempotent, openWorld, non-destructive, and the description adds useful context: no API key required and the fact that price is out of scope. It does not contradict annotations and provides mild extra behavioral color beyond the structured hints.

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?

Three sentences with no filler: purpose, usage examples/alternatives, and access/resolution notes are each front-loaded and compact. Every sentence 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?

The tool is a simple read operation with a rich output schema and fully documented parameters; the description covers purpose, scope, exclusion, authentication, and id resolution. Nothing essential for correct invocation is missing.

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 both parameters are already well documented, especially coinId with format, examples, and resolution caveats. The tool description adds little beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Get descriptive project information about a coin') and enumerates fields (description, links, team, tags). It differentiates from siblings by explicitly excluding price and naming getTickersById as the price tool, so an agent can choose correctly.

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?

Gives concrete natural-language triggers ('tell me about Uniswap', 'what is this project') and explicit when-not-to-use guidance ('Does NOT include price; ... use getTickersById'). Also instructs resolving coinId via resolveId, covering the key prerequisite.

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, idempotentHint, and destructiveHint, so the read-only nature is covered. The description adds useful non-obvious behavior: coinId must be a canonical id, limit caps results, and no API key is required. These go beyond the annotation schema and help the agent set expectations.

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?

Four tight sentences with no filler: purpose and event examples first, then use-case phrases, then the price-tool alternative, then behavioral/auth notes. Every sentence earns its place and the key scoping constraint is front-loaded.

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?

The combination of purpose, event types, example queries, alternative routing, parameter constraints, read-only status, auth requirements, and limit behavior makes this sufficient for an agent to decide when and how to call it. An output schema exists, so return-value detail is not the description's responsibility.

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 already covers coinId and rationale thoroughly, including slug format, examples, and the 'do not pass ticker symbols' warning. The description adds only minimal parameter value by saying 'coinId is a canonical id' and 'limit caps results'. With 67% schema coverage and the missing limit description only partially compensated, this is adequate but not outstanding.

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 names a specific action and resource: getting the timeline of events for a coin, with concrete event types (launches, partnerships, hard forks, conference talks) and result contents (dates and descriptions). It also distinguishes itself from price-focused siblings by explicitly deferring price queries to getTickersById.

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 explicit use-case phrases ('what is happening with X', 'upcoming events for Ethereum', 'X roadmap events') and names the alternative tool for price-related queries. This gives an agent clear selection criteria without having to inspect sibling descriptions.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavioral context beyond those annotations: the result contains only venue names, 'limit caps results', and no API key is required. This goes beyond redundant safety labeling, though it doesn't detail output format further; the output schema covers that.

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: it states the core behavior first, then gives usage examples, sibling-tool routing, and key constraints. Every sentence earns its place and there is no filler or redundant restatement of the tool name.

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, the rich input schema descriptions, the output schema, and the annotations, the description is complete. It tells the agent what the tool returns (venue names only), how to route related requests, when it is usable without a key, and what the optional limit does. Nothing essential is missing.

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 67%: coinId and rationale have detailed descriptions in the schema, while limit does not. The description adds meaning for limit ('limit caps results') and reiterates the canonical-id requirement for coinId, which helps prevent misuse. It does not need to repeat rationale because the schema already explains it thoroughly with examples.

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 and resource: 'List the exchanges that LIST a specific coin (venue names only)'. It explicitly distinguishes the tool from getCoinMarkets and getTickersById, and the stated use cases ('which exchanges list X', 'is X on Coinbase') make its 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 provides explicit when-to-use guidance with concrete natural-language queries ('which exchanges list X', 'is X on Coinbase', 'where is X listed') and names the alternatives for adjacent use cases: getCoinMarkets for per-market buy prices/volume and getTickersById for live price. It also notes there is no API key required, so an agent knows this tool is the low-friction choice for listing venues.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context beyond the annotations: 'No API key required' (auth info), and clarifies how quotes and limit behave. It does not contradict the annotations ('Read-only' aligns with readOnlyHint).

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?

Three sentences with zero waste: purpose is front-loaded, example queries follow, then the sibling alternative and parameter/behavior notes. Every clause earns its place, and the structure leads with the most decision-relevant 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?

With an output schema present, return values need no explanation. The description covers purpose, usage triggers, the differentiating sibling, parameter semantics, read-only behavior, and auth requirements. Nothing an agent needs to call this tool correctly is missing.

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 50% — coinId and rationale are richly documented in the schema, but limit and quotes have only bare type/default entries. The description compensates by explaining 'quotes sets quote currencies, limit caps results' and the canonical-id nature of coinId, which are the exact under-documented aspects.

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 verb and resource ('Get the specific markets and trading pairs where a coin trades') and adds concrete query examples ('where can I buy X', 'X price on Binance') that make the tool's purpose unmistakable. It also names the sibling it is not ('For just the list of exchange names use getCoinExchanges'), so an agent can differentiate it from the closest alternative.

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 gives usage triggers ('Use for ...'), which tells the agent exactly when to invoke this tool. It also names the alternative tool and the condition that selects it ('For just the list of exchange names use getCoinExchanges'), leaving nothing to inference.

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, idempotentHint, and destructiveHint, and the description adds meaningful context beyond them: it requires a Starter+ plan with COINPAPRIKA_API_KEY, notes that limit caps the number of candles, and warns that coinId must be resolved rather than guessed. This goes beyond the structured annotation data without contradicting it.

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 front-loaded with purpose and usage, followed by a dense but organized parameter summary. It is appropriately sized for a 7-parameter historical data tool, though the 'Read-only' phrase is slightly redundant given the annotations and the parameter summary partly repeats schema content.

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 tool with rich schema coverage, detailed annotations, and an output schema, the description covers the remaining invocation-critical context: auth requirements, ID resolution, date formats, interval choices, limits, and sibling routing. Nothing essential for correct usage is missing.

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 the schema already provides detailed parameter descriptions, examples, enums, and defaults. The description adds a compact summary but little genuinely new semantic information beyond what the input schema supplies, so the 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 opens with a specific verb and resource: 'Get OHLC candles (open, high, low, close, volume) for a coin.' It further distinguishes itself from siblings by explicitly stating that getTickersHistoricalById is for one past price and getCoinOHLCVLatest is for the latest candle, so an agent can select the right tool without ambiguity.

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 gives explicit use cases ('daily chart last month', 'hourly candles since Jan 1') and names alternatives with their conditions ('For one past price use getTickersHistoricalById; for the latest candle use getCoinOHLCVLatest'). It also instructs agents to resolve canonical IDs via resolveId, preventing a common invocation error.

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 read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations: no API key is required, quote defaults to usd, and coinId must be a canonical id resolved via resolveId. This helps an agent invoke it safely and correctly.

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 three concise sentences with no filler. It front-loads the core function, then provides a concrete use case and a pointer to the relevant alternative.

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, annotations, and sibling context, the description covers the key invocation details: canonical id resolution, default quote, no authentication required, and the distinction from live spot price. Potential confusion with OHLCVToday/Historical is mitigated by the 'full-day' and 'yesterday's candle' phrasing.

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 description mostly restates the schema's existing default for quote and the canonical coinId rule already detailed in the coinId property description. It adds little new parameter meaning beyond what the schema already provides, though it does helpfully surface the quote default and the resolveId requirement in prose.

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 verb and resource: 'Get the latest full-day OHLC candle...for a coin.' It names the exact fields (open, high, low, close and volume) and explicitly contrasts with getTickersById for live spot price, making the tool's scope clear relative to siblings.

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 gives an explicit use case ('yesterday's candle for BTC') and an explicit alternative for a different need ('For the live spot price use getTickersById'). It does not explicitly mention getCoinOHLCVToday or getCoinOHLCVHistorical, though 'latest full-day' and 'yesterday's candle' imply the distinction.

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, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that, noting the candle is in-progress, that the operation is read-only, and that no API key is required. This goes beyond the structured hints 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?

Four short sentences, each earning its place: the operation, the use case, routing to alternatives, and access/read-only notes. The most important information is front-loaded and no wording is wasted.

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, annotations cover safety semantics, and the description supplies routing, data nature, auth requirements, and ID resolution, nothing essential is missing for an agent to select and 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 description reminds users that coinId is a canonical id and suggests resolveId, but the input schema already documents coinId and rationale in detail. The quote parameter is only visible through its schema default and is not mentioned in the description, so the description provides only modest additional 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 opens with a specific verb and resource: "Get today's in-progress OHLC candle for a coin." It also gives a concrete use case, "today's high and low for ETH," and explicitly contrasts itself with getTickersById and getCoinOHLCVHistorical, making sibling differentiation easy.

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 is explicit about when to use this tool versus alternatives: use it for today's in-progress OHLC, use getTickersById for current spot price, and use getCoinOHLCVHistorical for past candles. It also directs callers to resolve coinId via resolveId first, which is clear operational guidance.

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 establish readOnly/openWorld/idempotent/non-destructive. The description adds limit-cap behavior, no-API-key requirement, and the price exclusion, which are not encoded in annotations. No contradiction found.

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?

Four tight sentences, each serving a purpose: function, use case, price alternative, and access/limit note. The core action is front-loaded and no sentence is wasted.

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 an output schema present, return fields do not need detailing. The description plus annotations and schema fully cover invocation intent, expectations, limitations, and alternatives.

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 schema already documents both parameters, including limit defaults/max/clamping and rationale requirements. The description only restates that limit caps results, adding marginal value beyond the schema.

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 verb and resource: 'List all available coins with id, name, symbol and rank.' It also distinguishes itself from price tools by explicitly saying it does not include prices, which differentiates it from getTickers and getTickersById.

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 'Use to discover coins or map a name to an id' and gives a when-not: 'Does NOT include prices; for prices use getTickers or getTickersById.' This provides clear routing 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.

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

Annotations already mark this as read-only and idempotent, and the description reinforces with 'Read-only' and adds concrete behavior: unknown platformId returns an error, limit defaults to 50 and maxes at 250. It also states no API key is required. This goes beyond the structured 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?

The description is information-dense but well organized: purpose, use cases, alternatives, then parameters. No filler, though the param summary could be slightly tighter; still every sentence 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?

Covers purpose, use cases, prerequisite (getPlatforms), sibling routing, parameter semantics, error behavior, and auth requirement. Combined with the output schema and annotations, an agent has everything needed to invoke it 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?

With only 33% schema description coverage, the description compensates by explaining platformId with concrete examples and limit with default/max. The rationale parameter is already documented in the schema, so the description doesn't need to repeat it.

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?

States a specific verb ('List') and resource ('token contract addresses tracked on one platform') and the mapping to CoinPaprika coin ids. It explicitly distinguishes itself from getTickerByContract and getHistoricalTickerByContract, so an agent can tell it apart.

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?

Gives explicit use cases ('contracts on ethereum', 'what tokens does BSC have') and an alternative for live price/history via sibling tools. It also instructs to find platformId first via getPlatforms, leaving no ambiguity about when to call this 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond the annotations by stating 'No API key required' and clarifying that exchangeId is a friendly id 'such as binance'. This is not a contradiction, and the added access and id-format details improve transparency.

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 well-structured: purpose first, then usage examples, then disambiguation, then access and id guidance. Every sentence earns its place, and the most important scoping information is front-loaded. There is no filler or redundant restatement of the tool name.

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 read-only get-by-id tool, the description covers the core workflow, examples, id discovery, and authentication requirements. The output schema exists, so return-value details do not need to be enumerated. The only notable gap is the undocumented optional quotes parameter, but the overall definition is still sufficient for correct selection and invocation in most cases.

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 description adds real meaning for exchangeId by clarifying it is an exchange id such as 'binance' and explaining how to obtain it. The required rationale parameter is documented in the schema with examples. However, schema description coverage is only 33% overall, and the optional quotes parameter is not explained anywhere, leaving one parameter without semantic 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 states the action: 'Get details for a specific exchange' and enumerates the specific fields returned (24h volume, market count, trust score, links, fiat support). It also provides concrete example user queries, which helps an agent recognize when this tool applies. It is well differentiated from the sibling getExchangeMarkets by explicitly scoping this tool to exchange details rather than traded pairs.

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 when-to-use guidance with example phrases like 'tell me about Binance' and 'is X a trustworthy exchange'. It also names the alternative tool for a different need: 'For the pairs traded there use getExchangeMarkets'. It further instructs the agent to find the exchange id first via search or getExchanges, leaving no ambiguity about the intended workflow.

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 carry readOnly/idempotent/non-destructive hints, so the description adds value with 'No API key required' and parameter default behaviors (quotes default 'usd', limit default 50). It also states output contents and examples. 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?

The description is dense but every sentence adds value: purpose, usage examples, sibling routing, auth/read-only status, and parameter details. Slight redundancy ('Read-only' repeats the annotation) but the overall structure is front-loaded and scannable.

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?

Covers purpose, output shape, parameter semantics, sibling routing, auth, and read-only behavior. An output schema exists to formalize return values. The only omission is the required rationale parameter, which is already described in the schema, so nothing critical is missing 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 only 25%, and the description compensates by explaining exchangeId with an example, quotes as a comma-separated list with default, and limit as a cap with bounds. It omits the required rationale parameter, but the schema's own property description covers it thoroughly.

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: 'List the trading pairs (markets) on one exchange as a list', and enumerates output fields. It also clarifies scope with usage examples ('what pairs trade on Binance') and distinguishes itself from the exchange-stats sibling by naming getExchangeByID.

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?

Explicitly says 'Use for...' with concrete queries, names the alternative for other purposes ('For exchange-level stats... use getExchangeByID'), and instructs how to obtain the required ID ('find the exchangeId first with getExchanges'). No ambiguity about when to call this 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, idempotentHint, and destructiveHint false, and the description reinforces this with 'Read-only' and 'No API key required.' It also adds useful behavioral context beyond annotations: results are ranked by rank, limit can cap result count, and quotes control which volume figures are returned.

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 well-structured: purpose and output fields first, then usage guidance with alternatives, then parameter semantics. Every sentence adds value and there is no redundant or filler text.

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?

The tool is a read-only list endpoint with an output schema available, so the description does not need to explain return values. It covers purpose, ranking, output fields, use cases, alternative tools, auth requirements, and both optional parameters, making it fully sufficient for an agent to decide when and how 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?

The schema only describes rationale in detail, leaving limit and quotes undocumented there. The description compensates fully by explaining quotes as a comma-separated list of quote currencies with default 'usd' and an example, and limit as an optional cap with default 50 and max 250. Together with the schema's detailed rationale description, every parameter is meaningfully documented.

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: 'List exchanges tracked by CoinPaprika as a list ranked by rank, each with id, name, trust score, active market count and 24h volume.' It clearly names the output fields and ranking order, and it distinguishes this tool from getExchangeByID and getExchangeMarkets by naming what those alternatives do.

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 states when to use this tool ('top exchanges by volume', 'biggest crypto exchanges', 'to find an exchangeId') and names the alternatives for different needs: getExchangeByID for full stats and getExchangeMarkets for trading pairs. This provides clear routing guidance with no ambiguity.

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 annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description usefully reinforces 'Read-only' and adds that no API key is needed. However, the claim 'takes no parameters' conflicts with the schema's required 'rationale' parameter, so the description is partially misleading about the actual invocation contract.

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 three compact sentences with no filler: purpose, example trigger phrases, alternative tool, and auth/safety note are each given efficiently. The most decision-relevant information is front-loaded.

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 read-only market-wide tool, the description covers purpose, usage context, alternative routing, and authentication, while the output schema presumably covers return structure. The false 'takes no parameters' statement creates a real invocation gap, so the description is not fully reliable or complete.

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 documents the required 'rationale' parameter with a clear description and examples, so the baseline is 3. However, the description explicitly says the tool 'takes no parameters,' which would cause an agent to omit the required rationale and fail validation. This active contradiction with the schema outweighs the schema's strong documentation.

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 names a specific verb ('Get'), a clear resource ('global crypto market overview'), and enumerates the exact metrics returned: total market cap, total 24h volume, Bitcoin dominance, and market-wide 24h change. It is easily distinguishable from siblings like getTickersById, getTickers, and getCoinMarkets because it is explicitly market-wide rather than coin-specific.

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 concrete example user queries ('how is the crypto market doing', 'total market cap', 'BTC dominance') and explicitly directs agents to getTickersById for single-coin price queries. This is strong when-to-use and when-not-to-use guidance that reduces tool-selection errors.

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?

Even though annotations already declare readOnlyHint and idempotentHint, the description adds valuable non-obvious behavior: it requires a Starter+ plan, details hosted free-tier restrictions (daily intervals up to a year, hourly intervals up to 24 hours), and states that unsupported ranges return a structured CP402_PAID_ENDPOINT stub. This goes well beyond the annotation baseline and informs the agent of real-world failure modes.

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 well-structured and front-loaded: purpose sentence, usage examples, sibling routing, param summary, and plan constraints all earn their place. It loses one point because the param summary largely duplicates schema content and contains the interval-default contradiction, preventing it from being a perfectly clean, concise definition.

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 8 parameters, full schema coverage, and an output schema, the description supplies the missing operational context: plan requirements, hosted-server interval limits, and sibling-tool routing. It is nearly complete, but the interval-default contradiction and the absence of the required rationale parameter in the narrative summary leave minor gaps that could cause an incorrect 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 coverage is 100%, so the baseline is 3, and the description does add examples for platformId and contractAddress plus plan limits. However, it directly contradicts the schema by claiming interval default '5m' while the schema declares default '1d', and it omits the required 'rationale' parameter from its param summary. The incorrect default is actively misleading for an otherwise well-documented parameter set.

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 + resource + scope: 'Get a token's price and market history by its contract address, as a time series.' It immediately distinguishes itself from siblings by explicitly naming getTickerByContract for current price and getTickersHistoricalById for coin-id lookups, so an agent can tell exactly which tool to select.

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 concrete query patterns ('token price on 2024-01-01 by address', 'hourly history for a contract') and explicit routing rules: use getTickerByContract for current price, getTickersHistoricalById for coin-id historical data. It also clarifies plan-tier eligibility by explaining free-tier interval limits and when a paid API key is required.

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?

Adds a concrete auth requirement (Business-plan key) and describes filter behavior (optional provider filters, narrowing with more params). It also confirms read-only, matching annotations. Minor accuracy issue: 'every parameter is an optional filter' overlooks the schema's required rationale, which prevents a top score.

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?

Three sentences, front-loaded purpose, then use cases, then behavior/auth. No filler or repetition of schema details.

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 7-param, 1-required tool with rich annotations and an output schema, the description covers purpose, usage signal, filter semantics, and auth prerequisite. It would benefit from explicitly acknowledging the required rationale in the description itself, but nothing critical is missing.

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 only 14%, so the description carries the burden; it maps each provider property to a named external system and explains combination semantics. It doesn't spell out value formats or the role of the coinpaprika param, but it is sufficient for basic invocation.

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?

States a specific operation: getting mappings between CoinPaprika ids and external/legacy identifiers, naming the provider families. The added query phrases ('id crosswalk', 'external id mapping') make the tool's role clear even relative to siblings like resolveId. No tautology or vague wording.

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?

Gives explicit trigger phrases and the high-level use case (reconciling ids across systems). It does not name sibling alternatives or state when not to use it, so it stops short of a full 5.

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 read-only, idempotent, and open-world behavior, so the description's 'Read-only' line is redundant. However, it adds useful operation-specific behavior: unknown ids return not found, no API key is required, and the id is a canonical slug rather than a free-form name. This goes beyond what the annotations alone provide.

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 core action is front-loaded, followed by use cases, prerequisite, and parameter format. It is compact and each sentence earns its place; the only slight redundancy is 'Read-only' duplicating the annotation.

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 an output schema available, the description does not need to explain return values, and it covers the key prerequisites: resolve personId first, use exact id, not-found behavior, auth, and example triggers. The only omitted element (required rationale) is fully specified in the input schema, so the full tool definition is complete.

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 leaves personId as a bare string, so the description compensates with canonical examples ('vitalik-buterin', 'satoshi-nakamoto') and clarifies the exact-id requirement. The rationale parameter is well documented in the schema, but the description's Params section mentions only personId, which is a minor gap.

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: 'Get the profile of one person in crypto by id', then lists the returned fields (name, bio, teams_count, positions, linked projects, social/code accounts). It distinguishes itself from sibling tools like getCoinById by being person-focused and requiring an exact id.

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 gives concrete example queries ('who is Vitalik Buterin', 'background on Charlie Lee') and explicitly instructs the agent to resolve personId via search or resolveId with type 'people' first. It also states the negative case: do not pass a name, the tool needs the exact id. This fully routes the agent to the right tool and prerequisite.

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, idempotentHint=true, and destructiveHint=false. The description adds meaningful context beyond those annotations: 'limit caps results' clarifies the pagination/truncation behavior of the limit parameter, and 'No API key required' discloses authentication requirements. 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?

Three sentences with zero waste: core purpose, usage guidance with concrete query phrasings and sibling routing, then behavioral notes. Each sentence earns its place, and the most decision-relevant information (what it lists) is front-loaded.

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 read-only list tool with only two parameters and an output schema present, the description is complete. It covers purpose, usage triggers, sibling routing, auth requirements, and limit semantics, while annotations cover the safety profile. Nothing an agent needs to call this correctly is missing.

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 50%, so the description must partially compensate. It adds meaning for the undocumented 'limit' parameter by clarifying it 'caps results', and it implies the return value contains platform ids usable as input to getContracts. The 'rationale' parameter is already fully documented in the schema, so no duplication 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 names a specific verb and resource: 'List the smart-contract platforms (blockchains such as ethereum, bnb, polygon) for which CoinPaprika indexes token contracts.' Concrete examples and the explicit scope ('indexes token contracts') make it distinguishable from siblings such as getContracts and getTickerByContract without opening the schema.

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 states when to use the tool: 'Use for "which chains are supported for contract lookups", "list contract platforms", or to pick a platform id before calling getContracts.' It names getContracts as the natural follow-up tool. It lacks an explicit when-not-to-use clause, so it earns a 4 rather than a 5.

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 readOnly, openWorld, idempotent, and non-destructive, but the description adds valuable behavior beyond that: unknown tagId returns an error, no API key is required, additionalFields is optional and defaults to none, and valid values are enumerated. No contradiction with annotations exists.

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 dense but every sentence earns its place: purpose, return fields, use cases, sibling tool relationship, parameter semantics, default behavior, error behavior, and auth requirement are all covered in a compact, front-loaded block.

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 read-only lookup tool with a rich schema and output schema, the description covers everything needed to call it correctly: how to obtain tagId, optional fields, valid values, error behavior, and authentication. Nothing critical is missing.

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?

With only 33% schema description coverage, the description compensates thoroughly: tagId is explained as an id from getTags with an example, and additionalFields is described as a comma-separated list with valid values and a concrete example. The rationale parameter is fully described in the schema itself, so no gap remains.

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 verb and resource: 'Get details for one CoinPaprika tag', and enumerates exactly what fields are returned. It also gives concrete examples ('defi', 'stablecoin') and explicitly contrasts with getTags, making sibling differentiation immediate.

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 provides explicit use cases ('what coins are in the defi tag', 'show the stablecoin category') and names the alternative tool and the condition for choosing it: 'To list every tag or find a tagId first use getTags.' It also clarifies required input provenance and error behavior for unknown tags.

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 cover read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds useful auth context ('No API key required') and states that additionalFields can expand each tag's payload, providing behavior 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 dense but organized: purpose first, use cases second, parameters last. It is longer than the minimum, but every sentence adds value and the structure keeps it 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?

For a listing tool with rich annotations and an output schema, the description covers purpose, return shape, parameter behavior, auth, and the relationship to a sibling tool. No critical information is missing for an agent to call it 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 low (33%), but the description thoroughly compensates by documenting additionalFields valid values ('coins', 'icos') and limit's default and maximum. The rationale parameter is already well described in the schema, so no further detail 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 states a specific action ('List all CoinPaprika tags'), names the resource, and explains the returned fields (id, name, coin_counter, ico_counter). It also distinguishes itself from getTagById by noting that getTags is for summaries while getTagById is for coins inside a tag.

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 gives use cases ('what crypto categories exist', 'list market sectors') and tells the agent to use getTagById when the coins inside a tag are needed. This is clear when-to-use and alternative routing.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context by noting no API key is required and clarifying this is for current data rather than history.

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 with the core purpose, followed by usage guidance, parameter hints, and auth requirements. Every sentence adds actionable value with no 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 read-only tool with an output schema present, the description covers purpose, usage conditions, alternative routing, key parameter semantics, and auth. Nothing essential is missing for an agent to invoke it 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 only 33%, and platformId and contractAddress have no descriptions in the schema. The description compensates by explaining platformId is the chain (e.g., eth-ethereum) and contractAddress is the token address. The rationale parameter is fully documented in the schema.

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 fetches current price and market data for a token by contract address, explicitly targeting on-chain and DeFi tokens. It also differentiates from getHistoricalTickerByContract, so an agent can distinguish it from siblings without inspecting schemas.

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 to use this tool when a contract address is available rather than a name, and directs historical requests to getHistoricalTickerByContract. This gives concrete when-to-use and alternative guidance.

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 read-only, idempotent, and non-destructive behavior; the description reinforces this and adds non-obvious context such as 'No API key required' and the default quote currency. It does not discuss rate limits or freshness, but the key access and mutation traits are clearly disclosed.

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: purpose, use cases, the key alternative, parameter notes, and access requirements are all covered in a few short sentences. No fluff or repetition of schema fields.

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 an aggregate market-snapshot tool with an output schema already present, the description covers access, ordering by market cap, parameter behavior, and the primary fallback for single coins. An agent can call it correctly without additional inference.

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 only documents 'rationale', so the description carries the burden for 'quotes' and 'limit'. It clarifies that quotes sets quote currencies (default USD) and limit caps results, which is exactly the missing semantics. 'rationale' remains well-documented in the schema.

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 ('current prices, market caps and 24h changes for the top cryptocurrencies'), and adds an explicit scope ('ranked by market cap'). It is immediately distinguishable from sibling coin-specific 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?

It explicitly lists natural-language triggers ('top 5 coins', 'top crypto today', 'biggest cryptocurrencies', 'market snapshot') and names the correct alternative for one specific coin: getTickersById. This removes ambiguity about when to use it.

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 carry readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds useful context beyond annotations: it is read-only, requires no API key, and that quotes defaults to USD. This supplements the structured hints 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?

The description is compact and front-loaded with the core purpose, then example queries, routing, and prerequisites. Every sentence adds information and there is no redundant 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 simple one-crypto scope, full annotations, and an output schema, the description covers purpose, example triggers, historical alternative, canonical-id prerequisite, quote currency behavior, and auth requirements. Nothing essential is missing for an agent to select and invoke it 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 covers coinId and rationale well, and the description compensates for the undocumented quotes parameter by stating it sets the quote currency with USD default. With 67% schema coverage, the description fills the main gap, though possible quote currency values are not enumerated.

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?

Clearly states verb+resource: 'Get the current price, market cap, 24h change and volume of one cryptocurrency in USD or another quote currency.' It also differentiates from sibling getTickersHistoricalById by specifying 'For past prices use...' and includes concrete example queries.

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?

Explicitly gives when-to-use triggers ('what is the price of X', 'BTC to USD') and an exact alternative for when not to use it ('For past prices use getTickersHistoricalById'). It also gives a prerequisite: resolve a bare symbol with resolveId first.

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 provide readOnlyHint, idempotentHint, and non-destructive hints, but the description adds substantial behavioral context beyond those: it returns point-in-time snapshots rather than candles, requires a Starter+ plan (COINPAPRIKA_API_KEY), and documents free-tier limits (daily intervals up to a year back, hourly up to 24 hours, otherwise a structured CP402_PAID_ENDPOINT stub). This directly prevents an agent from misusing the tool on the free tier.

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 long, but every sentence carries operational value: purpose, examples, sibling routing, parameter formats, plan requirements, and free-tier boundaries are all packed in. The front-loaded purpose sentence and the compact param summary show intentional structuring. Slightly verbose in the middle (pure parameter recap that overlaps the schema) but the additional caveats justify the length.

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 7-parameter tool with free-tier quirks and plan requirements, the description is remarkably complete: it covers what the tool returns, when to use it, which siblings to use instead, param formats and defaults, the coinId resolution requirement, plan/API-key needs, free-tier interval/range limits, and the structured error stub behavior. The output schema presumably covers the return shape, so nothing essential is missing.

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 baseline is 3; the description earns a 4 by adding the free-tier interval/range constraints not present in the schema ('daily and coarser intervals... served for the last year and hourly ones... for the last 24 hours'), clarifying the CP402_PAID_ENDPOINT failure mode for unsupported combos, and reinforcing the coinId resolution workflow with the 'aave-new' example. It doesn't just echo the schema, it enriches the interval and coinId 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 ('Get a coin's price, market cap and volume at past times as point-in-time snapshots'), explicitly distinguishes itself from OHLC candles with concrete example queries, and names sibling tools (getCoinOHLCVHistorical, getTickersById) it is not. An agent can immediately understand what this tool does and how it differs from adjacent 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 says when to use this tool ('price of BTC last Tuesday', 'ETH market cap on 2024-01-01') and gives named alternatives for other cases: 'For OHLC chart candles use getCoinOHLCVHistorical; for the current price use getTickersById.' It even covers when NOT to use it via the free-tier restrictions, making the routing decision unambiguous.

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, idempotentHint, and non-destructive behavior. The description adds valuable context: it requires a user-supplied paid CoinPaprika key, returns a plan-required message without one, and reports the user's key rather than the server's. This goes beyond the annotation profile.

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, front-loaded with the core purpose, and every clause adds relevant context: use cases, preconditions, and key ownership. The inaccurate 'takes no parameters' phrase prevents a perfect score because it is misleading rather than helpful.

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?

The description covers purpose, usage triggers, authentication requirements, error behavior, and read-only status, and an output schema exists for return values. However, the 'takes no parameters' claim conflicts with the required rationale input, making the description not fully reliable as a standalone guide 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?

The input schema has 100% coverage and fully documents the required rationale parameter, so the baseline is 3. However, the description states 'takes no parameters,' which directly contradicts the schema's required 'rationale' property. This active misstatement outweighs the schema coverage and could cause an agent to omit the required argument.

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 ('details and usage for the CoinPaprika API key you supplied') while listing concrete attributes: plan, quota, requests remaining, and expiry. This clearly distinguishes it from sibling market-data tools like getTickers or getCoinById.

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 names trigger phrases ('what plan am I on', 'how many requests are left', 'is my API key valid') and states the paid-key precondition and failure mode. It does not explicitly name alternatives or when-not-to-use cases, but the tool's narrow scope makes the intended usage 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 cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds genuine behavioral context beyond that: 'at the current rate' clarifies this is a spot conversion (not historical), and 'No API key required' discloses authentication requirements. The 'Read-only' phrasing repeats an annotation, so not full credit, but the additional traits earn a strong score.

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?

Three sentences, each earning its place: core function with examples, sibling routing, and a compact summary of parameter roles plus auth requirements. No filler, no repetition of schema details beyond a brief clarifying clause.

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?

The description covers purpose, usage conditions, sibling differentiation, auth requirements, and parameter semantics, while the 100%-coverage schema handles detailed parameter constraints (including the 0-value warning on amount) and the output schema handles return-value expectations. Error behavior for invalid symbols is also covered in the schema ('symbols like BTC are rejected upstream'). Nothing essential is missing 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 100%, so the parameters are already fully documented in the schema (slugs, required status, default amount, rationale rules). The description's note that 'baseCurrencyId and quoteCurrencyId are canonical ids and amount is the quantity to convert' is a light restatement that reinforces but does not materially extend the schema. 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 opens with a specific verb and resource: 'Convert an amount from one crypto or fiat to another at the current rate,' and grounds it with concrete examples ('how much is 0.5 BTC in USD'). It explicitly differentiates from the sibling getTickersById, which handles the no-amount case, so an agent can distinguish it without opening the schema.

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 routing: 'For a plain coin price without an amount, use getTickersById.' This names the alternative and the condition that selects it, and the example phrasings clarify the intended call patterns. No ambiguity is left about when this tool is the right choice.

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, idempotentHint, openWorldHint, and destructiveHint false. The description adds useful behavioral context beyond those annotations: results are ranked best-first, the return fields are listed, an empty list means no match, ids are not derivable, and no API key is required.

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 front-loaded with purpose and workflow, followed by terse parameter explanations, examples, and auth notes. Every sentence adds a distinct useful fact, with no filler or repetition of the schema.

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 read-only, idempotent annotations and the presence of an output schema, the description covers trigger conditions, follow-up use, return value shape, failure semantics, and parameter constraints. Nothing essential for correct invocation is missing.

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 only 25%, so the description carries most of the parameter burden. It clearly explains type ('one of coin, exchange, people, tags sets entity kind'), query ('fuzzy text'), and limit ('optional, default 50, max 250'). However, it omits the required 'rationale' parameter from the natural-language params list, even though the schema itself documents rationale well.

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 verb ('Resolve'), a clear resource ('fuzzy coin, exchange, person or tag name or symbol'), and a definite outcome ('ranked list of candidate CoinPaprika ids, best first'). It also differentiates the tool from siblings by explaining it is the id-resolution step before getTickersById.

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 says 'Call FIRST when you have a bare name or symbol but need an id' and prescribes the follow-up action: 'pass the id to getTickersById for price.' This gives an agent concrete when-to-use guidance and prevents confusion with sibling lookup tools.

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 readOnly, openWorld, idempotent, and non-destructive hints. The description adds useful behavioral context beyond those: no API key is required, querying is driven by q, categories filters entity types, and limit caps results. It does not cover errors or pagination, but the annotations lower the burden here.

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 well-ordered: search scope, usage trigger, alternative, and operational notes. Every sentence earns its place, and there is no filler or redundant schema repetition.

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 full input schema and an output schema available, this description covers the essential context: what is searched, when to use it, when not to, authentication, and key parameter behavior. The only minor gap is the vague 'modifier' parameter, but the schema itself shares that ambiguity.

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 briefly restates q, categories, and limit, but the schema already gives more precise semantics such as limit being per category and q being case-insensitive/partial-match. It adds no additional meaning for modifier or rationale.

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 names a specific verb ('Broadly search'), a defined resource set ('coins, exchanges, ICOs, people and tags'), and a search mode ('by name or symbol'). It also explicitly distinguishes the tool from resolveId, making its role clear among siblings.

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 states the exact condition for use ('when the entity type is unknown or you are exploring') and gives a natural-language trigger ('find anything called X'). It names resolveId as the preferred alternative when a canonical coin id is needed, satisfying the when/when-not requirement.

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 provide readOnlyHint, idempotentHint, and destructiveHint=false, so the bar is lower. The description adds useful context (no API key needed; reports server status rather than market data), but it falsely claims 'takes no parameters' while the schema requires a rationale parameter. This misleads an agent about invocation requirements and undermines transparency.

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 short, front-loaded with the core purpose, and uses clear examples. The false 'takes no parameters' clause is the main flaw; otherwise the structure is tight and every sentence contributes to routing or scope.

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?

The output schema and annotations cover much of the context, but the description's claim that the tool 'takes no parameters' directly contradicts the input schema's required rationale. As a result, an agent relying on the description alone would fail to call the tool correctly. This is a significant completeness gap for a simple status 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 description coverage is 100%, with a fully documented required rationale parameter. The description adds no parameter meaning and actively contradicts the schema by stating 'takes no parameters', which would cause an agent to omit the required rationale field.

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 and resource ('Get the CoinPaprika MCP server's status and configuration') and lists concrete fields (uptime, mode, enabled features). It also explicitly distinguishes itself from market-data tools by saying 'This reports the MCP server itself, not the crypto market,' which separates it from siblings like getGlobal and getCapabilities.

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 gives explicit trigger phrases ('is the server up', 'what mode am I in', 'server status') and an explicit alternative: 'for market health use getGlobal'. This tells an agent exactly when to invoke it and when to choose a different 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?

The annotations are all false hints and provide little guidance, so the description carries the burden. It adds useful behavioral context: low friction, partial feedback is acceptable, and every submission is read. It does not fully describe side effects or whether any response comes back, but the core behavior is transparent enough.

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 concise and front-loaded with the core purpose, followed by concrete invocation triggers and a helpful reassurance. Every sentence earns its place, and there is no redundant repetition of schema content.

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 low-complexity feedback tool, the description is complete: it explains when to use it, what counts as valid feedback, and that partial feedback is welcome. The rich input schema and existing output schema cover the remaining details an agent needs.

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 input schema already documents every parameter thoroughly. The description adds general context about stuck points and missing information but does not need to repeat parameter semantics; 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 opens with a specific verb and resource: 'Report a problem or gap back to the CoinPaprika MCP maintainers.' It clearly distinguishes this tool from all sibling data-lookup tools, which are about fetching market data, not submitting feedback.

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 gives explicit when-to-use conditions: got stuck, unexpected response, missing information, or tool behavior not as documented. It also maps natural user expressions like 'this is wrong' and 'report this' to invocation, which strongly helps an agent recognize the right moment to call it.

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