True Value Rankings

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the tool is free, the comparison is capped at 2–5 coins, and it surfaces the largest scoring difference as an analytical output, with data sourced from truevaluerankings.com.

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?

Front-loads the decisive fact ("Free.") and packs scope, output content, and the paid alternative into three tight sentences. The source attribution to truevaluerankings.com is marginally expendable but harmless.

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?

An output schema exists, so return values need not be described, and the description still names the compared dimensions. Cost, input constraints, accepted input forms, and the paid alternative are all present — nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100%, and the schema already documents the 2–5 item bounds and ticker-or-name examples. The description's "Accepts tickers or names" restates what the schema says rather than adding format or normalization rules, so this sits at the baseline.

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 ("Compares 2 to 5 cryptocurrencies") and enumerates exactly what is compared: TVR Score, rank, valuation category, and all 8 metric scores side by side, plus the largest scoring difference. This is clearly separable from siblings like get_tvr_score or get_full_breakdown, which operate on one coin.

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 to get_fair_value_verdict when exact Fair Value Gaps and TVR Estimated Values are needed, and discloses that this alternative costs $0.02 per coin — a strong when-to-use signal. It stops short of covering other plausible siblings such as get_full_breakdown or get_top_ranked, so the routing map is 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 declare readOnlyHint=true and destructiveHint=false, and the description aligns, describing a non-mutating rerank. It adds valuable behavioral context beyond annotations: payment required, unpaid calls return an offer with isError, invalid input is refused before payment, and charges nothing on failure. This goes beyond the basic annotation profile.

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

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

The description is well-structured, front-loading the critical 'Paid' flag and purpose, then covering payment details, error behavior, and alternatives. Every sentence earns its place, providing comprehensive information without redundancy.

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

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

With an output schema present, return values are covered. The description explains the tool's scope, payment mechanics, error handling, and free alternatives. An agent has all necessary information to decide when to use this tool and how to invoke it correctly, including payment prerequisites.

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 descriptions for both coins and weights. The description adds extra meaning by specifying that coins can be omitted for all covered coins and that weights follow a specific order with missing entries defaulting to TVR defaults, which is not fully in the schema. This enriches understanding 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 clearly states the tool reranks all TVR-covered coins using custom weights for 8 metrics, applying a non-public score transformation. It distinguishes itself from siblings like get_top_ranked and presets, and mentions the paid nature, leaving no ambiguity about what it does.

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

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

Explicitly states 'Paid' and offers a 'Free alternative: get_top_ranked and the four presets,' giving agents a clear decision rule. It also details payment methods (x402/MPP) and the behavior on unpaid calls, ensuring correct invocation 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?

Annotations only declare it a safe, non-destructive read; the description adds the pricing model ($0.02 per call via x402/MPP), the exact failure mode for an unpaid call (isError with PaymentRequired in structuredContent, no charge), and that unknown coins are refused before payment. The non-idempotent annotation is consistent with a per-call charge, and the description explains why.

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?

Front-loaded with 'Paid.' and the use condition, then progressively more detail, with no filler sentences; every clause (cost, failure mode, refusal, alternative, source) carries decision-relevant information. The pricing sentence is dense but earned.

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 paid, single-parameter read tool this covers everything an agent needs: what it returns, what it deliberately omits, cost and payment mechanics, the unpaid/unknown-coin error paths, and a cheaper sibling. Presence of an output schema makes detailed return-value explanation unnecessary, yet the description still summarizes the payload usefully.

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

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

