CoinGraph

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

Without annotations, the description carries the full burden. It does disclose that outputs are 'full v1 objects' plus a difference row with named metrics, and includes a disclaimer that ratings are opinions, not predictions or financial advice. However, it doesn't explicitly state read-only behavior or mention any side effects, though it's implied by the comparative nature.

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 concise sentences: the first front-loads the main purpose and output, the second adds a necessary caveat. No wasted words, and the key information is presented 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?

The description lists the specific metrics included in the difference row and mentions 'full v1 objects', giving a decent sense of the return structure. However, with no output schema and no annotations, it doesn't mention how assets are identified, potential error conditions, or any prerequisites. It's reasonably complete for a simple compare tool but leaves some gaps.

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 0%, so the description must compensate for the 'assets' parameter. It only says 'up to five assets' but doesn't specify the expected format (e.g., ticker symbols, IDs) or that they are strings. The description adds little beyond what the schema already shows (array of strings, min 2 max 5), failing to provide any practical guidance on how to construct the 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 clearly states the tool compares up to five assets side by side and provides a difference row with specific metrics. It distinguishes itself from siblings by emphasizing the comparative output and the difference row, though it doesn't explicitly name alternative tools. The verb 'compare' is implicit in the name and description, and the resource (assets) is clear.

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?

There is no explicit guidance on when to use this tool versus its siblings (e.g., coingraph_evaluate, get_movers). The description implies it's for multi-asset comparison but doesn't state conditions or exclusions. An agent is left to infer use cases from the tool name and description alone.

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?

With no annotations present, the description carries the full disclosure burden and delivers thoroughly: it discloses which fields are not versioned (contract permissions, supply events, development activity), that an empty change list never implies stability, that resolution is none when history is too short, and how baseline drift surfaces in window.baseline_drift_days. This is exactly the edge-case behavior an agent needs and far exceeds typical coverage.

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

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

A single dense paragraph, but every sentence carries load-bearing information: purpose is front-loaded, and each caveat (not_versioned, resolution none, baseline drift, ratings disclaimer) addresses a distinct failure mode. It could be easier to scan with bullets or headers, but there is no redundancy or filler.

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

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

Despite having no output schema and no annotations, the description covers the return shape in detail (before/after pairs, deduction state changes, signals opened/resolved, not_versioned, resolution:none, baseline_drift_days) plus the edge cases that would cause misinterpretation. The only missing element is explicit sibling routing, which is minor given how purpose-specific the text is.

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 already described, so the baseline is 3. The description adds genuine parameter behavior beyond the schema — the since parameter's nearest-earlier-observation baseline and the meaning of window.baseline_drift_days — which helps an agent interpret the window it actually requested.

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?

Opens with a specific verb-plus-resource — 'what changed for an asset since a moment' — and enumerates the exact output fields (rank, price, market cap, volume, turnover, survival score/band, deductions, signals) framed as before/after comparisons. The temporal-diff scope is immediately distinguishable from sibling names like coingraph_get_asset or coingraph_compare, even though it never names them.

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?

No alternative tool is named and no explicit when-to-use vs when-not-to-use guidance is given; usage is implied by the purpose statement. The description does provide clear interpretive context for results (check window.baseline_drift_days, treat resolution:none as missing history), but stops short of routing the agent toward siblings like coingraph_compare.

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?

