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

Annotations already declare read-only, idempotent, non-destructive, so the safety profile is covered and the bar is lower. The description still adds valuable context the annotations cannot: the row layout, oldest-first ordering, price denomination, and an exchange-specific failure mode (Nobitex refuses USDT/IRT). Pagination, rate limits and error shape are unaddressed, keeping it at 4.

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 short sentences, front-loaded with the core purpose, then the return shape, then the exchange caveat. No filler and nothing repeated that is already redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by specifying the candle row format and ordering, which is essential for interpretation. It is missing only secondary information such as error behavior for invalid coin/exchange combinations or rate limits.

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 enum/defaults are fully documented in the schema, so baseline 3 applies. The description's mention of Toman/USDT pricing and the 'USDT = Tether in Toman' nuance largely restates what the schema already says for coin and quote.

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 recent OHLC candles of one coin') plus scope constraints (two named exchanges, oldest-first ordering). The resource is clearly distinct from sibling tools like ic_get_ticker, ic_get_orderbook and ic_recent_trades, so an agent can route correctly 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?

Gives a concrete selection rule: Nobitex refuses USDT/IRT candles, so use Wallex for those. That is real when-to-use guidance, but there are no explicit exclusions against the sibling tools (e.g. when to prefer ic_get_ticker or ic_recent_trades instead).

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, so the safety profile is covered. The description adds genuine behavioral context beyond annotations: prices are normalized to Toman or USDT, and exchanges that are down, network-blocked, or unlisted appear under an `errors` key while others still compare. It does not discuss rate limits or return shape in more detail, but the added failure semantics are substantive.

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 the core purpose and structured into a short paragraph plus two practical notes. Every sentence carries operational value, though the schema already documents the coin/quote symbols, so the 'Use coin=USDT...' sentence is marginally redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain return behavior; it does so by stating results are cheapest-first with spread and that failures appear under `errors`. Annotations cover safety, and the description covers failure modes and verification next steps, making it largely complete for a two-parameter read tool. Minor gaps remain around exact response fields and pagination behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining the non-obvious combination 'Use coin=\'USDT\' with quote=\'IRT\' for the Tether rate in Toman,' which clarifies an edge case in how the enum and coin symbol interact.

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 combination ('Compare one coin's price on every supported exchange in one call') and adds output characteristics ('cheapest first, with the spread'). It is clearly distinguishable from siblings like ic_get_ticker and ic_get_orderbook, which it names explicitly.

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 when to use this tool (cross-exchange price comparison) and directs the agent to a specific alternative for verification: 'call ic_get_orderbook on the cheapest and the priciest exchange.' It also instructs the agent to always report missing exchanges and why, giving clear post-call 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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the level tuple format, ordering ('best first'), and the price denomination (IRT or USDT). It does not mention the depth cap, but the schema does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action, followed by the one non-obvious output detail. 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?

No output schema exists, so the description must carry return-format information; it explains the level tuple and spread, which is the essential payload. A brief note on the overall response shape (e.g. bids/asks arrays) would close the remaining gap.

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 above that by clarifying the ambiguous 'quantity in coin' meaning of the second level element and tying price units to the quote currency, which the schema does not spell out at the level-tuple level.

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 with scope: top bids and asks for one coin on one exchange, plus the spread. This is clearly distinct from sibling tools like ic_get_ticker, ic_recent_trades, and ic_candles, which return different data shapes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you need depth/liquidity or spread for a market) but never states when to prefer it over ic_get_ticker or ic_compare_price, nor any prerequisites such as first resolving the exchange id via ic_list_exchanges. Usage is inferable but not explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent), so the description correctly spends its space on behavioral quirks instead: missing bid/ask for Bitpin, Tabdeal, OMPFinex and Exir, missing volume for Tabdeal, and the fact that an unlisted coin is an error rather than an empty result. It doesn't mention rate limits or response units, keeping it from a 5.

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 short sentences: what it returns first, then data caveats, then error handling and alternatives. No sentence is filler, and the most decision-relevant information (the returned fields) 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?

With no output schema, the description usefully enumerates the returned fields and flags which are absent on which exchange, which is what an agent needs to avoid misinterpreting nulls. Only minor gaps remain, such as not clarifying the quote-currency interaction with returned values.

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 baseline is 3; the description earns above it by adding the constraint that coin symbols are exchange-specific and must be validated with ic_list_markets. The quote parameter (IRT vs USDT) is left entirely to the schema, so it isn't fully additive.

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 (get) and resource (ticker) plus the exact scope: one coin, one exchange, with enumerated fields (price, best bid/ask, 24h range, change, volume). This clearly differentiates it from siblings like ic_get_orderbook and ic_candles without needing their 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?