Schema description coverage is 100% and the schema already documents the single 'coin' parameter with an explicit coin list. The description only restates 'ticker or name' without adding format, casing, or matching behavior beyond the schema, so it sits at the baseline.

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: the fair value verdict for one coin, with named deliverables (Fair Value Gap, TVR Estimated Value, scoring factors) and an explicit exclusion ('No market price or market cap'). It also distinguishes itself from the sibling get_tvr_score, so an agent can separate the two without opening either 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 an explicit triggering condition ('Use when asked whether a cryptocurrency is undervalued, overvalued or fairly priced') and names a free alternative (get_tvr_score) with what that alternative returns, giving the agent a clear decision path. The paid nature and refusal behavior further constrain when this tool is appropriate.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description adds cost information ('Free' versus the $0.02 sibling) and the upstream data source, which are traits annotations cannot express. It does not discuss rate limits, caching, or failure behavior for unknown tickers, so it is strong but not exhaustive.

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 cost qualifier is front-loaded ('Free.'), followed by the payload, the alternative, the input note, and the data source, all in four compact sentences. The closing attribution to truevaluerankings.com is borderline but defensible as provenance; nothing else is wasted.

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

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

An output schema exists, so return values need no prose explanation, yet the description still summarizes the payload at the right level of detail. With rich annotations, a fully documented single parameter, and a clear paid-alternative pointer, an agent has everything needed to select and call this tool correctly.

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

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

Schema description coverage is 100% and the single 'coin' parameter already includes ticker/name examples, so the schema carries the burden. The description's 'Accepts a ticker or a name' restates that flexibility but adds no format, casing, or ambiguity-resolution 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 concrete verb ('Returns') and enumerates the exact payload: all 8 metric scores with weights, TVR Score, rank, valuation category, and a note on how the score is built. It also implicitly separates itself from get_tvr_score by promising the full bundle rather than a single score.

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

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

It explicitly routes the agent to get_fair_value_verdict ($0.02) for the written scoring factors, valuation note, exact Fair Value Gap, and TVR Estimated Value, so the boundary between the two tools is clear. It stops short of stating when-not to use this tool (e.g., for historical or comparison needs covered by other siblings), so it is not a full 5.

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

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description goes well beyond them: payment rails (x402 USDC on Base, MPP USDC.e on Tempo), per-pull pricing, and the fact that nothing is charged while the record still fits in the free slice. Forward-only recording and per-record SHA-256 hashes are also disclosed.

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

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

Front-loaded with 'Free slice, paid full record,' which is exactly the right framing. The pricing/scope material is partially duplicated between the description and the scope enum's schema text, which costs a little efficiency but doesn't obscure anything.

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?

An output schema exists, yet the description still enumerates the record fields (dated record, TVR Score, method version, source label, public reason, SHA-256 hash), so an agent knows what comes back and what billing behavior to expect. Nothing needed for a correct call is missing.

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

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

Schema coverage is 100%, so both parameters are already documented; the description still adds value by clarifying that the 'source' label takes values like baseline vs auto_captured and what the hash represents. Marginal gain over the schema, but real.

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 — the score history of one coin, every recorded change to its 8 metric scores — and pins down the record's composition. It is clearly distinct from get_tvr_score (current score) and get_full_breakdown in the sibling list.

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 describes the two modes: without scope or 'free' returns the last 90 days / 3 records at no cost; 'full' returns the whole record for $0.05 per pull. It doesn't name a sibling tool as an alternative, but the free/paid branch is spelled out with the exact threshold that triggers billing.

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, non-destructive, and closed-world behavior. The description adds some useful context by saying the tool is free and names the data source, while noting that default weights and presets are covered, but it does not add details about rate limits, auth, or return behavior beyond what the output schema provides.

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

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

The description is two sentences, front-loads the cost and core purpose, and lists the covered contents without redundant wording. Every sentence adds 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 zero-parameter explanatory endpoint with rich annotations and an output schema, the description is complete: it states what the methodology covers, that weights and presets are included, and where the data comes from. No additional call details are needed.

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

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

There are zero parameters, so the baseline is 4. The description appropriately does not discuss parameter semantics, and the empty schema is self-explanatory.

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, 'Explains,' and a specific resource, 'how True Value Rankings scores cryptocurrencies.' It also enumerates the scope: the 8 metrics, current default weights, 4 built-in presets, and general scoring approach, which distinguishes it from sibling tools that return scores or rankings.

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

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