No annotations are present, so the description carries the transparency burden. It discloses the output shape (ranked candidates, reasons, URL) and important interpretive caveats ('never predictions, never financial advice' and 'Unscored is not Active'). It does not address staleness or the exact meaning of 'today's scored tier', but for a read-like discovery tool it is reasonably transparent.

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: the action and filters are front-loaded, the return value is stated, and the disclaimer earns its place by preventing misuse. Every sentence adds 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 9 optional parameters, no output schema, and no annotations, the description covers the filter space and return type but leaves gaps: how ranking works, what 'reasons' look like, and how this tool relates to the many similar sibling discovery tools. It is sufficient for a basic call but not for confident selection among 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 only 11%, so the description is the main source of parameter meaning. It maps most filter groups to parameters: band, health score range, market cap range, minimum turnover, maximum decline from peak, and minimum 30-day change. However, it omits 'limit' entirely and does not clarify score scale, inclusivity, or defaults, so compensation is strong but incomplete.

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 ('Find') and resource ('today's scored tier'), enumerates the filter dimensions, and names the return payload (ranked candidates with reasons and coin page URL). The semantic note 'Unscored is not Active' adds useful boundary information, though it does not explicitly name sibling tools for 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?

The description implies a discovery/candidate-screening use case, but it does not state when to choose this over siblings like list_coins_by_band, search_coins, or get_comebacks. There is no when/when-not guidance or explicit alternative routing, only the band semantics note.

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?

With no annotations provided, the description carries the full burden, and it does so thoroughly: it discloses the classification outputs (pass/caution/unassessed), warnings with numbers, roll-up values, the side effect of recording the assessment, and the epistemic caveat that ratings are opinions, not predictions or advice. It also clarifies the tool does not make the decision — 'The agent decides'.

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 pack the core purpose, output semantics, side effect, and limitation without redundant filler. The main behavioral content is front-loaded, with the disclaimer placed at the end where it serves as a caveat rather than an obstacle.

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 there is no output schema, the description adequately explains what the agent will receive: per-check statuses against thresholds, numerical warnings, an actionability roll-up, and insufficient-data cases. It also addresses the side effect of recording and the non-advice nature of the output, making it functionally complete for invocation and interpretation.

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 75%, so most parameters already carry meaning through the schema's property descriptions and the intent enum. The tool description adds no parameter-specific semantics beyond what the schema provides, and horizon_days remains the one under-documented parameter at 0% coverage within the description.

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 identifies the verb ('Evaluate') and resource ('an asset before acting'), and details the evaluation dimensions (health, drawdown, volume trend, dilution, volatility, turnover, regime) plus the actionability roll-up. However, it does not explicitly distinguish itself from siblings like coingraph_validate_trade or coingraph_get_signals, so an agent must infer the 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?

The phrase 'before acting' and 'The agent decides' imply the tool is meant to support pre-trade deliberation, and 'Records the assessment' suggests it is for decisions that will be measured later. There is no explicit when-to-use versus alternatives guidance, nor any statement about when not to use 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?

With no annotations, the description carries the full burden, and it delivers: it discloses that groups carry source and as_of, scores carry confidence, missing factors are listed under unassessed, and that ratings are opinions, not predictions or financial advice. This sets appropriate expectations about data provenance and limitations. It doesn't cover auth or rate limits, but those are less critical for a read-only data retrieval tool.

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 serving a distinct purpose: content enumeration, structural conventions, and a disclaimer. The core purpose is front-loaded in the first sentence, with no filler. Every clause adds value.

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?

There is no output schema, so the description must explain the return value, and it does: it lists the major fields/groups and describes metadata conventions (source, as_of, confidence, unassessed). This is enough for an agent to understand what it will receive. It could go further by noting the top-level shape or error behavior, but for a single-param retrieval tool this is largely 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 single parameter `coin` is fully described in the schema (100% coverage), so the description adds no additional parameter-level meaning, which is acceptable. Baseline 3 applies because the schema already explains the coin parameter's resolution behavior.

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 'The full v1 asset object' and enumerates the specific content groups (identity, market, health, risk, venues, market context), making the resource and scope unmistakable. This clearly separates it from narrower siblings like get_survival_rating or get_market_context, even without explicitly naming them.

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?

No guidance is given on when to choose this tool over alternatives. It never mentions sibling tools or conditions like 'if you need only health, use get_survival_rating'. Usage must be inferred solely from the word 'full' in the first sentence, which is not explicit 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?

With no annotations provided, the description carries the full burden, and it does substantial work: it discloses the hourly computation cadence, that reads are never live, the payload envelope (inputs, severity, confidence, first-seen time), the definition of open vs. resolved, and that ratings are opinions, not predictions or financial advice. It omits auth requirements and rate limits, but for a read-only feed tool the disclosed traits meaningfully shape agent 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?

Three sentences, front-loaded with the signal taxonomy and followed by attribute and cadence details; there is no filler. The final disclaimer sentence about opinions and non-advice earns its place given the financial-adjacent domain. It is dense but not bloated for the amount of behavioral and semantic context it conveys.

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 tool with no output schema and no annotations, the description covers the signal kinds, per-signal attributes, open/resolved semantics, and compute cadence, which is largely sufficient for correct invocation. Minor gaps remain: no mention of ordering, pagination, or what the returned structure looks like beyond the per-signal attributes, and there is no explicit statement about whether omitting 'kind' returns all categories.

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 20%, so the description must compensate, and it does: all six 'kind' enum values are enumerated in prose, 'severity' and 'confidence' attributes are explained, and the open-signal definition effectively clarifies the include_resolved parameter. The asset and limit parameters receive little direct explanation, but the per-coin baseline phrasing partially covers asset 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 clearly identifies the resource (signals reflecting changes in CoinGraph's stored state) and enumerates six concrete signal kinds, so an agent understands what this tool returns. The phrasing 'What changed in CoinGraph's stored state' is slightly indirect rather than an explicit 'list/get' verb, and it doesn't name sibling tools to differentiate itself. However, the content is specific enough that it is plainly distinct from coingraph_compare, coingraph_diff, and coingraph_evaluate.

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 context is implied: the description states signals are 'computed hourly from stored rows, never a live read,' which hints an agent should use this for state-derived signals rather than live data, and 'an open signal is one whose condition still holds' implies how to use include_resolved. But there is no explicit statement of when to use this tool versus alternatives like coingraph_diff or coingraph_discover, and no exclusions or conditions are spelled out.

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?

With no annotations provided, the description carries the full behavioral disclosure burden. It reveals a key limitation (slippage is not extrapolated beyond measured depth), clarifies that the verdict reflects the user's policy rather than CoinGraph's own judgment, and includes a disclaimer about ratings being opinions. It does not mention auth, rate limits, or explicit read-only status, but it goes well beyond a minimal description.

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, followed by the metric list, the key slippage caveat, and the policy/disclaimer. At roughly 90 words across four sentences, each sentence contributes meaningful content without unnecessary elaboration.

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 5 parameters, no output schema, and no annotations, the description explains the returned concepts (slippage, depth share, spread, unlocks, flags, health/risk), the policy evaluation mechanism, and the non-extrapolation boundary. This is sufficient for an agent to select and invoke the tool correctly, though explicit output field names are not enumerated.

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 80%, so the baseline is 3. The description reinforces that `policy` is a set of user-supplied thresholds and that `horizon` defines the unlock window, and it ties `size` to the depth-share metric. It does not add substantive semantics for `side` or `asset` beyond what the schema already specifies.

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 performs pre-trade validation for an order of a given size and lists the metrics it evaluates (slippage, depth share, spread, unlocks, contract flags, health/risk). It is specific and distinct from a generic evaluation tool, though it does not explicitly name sibling tools or contrast with them.

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 'pre-trade validation' phrasing implies it should be used before executing a trade, and the description explains how custom policy thresholds are evaluated. However, it provides no explicit when-to-use vs. when-not-to-use guidance, no named alternatives, and no exclusions, leaving the agent to infer the appropriate context.

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?

With no annotations present, the description carries the full burden of behavioral disclosure. It does this well by stating that ratings are opinions derived from disclosed market inputs and are never predictions or financial advice. It also discloses the breadth of the response and its risk-related content, which is useful behavioral context beyond the 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 sentences with no repetition of schema or annotation data. The first sentence is long but packed with a purposeful enumeration of what the profile includes, and the usage and disclaimer sentences each earn their 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?

For a single-parameter tool with no output schema, the description fully covers what the agent can expect: price data, rating breakdown, confidence, risk read, market figures, links, and the opinion/non-advice caveat. Nothing essential is missing for correct selection and invocation.

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

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

Schema description coverage is 100%, so the schema already documents the coin parameter thoroughly. The description adds the idea that this is about 'one coin' and links the parameter to user intent, but it does not need to add more parameter-level detail.

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: it returns what CoinGraph holds on one coin, then enumerates the exact content areas. It clearly separates this from sibling tools like coingraph_compare or get_survival_rating by emphasizing the single-coin, comprehensive nature.

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 guidance: when a person asks what is happening with a coin or whether the project is still going. It does not name alternatives or exclusions, so it misses the 'when not to use' component, but the context is still 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?

With no annotations, the description must disclose behavior itself. It does add context: the selection logic, the liquidity check, and a disclaimer that ratings are opinions, not predictions or financial advice. However, it does not describe output shape, ordering, pagination, or any operational constraints, leaving part of the behavioral burden unmet.

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: the first sentence front-loads the core screening criteria, and the second adds a useful disclaimer. 'The recovery half of the story' is slightly vague but adds interpretive context without bloat.

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 list-returning tool with one self-documenting parameter, the criteria are described sufficiently for basic invocation. However, there is no output schema and no mention of what the returned data contains, and the lack of sibling usage guidance makes the surrounding context incomplete for an agent choosing among many coin-related tools.

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 provides type, default, min, and max for the single limit parameter, but no description text, and schema_description_coverage is 0%. The description does not mention the limit parameter at all, so it fails to compensate for the missing schema description. The name 'limit' and its numeric bounds make its meaning partly inferable, which keeps this above 1.

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 specifies a concrete, verifiable screening criterion: coins down 60%+ from ATH, outrunning Bitcoin over 30 days, with turnover as a liquidity filter. This clearly identifies what the tool returns. It lacks an explicit action verb and does not differentiate from siblings by name, but the criteria are specific enough to separate it from get_movers and get_survival_rating.

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?

There is no guidance about when to use this tool instead of siblings like get_movers, get_survival_rating, or coingraph_evaluate. The phrase 'the recovery half of the story' hints at a complementary role, but it never names an alternative or states a when-to/when-not-to condition.

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?

With no annotations, the description carries the behavioral burden. It is transparent that this is a read-only market snapshot and lists the derived regime calculation. It doesn't mention update frequency or exact formatting, but there is no mutation or hidden side-effect suggested.

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 concise sentences: the first front-loads the returned data in a readable list, and the second gives the intended use. No filler words 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?

For a no-parameter, read-only overview tool, the description fully covers the returned values and the reason to call it. Without an output schema, this enumeration is sufficient for an agent to know what to expect and use it appropriately.

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

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

The tool has zero parameters, so the 0-param baseline of 4 applies. The description makes clear no selection is needed: it returns the market context as a whole. No parameter-level explanation is required.

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 specifies exactly what the tool provides: total crypto market cap with 24-hour change, Bitcoin dominance, BTC 7/30-day moves, distance from peak, and a derived regime. It frames this as the market-level read and explicitly contrasts with putting a single coin in context, distinguishing it clearly 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 gives an explicit use case: 'Use it to put a single coin's move in context.' This clearly signals when to call it. It doesn't name exclusion cases or alternative tools, but the context is strong enough for an agent to select it over coin-specific siblings.

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

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

With no annotations provided, the description carries the full burden and does meaningful disclosure: it specifies the market-cap threshold, stablecoin exclusion, the 7/30-day context, and the market cap field, and explicitly disclaims that a move is a rating. It stops short of describing output shape or ordering, so it is not 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?

Two tight sentences with no filler: the first packs the resource, criteria, and returned context, while the second eliminates a likely misinterpretation about ratings. The wording is efficient and 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-oriented tool with one optional parameter and no output schema, this is nearly complete: it communicates selection criteria, exclusions, and the fields returned. The only material gap is the lack of explicit guidance about how count affects results and how the gainer/loser output is organized.

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 0% and the description never mentions the only parameter, count, leaving its effect on the result implicit. The parameter name and constraints make it inferable, but the description adds no explicit meaning beyond the raw 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 identifies a specific resource (today's largest 24-hour gainers/losers), defines the universe (top 1,000 coins by market cap), applies an exclusion (stablecoins), and clarifies that movers are price facts, not ratings. This clearly differentiates it from sibling tools like coingraph_evaluate or get_survival_rating.

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 use case is implied: call this when you need today's top movers among large-cap coins. However, the description does not explicitly state when to prefer it over siblings such as get_comebacks, get_market_context, or coingraph_compare, nor does it provide exclusion criteria.

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?

With no annotations, the description carries the transparency burden. It discloses output structure (score range, band categories, deduction inputs, citation), and adds critical limitations ('never predictions, never financial advice'). It lacks error-handling or look-up behavior details, but for a simple read tool it provides substantial behavioral context.

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

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

Two sentences with zero redundancy: the first front-loads the tool's output and scope; the second is a crucial disclaimer. Every sentence earns its place, and the structure is immediately 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?

No output schema exists, so the description must explain return values; it does so with concrete details (score range, bands, deductions, citation). For a one-parameter tool, this is sufficient for correct invocation, though it omits failure scenarios or how deductions are structured. Minor gap, but not enough to lower to a 3.

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% and the description adds no extra parameter-level meaning. The description does not clarify how the 'coin' parameter is matched beyond the schema's existing explanation of id/symbol/name resolution. Baseline 3 is appropriate since the schema fully documents the 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+resource ('survival rating alone for one coin') and enumerates exactly what is returned: score, band, deductions, and citation. It differentiates itself from the 'full profile' sibling by emphasizing it is the standalone rating and faster, making its purpose unmistakable.

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 clearly implies when to use this tool ('Faster than the full profile') – i.e., when only the survival rating is needed, not the full coin profile. However, it does not explicitly name the alternative (e.g., get_coin_profile) or state when not to use it, leaving some inference to the agent.

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?

With no annotations, the description carries the behavioral burden and does well: it discloses the daily snapshot cadence, the membership rule for the scored tier, ordering by market cap rank, and that absence from a band means unscored rather than Active. It also adds a disclaimer about CoinGraph ratings being opinions. It omits details like pagination, output fields, or rate limits, but provides meaningful behavior beyond the 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 compact sentences with no filler. The first sentence front-loads the operation, scope, and ordering; the second explains band membership; the third clarifies absence semantics and adds a disclaimer. 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?

For a simple two-parameter list tool, the description covers the core selection and invocation semantics well: what is listed, from what snapshot, in what order, and how band membership is determined. Gaps remain because there is no output schema, so return fields are not described, and the optional limit parameter is never mentioned. These are not fatal, but they keep it from being fully 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?

Schema coverage is only 50%, since limit has no schema description. The description adds useful meaning to the band parameter by explaining how bands are computed and what absence from a band means, which helps interpret enum values like Active. However, it never addresses the limit parameter or explains the substantive differences between Weakening, Distressed, and Dormant, so the compensation is partial.

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

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

Description begins with a specific verb and resource: lists coins by survival band, scoped to today's daily snapshot and ordered by market cap rank. This clearly differentiates it from sibling tools like coingraph_compare, coingraph_diff, and search_coins without needing to open 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?

The description makes the intended use easy to infer: call this when you need the coins currently assigned to a survival band. However, it does not explicitly state when to prefer this over related tools like get_survival_rating or search_coins, nor does it mention any exclusions or alternative conditions.

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?

With no annotations, the description must disclose behavior. It does reveal the return payload (ids and market cap rank) and positions the tool as a resolver. However, it does not mention read-only behavior, result limits, matching behavior for partial queries, or what happens when no coins match.

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

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

Two sentences, no filler. The core function is front-loaded, the return value is stated, and the usage trigger is given. Every sentence contributes.

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 one-parameter search tool with no output schema, the description covers the essential purpose, the output, and the use case. It lacks examples or result-count details, but the integration hint (passing ids to other tools) makes the tool's role clear in the broader sibling toolset.

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%, and the schema already explains the query parameter as 'Name or symbol, at least two characters.' The description restates 'by name or symbol' but adds value by explaining the purpose of the id ('to pass to the other tools'). 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?

States a specific verb ('Find'), a resource ('coins'), and the search criteria ('by name or symbol'). It also specifies the key output ('CoinGecko ids ... with market cap rank'), which clearly distinguishes it from sibling tools that retrieve profiles or market context.

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 guidance: 'Use when a name is ambiguous or you need the id.' This tells the agent when to invoke the tool, though it does not explicitly name alternatives or state when not to use it beyond the implied contrast with other tools.

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