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

Annotations already cover the read-only safety profile, and the description adds substantial context beyond them: the ask/bid leg convention, the meaning of `basis: last` (gap may not be executable), the silent dropping of gaps over 15% with the reason (stale/illiquid/symbol collisions), and the exclusion of fees, withdrawal time and network costs. These are exactly the caveats that would otherwise cause an agent to over-trust the output.

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 tight paragraphs: what it does, how it computes and what it discards, then what it omits. The core purpose is front-loaded in the first clause and every subsequent sentence carries a distinct caveat with no repetition of schema 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?

For a 5-parameter read-only scanner with no output schema, the definition covers method, data-quality guards and follow-up tools well. The only real gap is that the return shape (fields per opportunity, ordering, whether the gap is expressed in percent) is left for the agent to discover.

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 explaining the semantics behind the fields — why `executable_only` matters (last-price-only exchanges produce non-executable gaps) and why 15% is a hard ceiling on `min_gap_pct`. `limit`, `quote` and `min_exchanges` are left entirely to 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?

States a specific verb and resource — 'scan every coin on every exchange for the biggest price gaps' — and immediately explains the mechanic (buy cheapest, sell dearest). This distinguishes it from ticker/orderbook siblings that return single-venue data rather than cross-venue spreads.

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 the agent onward: 'confirm with ic_get_orderbook and ic_fees', which tells it this tool is a screening step, not an execution step. It does not, however, contrast against close siblings like ic_best_deal or ic_compare_price, so the agent must infer when this scanning tool is preferable to those.

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 substantial context beyond the read-only annotations: order books are walked level by level, `filled_pct < 100` signals thin visible liquidity, brokers fill at their own price, `source: listed_price` is a single indicative price ranked last, and results are snapshots rather than quotes. It also warns that trading and withdrawal fees are excluded.

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 purpose and example questions are front-loaded, followed by precise behavioral caveats. Every sentence carries useful operational meaning: slippage mechanics, broker behavior, listed-price ranking, fee exclusion, and snapshot warning.

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?

Despite having no output schema, the description explains the key return semantics (`receive` meaning for buy vs sell), liquidity ranking caveats, and the crucial fee/snapshot limitations. This gives an agent enough context to invoke and interpret the tool responsibly.

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 `coin`, `side`, `quote`, and `amount` including examples and enums. The description reinforces `amount` semantics through examples and explains what `receive` means, but does not add materially new parameter-level detail 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 precise verb and resource: ranking exchanges by effective buy/sell outcome for a given size, including order-book slippage. It gives concrete example questions and distinguishes the result type (`receive`) for buys vs sells, so an agent can tell exactly what the tool computes.

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 clearly indicates when to use it via example questions and explicitly warns to check `ic_fees` before acting because fees are not deducted. It does not explicitly contrast with sibling tools like `ic_compare_price` or `ic_arbitrage`, so it stops short of full 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 safety is covered. The description adds real value beyond that: ordering ('oldest first'), the row layout, and a known per-exchange failure mode. It still says nothing about how far back the history reaches, empty/missing-candle behavior, or rate limits.

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 lines: purpose and ordering first, then return layout, then the exchange caveat. No filler, and the most decision-relevant constraint is not buried.

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 carries the return-shape burden (row order and column meanings, price units), which is exactly what an agent needs to parse the result. Minor gaps remain around history depth and what happens for unsupported coin/exchange pairs beyond the one Nobitex case.

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 more by tying the exchange and quote parameters together ('Nobitex refuses the USDT/IRT candles') and by clarifying that prices are denominated in Toman or USDT depending on the quote. It does not touch the limit/interval interplay ('most recent N candles, then returned oldest first'), which is left to 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?

States a specific verb and resource ('Get recent OHLC candles'), plus the scope constraint ('one coin on one exchange'), which cleanly separates it from ic_recent_trades, ic_get_ticker and ic_get_orderbook without needing to name them. The description alone tells an agent exactly what data comes back.

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 one explicit routing rule — Nobitex will not serve USDT/IRT candles, use Wallex instead — which is a concrete when/when-not for an exchange/quote combination. It does not explain when to prefer candles over the ticker or orderbook siblings, so it stops short of full 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 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 read-only, idempotent, and non-destructive behavior. The description adds substantial context beyond annotations: fee units (percent for trading fees, coin units for withdrawals), what `withdraw: false` means, what `cheapest` denotes, and how exchanges with no data appear under `missing`.

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, followed by examples and key output semantics. Every sentence earns its place by clarifying either usage or how to interpret the results, with no wasted 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?

