Ventis

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered. The description adds value by listing the data fields the caller will get back, which substitutes for the missing output schema, but it says nothing about caching, rate limits, or error behavior for unknown ids.

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 sentence that front-loads the resource and packs the returned fields without waste. Nothing to trim.

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 one-param read tool with full schema coverage and annotations, the description is adequate but thin: it enumerates some fields without indicating whether the response is a flat object, and gives no hint about what to do with an invalid id. Adding a sentence on id format or completeness of the payload would close the 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% and the single parameter is documented as 'CoinGecko id'. The description adds no extra semantics such as accepted id formats (slug vs contract address) or casing, 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 resource ('Fundamentals for one coin') and enumerates the fields returned (categories, homepage, price, ATH, supply), which distinguishes it from siblings like get_price and market_overview. The verb is implicit ('return fundamentals'), keeping it short of a 5.

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 on when to use this versus get_price or market_overview, even though the overlap in price data is obvious. The 'one coin' scoping is the only implicit hint, and no exclusions or preconditions 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds real value with the 0/100 scale interpretation and the daily-granularity of the series, but says nothing about the default range, the 30-day cap, or the data source/refresh cadence.

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 tight sentence with the identifying noun and the scale semantics front-loaded. Zero padding or redundancy.

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

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

For a simple one-parameter read tool with annotations covering safety, the description is adequate but leaves gaps: the days window (default and 30-day maximum) and the shape of the returned history are undocumented, and there is no output schema to fall back on.

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 is one parameter (days, default 7, max 30) with 0% schema description coverage, so the description is the only place semantics could be supplied — yet it never mentions the parameter at all. 'Daily history' faintly implies a day-count window but gives no default, bounds, or units.

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 the specific resource (Crypto Fear & Greed Index) and states what it returns: the 0-100 value with daily history. It is distinguishable from siblings like get_price or global_stats, though it never uses an explicit retrieval verb.

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 on when to use this versus alternatives such as global_stats or market_overview, and no stated preconditions. The only implied usage cue is the mention of 'daily history', which hints at multi-day trend analysis but is never articulated.

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 openWorldHint, so the safety and determinism profile is covered. The description adds the meaningful behavioral detail that results are in USD and include a 24h change window, but says nothing about batch behavior, error handling for invalid ids, or rate limits on the upstream API.

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

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

Two short sentences, front-loaded with the output contract before the identifier convention. No filler and nothing 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?

For a one-parameter read tool with full schema coverage and annotations, this is close to sufficient: the agent knows the input format and exactly what comes back. Minor gaps are how batched ids map to results and what happens with an unknown id.

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 parameter's description already specifies comma-separated CoinGecko ids with an example. The description's example repeats what the schema provides, so it adds no semantics beyond the baseline for fully documented schemas.

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 resource and output: current USD price plus 24h percent change for one or more coins. It is clearly distinguishable in substance from ohlc, market_overview, and coin_profile, though it never names those siblings to make the distinction explicit.

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 identifier-format guidance (CoinGecko slugs like bitcoin, ethereum, solana) but no when-to-use or when-not-to-use guidance, and no routing advice relative to siblings such as ohlc or market_overview. Usage is only implied by the tool's function.

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 openWorldHint, so the safety profile is covered structurally. The description adds the enumerated payload contents, but says nothing about data freshness, caching, or whether figures are real-time or delayed – relevant for a live market-data 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?

A single efficient sentence with the headline metric (total market cap) front-loaded and no filler. It is a noun-phrase fragment rather than a framed statement, which slightly weakens the structure but wastes nothing.

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 convey return contents, and it lists the key metrics an agent needs to decide relevance. Units, value formats, and time-zone/freshness of the 24h change remain unspecified, a minor gap for a zero-parameter 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?

The tool takes no parameters, so per the baseline this scores 4. There is nothing for the description to disambiguate beyond confirming the tool is unfiltered and global in scope.

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 exactly which metrics are returned (total market cap, 24h volume, BTC/ETH dominance, 24h change), so an agent knows what data this yields. It lacks a verb and does not differentiate itself from the sibling market_overview, which appears to overlap in scope.

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 statement of when to use this tool versus market_overview or get_price, and no exclusions or prerequisites. The agent must infer usage purely from the metric list.

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, openWorldHint and idempotentHint, so safety is covered; the description adds the useful detail that the response is a pricing catalog with per-call prices. It does not say whether the list is static, plan-dependent, or empty when nothing is paid, which keeps it below 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 short sentences, the payload description is front-loaded, and the usage cue comes second. No filler or restatement of the title.

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 parameters and no output schema, the description carries the return-shape burden and does list the fields returned, which is adequate. Minor gaps remain: no note on ordering, paging, or behavior when no paid tools exist.

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 no per-argument semantics to explain and the baseline of 4 applies. The description correctly implies no inputs are needed by never referencing any.

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 ('Lists every paid tool') plus the exact fields returned (tier, endpoint, price per call). That immediately separates it from the market-data siblings like get_price and coin_profile, which return market data rather than a catalog.

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?