Explicitly routes to alternatives with conditions: ic_get_orderbook when bid/ask is unavailable, ic_candles for price history, and ic_list_markets when a coin isn't listed. It also tells the agent which exchanges lack which data, which is an unusual and useful selection constraint.

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, so the safety profile is covered. The description adds meaningful domain context beyond annotations: that every returned price is already converted to Toman (IRT markets) or is in USDT, which is important for interpreting data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences with the core purpose front-loaded and no wasted text. The guidance to start here and the unit-conversion note are both immediately relevant.

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 low complexity of a zero-parameter discovery tool, plus rich annotations and no output schema, the description provides everything an agent needs: what the tool lists, that it is a starting point, and how to interpret returned prices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there are no parameter semantics to explain. Baseline 4 is appropriate because the schema is empty and the description correctly does not invent 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 uses a specific verb+resource ('List the supported Iranian crypto exchanges') and states exactly what information is included: native price unit and what each exchange can answer. This clearly distinguishes it from sibling tools like ic_list_markets or ic_get_ticker, which operate on markets/prices rather than exchange metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Start here' gives explicit when-to-use guidance for this discovery tool. It does not name alternatives or exclusions, but the context of listing exchanges makes the entry-point role clear enough.

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

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

Annotations already declare this tool as read-only, idempotent, non-destructive, and open-world. The description adds useful scoping and pre-call validation context, but it does not describe return behavior, rate limits, authentication, or other operational traits 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?

Two short sentences, front-loaded with the core purpose and followed by a practical usage note. No wasted wording.

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, the description covers what it does and when to use it. It does not clarify the exact return shape or relationship to ic_list_exchanges, but annotations and the schema provide enough surrounding context.

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 have enums with descriptions. The description mentions IRT/USDT, but this duplicates schema information rather than adding new meaning, so the baseline of 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?

The description states a specific verb and resource: list the coins an exchange trades against IRT or USDT. This is clear enough to distinguish it from general exchange listing tools, but it does not explicitly name or differentiate itself from siblings such as ic_list_exchanges.

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 clear usage context: use it to check a coin symbol before calling other tools. It does not provide explicit when-not conditions or name alternative tools, but the intended workflow is 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 the safe read-only, idempotent, non-destructive profile, and the description adds meaningful behavior: results are public, newest first, and unavailable on OMPFinex. It also clarifies the `side` semantics when reported, though it omits return-shape and rate-limit details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences, front-loads the core operation, and includes only relevant caveats. Every sentence carries useful 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?

For a simple read-only market-data tool with rich parameter schemas and clear annotations, the definition covers the essentials: scope, ordering, availability, and `side` semantics. It could be slightly more complete about the returned trade fields or pagination behavior, especially since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameters themselves are already well documented. The description adds little parameter-level meaning beyond restating the one-coin/one-exchange scope, and its `side` note appears to describe output rather than an input parameter.

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 recent public trades for one coin on one exchange, with newest-first ordering. It is clearly distinct from order-book and candle-style siblings in substance, but it does not explicitly differentiate itself from them by name.

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 one useful usage constraint by excluding OMPFinex, but it does not explain when to use this instead of siblings such as ic_get_orderbook, ic_candles, or ic_get_ticker. The intended use is implied rather than explicitly routed.

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 and non-destructive, so safety is covered. The description adds non-obvious behavioral context the schema cannot: Tabdeal publishes no volume, so its coins bypass the volume filter entirely. That is a genuine disclosure about result composition, though it says nothing about ordering ties or response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences: the core behavior is front-loaded, and the second sentence is a genuinely useful operational note plus next-step pointer. No filler or 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?

With no output schema, the description would ideally hint at the returned fields beyond `coin`, but the follow-up instruction implies a per-coin list with identifiers, which is enough to plan a call. All five parameters are documented in the schema, and the volume-filter caveat closes the main operational gap.

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 enums and defaults on exchange/direction/quote/limit/min_volume, so the schema does the heavy lifting. The description only reinforces the filtering concept and the Tabdeal carve-out rather than adding syntax or units beyond what the schema already states.

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 ('List the biggest 24h gainers or losers on one exchange') with an explicit scoping qualifier ('illiquid coins filtered out'). This is clearly separable from siblings like ic_list_markets (all markets) and ic_candles (history) without opening any 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?

Provides a clear follow-up path — pass a mover's `coin` to ic_get_ticker or ic_compare_price for detail — which routes the agent to the right siblings. It does not state when to prefer this over ic_list_markets or ic_candles for a broader/historical view, so it falls short of full when/when-not guidance.

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