With no output schema and a comparison-oriented tool, the description supplies the critical return semantics: units, level-1 fee scope, closed networks, cheapest open fee per network, and missing data. It covers enough for an agent to call and interpret the tool without further 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%, so the schema already documents both parameters. The description reinforces that `coin` enables withdrawal comparison and that omitting it returns trading fees only, but it adds little parameter-specific detail beyond what the schema provides, fitting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Compare trading fees and, for one coin, each exchange's withdrawal networks, fees and minimums.' It clearly distinguishes the tool from siblings like ticker, orderbook, or price comparison by focusing on fee and network 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 provides concrete example questions that illustrate when to use the tool, such as 'which exchange has the cheapest USDT withdrawal on TRC20?' It does not explicitly state when not to use it or name alternative tools, but the examples give clear contextual 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/non-destructive/openWorld, so the safety profile is covered. The description adds genuine behavioral context beyond that: level format is [price, quantity in coin], ordering is best-first, and quotes are Toman or USDT. It doesn't say whether the book is a live snapshot or cached, which keeps 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, front-loaded with what is returned, then the data shape, then the exclusion. Each line carries distinct information with no padding.

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 partially compensates by explaining level element order, ordering, and price denomination. It omits other plausible return fields (timestamps, exchange echo, spread units), which an agent may still want before parsing results.

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 coin, depth, quote, and exchange are all documented in structured form. The description only reinforces the quote-currency semantics already stated in the schema and adds nothing about depth; baseline 3 applies when the schema does the work.

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 explicit scope: top bids/asks for one coin on one exchange, plus the spread. An agent can distinguish it from ic_candles or ic_recent_trades by the resource itself, though no sibling is named 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?

"Not on the instant-swap brokers (Aban Tether, Kifpool, OK-EX, Tetherland)" gives a concrete when-not constraint that saves a failed call. It stops short of routing to alternatives such as ic_get_ticker or ic_best_deal when only a last price is needed.

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, non-destructive), and the description layers on non-obvious behavioral facts: bid/ask are unavailable for Bitpin, Tabdeal, OMPFinex and Exir, and volume is missing for Tabdeal. It also defines error behavior for unlisted symbols, which an agent cannot infer from annotations or schema.

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 tightly packed sentences: purpose first, then data caveats plus alternatives, then error handling. No filler, and the scoping sentence is front-loaded where an agent will read it first.

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 enumerates the returned fields and adds per-exchange availability caveats and error semantics, which is most of what an agent needs. The omission of the quote-currency distinction is the one meaningful gap for a multi-market price 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%, so baseline is 3. The description clarifies the coin/exchange pairing and the consequence of an invalid symbol, but never mentions the 'quote' parameter (IRT vs USDT markets), which materially changes the meaning of the returned price and is the one semantic gap left to inference.

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'), resource (live price/bid/ask/24h range/change/volume), and scope (one coin on one exchange), enumerating exactly what is returned. It also names sibling tools (ic_get_orderbook, ic_candles, ic_list_markets) so the agent can distinguish it without inspecting other 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 the agent: use ic_get_orderbook for best bid/ask and ic_candles for price history, and treat an unlisted coin as an error to be resolved via ic_list_markets. Both the when-to-use and the failure path are spelled out rather than implied.

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only the sequencing hint about validating symbols first; it says nothing about return shape, result size, or whether markets are cached/refreshed, so it adds modest value beyond structured data.

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

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