'Call this to see what upgrading unlocks' gives a clear triggering scenario. It stops short of naming exclusions or an alternative (e.g., a free-tier listing tool), so it is clear context without full routing 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?

The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety and freshness profile is covered. The description adds value by enumerating the returned metrics, but says nothing about ordering stability, pagination, or data latency. That is a fair addition on top of the annotations, not a rich disclosure.

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 front-loaded sentence that names the resource before the returned fields, with no filler. It is economically sized, though slightly thin for a tool with only one parameter and no other suppositions.

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 carries the burden of describing return values, and it does so by listing the four metric families. With one optional, fully-documented parameter and annotations covering safety, what remains missing is minor (ordering, refresh cadence).

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 'limit' parameter is fully documented in the schema with range and default, so the baseline of 3 applies. The description does not mention the limit parameter at all, adding nothing beyond structured data.

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 pair: it returns top coins ranked by market cap, along with the exact fields returned (price, market cap, volume, 24h/7d % change). This clearly distinguishes it from single-asset siblings like coin_profile and get_price, though it doesn't name those siblings 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?

The description never says when to use this tool versus get_price, global_stats, or trending. The agent must infer from the phrase 'top coins ranked by market cap' that this is a bulk market listing, and there is no stated exclusion or condition for choosing it.

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

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

Annotations already cover read-only, open-world, and idempotent behavior. The description adds meaningful output context by specifying USD denomination and the exact returned row structure [timestamp_ms, open, high, low, close], though it still omits granularity or rate-limit 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?

Two compact sentences with no filler. The core resource and return format are front-loaded and easy to scan.

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 read tool with rich annotations, the description covers purpose and return shape adequately. However, it leaves days semantics and when-to-use guidance unstated, which are relevant gaps for correct invocation.

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

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

Schema description coverage is only 50%: id is documented in the schema, but days has no description anywhere. The description does not explain what days controls, such as the time window or candle granularity, so it fails to compensate for the gap.

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

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

The description clearly identifies the resource as OHLC candles in USD and states the returned row shape. It is distinguishable from price-only tools, though it does not explicitly name sibling alternatives.

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 no guidance on when to use OHLC candles versus get_price or other market-data tools, nor any exclusions or prerequisites. Usage is only implied by the resource name.

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 openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: it lists the quote's contents and explicitly warns nothing is executed, preventing an agent from mistaking a quote for a trade. Permissions/pricing-tier details are absent.

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 front-loaded sentence plus a four-word safety clause. Every element earns its place, and the non-execution warning sits at the end where it is most likely to be read as a qualifier.

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, and the description compensates by enumerating the returned fields (received amount, minimum after slippage, price impact, route). For a read-only quote tool with 4 simple flat parameters, an agent has everything needed to select and call it.

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

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

Schema coverage is 75%; 'from', 'to' and 'amount' are well documented in the schema. The description mentions slippage only obliquely via 'minimum after slippage' and never explains the units or bounds of slippage_bps, which is the one parameter the schema leaves undocumented. Baseline 3 for high-coverage schemas applies.

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

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

The description names the resource (swap quote), the venue/aggregator (Jupiter on Solana), and the exact output fields (tokens received, minimum after slippage, price impact, route). A specific verb is implied by 'quote' and reinforced with 'executes nothing'. It does not explicitly contrast with read-only siblings like get_price, so it falls just short of the top mark.

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?

'Quote only; executes nothing' usefully fences the tool off from any execution intent, but there is no guidance on when to prefer it over get_price or a future swap-execution tool, nor any prerequisite/rate-limit context. Usage 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 readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds two useful facts beyond them: results are live/fresh ('right now') and each entry carries a market cap rank. It omits how many coins are returned and whether ordering is by rank or popularity.

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 clause with no waste, front-loading the resource and the recency qualifier. For a zero-parameter read tool this is appropriately sized.

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 parameters, no output schema and full annotation coverage, the description only needs to convey what the call yields. It does that ('coins trending... with market cap rank'), though it could note the result count or that the list is unordered by rank.

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 schema is trivially complete.

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 and scope: coins trending on CoinGecko 'right now'. This separates it from price/data siblings like get_price or market_overview. It does not explicitly contrast itself with those siblings, so it stops short of a 5.

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 only implied by 'right now' – an agent can infer this is for current trending discovery rather than historical or per-coin lookups. No alternatives are named and no when-not-to-use condition is given, despite siblings like market_overview and global_stats covering adjacent questions.

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