The description implies the tool is for understanding the scoring methodology, but it does not explicitly state when to use it versus alternatives such as get_tvr_score, get_custom_ranking, or get_full_breakdown. No exclusions or prerequisites are given.

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?

Goes well beyond the annotations (readOnlyHint/destructiveHint only cover safety), disclosing cost ($0.08/call), payment rails (x402 USDC on Base, MPP USDC.e on Tempo), the unpaid-call behavior (isError with PaymentRequired in structuredContent, nothing charged), and that invalid input is refused before payment. This is exactly the behavioral context an agent needs for a paid call.

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?

Front-loads the key constraint ('Paid.') so cost is known before anything else, then packs output contents, pricing, error behavior, and the free alternative into a handful of dense sentences with no filler.

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

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

With an output schema present, return values need not be explained, and the description instead covers the things the schema can't: payment flow, failure modes, and the cheaper alternative. Nothing an agent needs to invoke this correctly is missing.

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

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

The single 'portfolio' parameter is fully documented in the schema (100% coverage, including the maxItems 50 cap and allocation normalisation), so the schema carries the load. The description adds only indirect context ('allocation-weighted'), which is baseline-appropriate but not extra parameter meaning.

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+resource ('Fundamentals profile of a portfolio') and enumerates exactly what comes back: allocation-weighted scores for the 8 metrics, per-holding TVR Score and valuation category, and the portfolio TVR Score. It also carves out scope ('scores only, no prices'), which separates it from siblings like get_full_breakdown or compare_coins.

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

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

Explicitly names the free alternative (compare_coins) and describes the paid-path mechanics, giving the agent a clear routing signal. It stops short of spelling out the exact condition under which compare_coins is preferable over this paid tool, so the 'when not to use' is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-schema information: the tool is free, the paid boundary sits at get_fair_value_verdict, and results include the TVR Score plus a valuation category but omit exact gaps and estimated values — that tells an agent what it will NOT get back. Pagination and result-format details are left to the output 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?

Front-loads the two things an agent needs to gate on first — cost ("Free") and the ranked-list purpose — then compresses the three ranking modes into one sentence. It is dense but every clause carries information; the only mild cost is a long run-on middle sentence rather than scannable structure.

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 two-parameter read tool with an output schema and full annotations, this covers everything: cost, ranking semantics, what fields are returned, what is deliberately withheld, and the sibling that supplies the withheld data. Nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns an upgrade by defining what each rank_by enum value actually sorts on (fundamental strength vs. positive vs. negative fair value gap direction). That is real semantic meaning beyond the schema's bare enum listing. The count parameter is fully handled by the schema and gets no extra treatment here.

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?

Names a specific verb and resource ("Returns the top N cryptocurrencies") and immediately disambiguates the three ranking modes: tvr_score = fundamental strength, most_undervalued = largest positive fair value gap first, most_overvalued = largest negative gap first. An agent can distinguish this from sibling tools like list_coins or get_custom_ranking 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?

Gives clear context: this is the free tier for ranked lists, and it explicitly routes the agent to get_fair_value_verdict when exact gaps or TVR Estimated Values are needed, including the cost ($0.02 per coin). It does not name exclusions against get_tvr_score (single coin) or list_coins, so the when-not-to-use side is only partially covered.

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, closed-world, non-destructive behavior, so the bar is lower. The description still adds useful context beyond that: cost is free, data provenance is truevaluerankings.com, and it discloses that the payload is a label, not the full valuation. It does not mention rate limits or caching, 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?

Front-loaded with the cost signal, then purpose, then routing to the paid sibling, then provenance — a sensible order with no wasted sentences. The only near-redundancy is the ticker-or-name sentence, which duplicates the input schema.

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

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