Two short sentences with zero redundancy; the core purpose is front-loaded and the workflow hint follows immediately. Nothing could be removed without losing 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 two-parameter lookup with no output schema and full annotation coverage, the description suffices to call it correctly. A brief note on what the result contains (symbols only vs. pairs with metadata) would close the last 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% with both parameters enum-constrained and documented, including the IRT default. The description restates the quote-currency dimension ('against Toman (IRT) or USDT') but adds no format or validation detail 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 ('List the coins an exchange trades against Toman (IRT) or USDT') with scope narrowed to two quote currencies. This is clearly distinguishable from sibling market-data tools like ic_get_ticker or ic_get_orderbook, which retrieve prices rather than symbol inventories.

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 to use it to 'check a coin symbol before calling the other tools,' which gives an agent a concrete workflow trigger. It does not name the closest alternative (ic_list_exchanges) in the description text, nor state when not to use it, so it falls short of 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 establish a safe, idempotent, open-world read, so the description doesn't need to repeat that. It does add genuinely new behavioral detail: per coin it returns the median Toman price, cheapest and dearest exchange, median 24h change and the number of responding exchanges, which tells the agent this is a cross-exchange aggregate with sampling rather than a single quote. No mention of rate limits, caching or partial-exchange failure behavior.

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

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

Three short sentences: purpose first, then the returned fields, then the sibling routing. Every sentence carries information the agent needs, with no filler or repetition of annotations.

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, and the description compensates by enumerating exactly what each coin's result contains. Combined with the safe-read annotations and a fully documented parameter, an agent has everything needed 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 100% and the coins parameter already documents its max of 10 and default list, so the description adds nothing about the parameter. Baseline 3 is appropriate — the description neither explains nor misrepresents the single optional filter.

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 the key Iranian crypto rates in one call') plus concrete scope: Tether in Toman and major coins aggregated across all exchanges. It explicitly distinguishes itself from ic_compare_price, so an agent can separate the aggregate view from the per-exchange lookup without opening 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?

Gives clear entry-point guidance ('Start here for "what is the dollar/Tether rate" or "how is the market today"') and names one alternative with its selection condition (ic_compare_price for every exchange's price of one coin). It does not address the other siblings such as ic_top_movers, ic_best_deal or ic_list_markets, so the routing is helpful but incomplete.

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 that this is a safe, read-only, idempotent operation, so the description mainly needs to add semantic context. It does so by disclosing newest-first ordering, the OMPFinex exclusion, and that `side` reflects the taker side when reported.

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 definition is short and front-loads the core purpose efficiently. The second sentence is terse and slightly cryptic, especially the fragment 'Order-book exchanges except OMPFinex', but there is 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 market-data retrieval tool with full schema coverage and strong annotations, the description gives enough context to invoke it correctly. It does not describe the shape of returned trade records, but that is a relatively minor gap for this 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 every parameter documented, including enums and defaults. The description does not add much parameter-level meaning beyond the schema, so the baseline score 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 states a specific verb and resource: get the most recent public trades for one coin on one exchange, newest first. It also makes the scope narrow enough to distinguish individual trade prints from sibling market-data tools like orderbook or candles.

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

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

Usage is implied by the precise purpose, and the description adds a coverage constraint: order-book exchanges except OMPFinex. However, it does not explicitly say when to use this instead of ic_get_orderbook, ic_candles, or ic_get_ticker.

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/non-destructive, and the description adds genuinely new behavior: illiquid coins are filtered out, and Tabdeal is exempt from volume filtering because it publishes no volume. That exception is exactly the kind of context annotations can't carry. It doesn't state how 'biggest' is measured (percent vs absolute) or the return 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?

Three sentences, no waste. The scope statement comes first, the filtering caveat second, the drill-down routing last. Every sentence carries information an agent would otherwise have to infer.

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, but the reference to a mover's `coin` field implicitly reveals the response shape and the follow-up path. The remaining gap is that ranking metric (percent change over 24h vs absolute) and sort order aren't stated, which matters for interpreting results.

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 limit, quote, exchange, direction, and min_volume with enums and defaults. The description's filtering sentence adds context for min_volume's default exclusion behavior and the Tabdeal exception, but nothing about quote-market semantics or limit effects 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?

States a specific verb and resource: list the biggest 24h gainers or losers on one exchange. The illiquid-filter caveat sharpens the scope. It doesn't explicitly contrast with ic_market_overview, the closest sibling for market-wide summaries, so it stops short of full differentiation.

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?

Routes the agent forward: pass a mover's `coin` to ic_get_ticker or ic_compare_price for detail, which defines the drill-down workflow clearly. Missing an explicit 'when not to use' (e.g., cross-exchange comparison belongs to ic_market_overview or ic_arbitrage).

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