An output schema exists, so return values need no explanation, and the description correctly confines itself to what the schema cannot convey: price, data source, and the boundary against get_fair_value_verdict. For a one-parameter read tool this is close to complete; only rate/usage limits are unaddressed.

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 single 'coin' parameter already documents ticker-or-name input with concrete examples (BTC, Bitcoin, ETH, XMR...). The description's 'Accepts a ticker or a name' merely repeats the schema, adding no new meaning. Baseline 3 is correct when the schema carries the load.

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: returns TVR's valuation category (Undervalued, Fair Value, Overvalued) plus the rule behind it for a cryptocurrency. It also explicitly delineates scope against the sibling get_fair_value_verdict by calling this 'label only', so an agent can distinguish the two without opening either 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?

Names the alternative and the condition that selects it: if you need the exact TVR Estimated Value, Fair Value Gap, or reasons, use get_fair_value_verdict. Also signals cost ('Free' vs '$0.02'), which is a real selection factor here. It stops short of an explicit 'use this when you only need the label' instruction, but the routing 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 readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered and the description is not required to restate it. It instead contributes context the annotations cannot: the call is free, data originates from truevaluerankings.com, and there is a concrete rate limit of 100 requests per 15 minutes per IP. What is missing is any statement about failure behavior, e.g. what happens for an unrecognized ticker.

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 cost marker and the return payload, then the sibling routing, then input flexibility and provenance. Every sentence is functional, though the trailing 'TVR evaluates fundamental strength using Sound Value principles' plus the domain callout could be merged or dropped without loss.

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?

An output schema exists, so the description need not spell out return values and correctly spends its words on cost, rate limits, data provenance, accepted input forms, and the alternative for deeper data. For a single-parameter read-only lookup this is sufficient for an agent to invoke correctly on the first attempt.

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 single 'coin' parameter is already documented with ticker and name examples (BTC, Bitcoin, ETH...). The description's line 'Accepts a ticker (BTC) or a name (Bitcoin)' restates that same flexibility rather than adding new meaning such as case sensitivity, partial-name matching, or handling of ambiguous symbols. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific resource (TVR Score) and enumerates exactly what is returned: rank, valuation category, all 8 metric scores with weights, and the date scores last changed. It explicitly delimits itself against a named sibling, get_fair_value_verdict, which owns the estimated value and Fair Value Gap. An agent can tell this tool apart from compare_coins or get_full_breakdown 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?

It clearly frames a summary-score request as this tool's job and routes the agent to get_fair_value_verdict when the exact Estimated Value, Fair Value Gap, or category reasoning is needed, including the price of that call. What it does not do is mention the other plausible alternatives present among siblings, such as get_full_breakdown, get_historical_scores, or get_tvr_estimated_value, so the exclusion set is 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 declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new behavior context: the call is free of charge and the coin set changes over time ('new coins are added regularly'), which warns the agent results are not a static catalog. No mention of list size or ordering, which is the only remaining gap.

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 cost signal and the core action. Slight redundancy in naming 'True Value Rankings' twice (once as the evaluator, once as the data source), but nothing is misleading or padded.

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

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

For a zero-parameter read tool with a full output schema and rich annotations, the description covers what is returned (symbol, name, category), cost, and data freshness. Only freshness granularity and result ordering/size are left unstated, which is minor here.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly signals this is an unfiltered full listing rather than implying hidden filter options.

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?

Clear specific verb+resource: lists all cryptocurrencies evaluated by True Value Rankings, and names the returned fields (symbol, name, category). The word 'all' plus 'currently evaluated' separates it in spirit from ranked/filtered siblings like get_top_ranked and compare_coins, but it never names a sibling 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?

No explicit when-to-use or when-not-to-use guidance. Usage is only implied: it is the natural discovery/entry-point call before get_tvr_score, compare_coins, or get_full_breakdown. The 'Free' prefix hints at cost considerations but does not state that other tools may be metered.

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