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

Annotations already declare readOnlyHint, idempotentHint and non-destructiveness, so safety is covered. The description adds genuinely useful behavior beyond the annotations: a 0.001 USDC x402 micropayment cost per call on Base and a CoinGecko-with-CoinLore-fallback data source. It omits rate limits or failure/payment behavior, keeping it short of a 5.

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

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

Three tight sentences: purpose first, return payload second, cost/source last. Every sentence carries distinct, load-bearing information 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?

For a zero-parameter, read-only tool with no output schema, the description discloses what is returned (prices and gainers/losers), the cost, and the data provenance. That is sufficient to call it correctly, though the exact response shape is only loosely described.

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 the baseline is 4. The description correctly does not invent parameter semantics, and no schema-documented parameters need compensating for.

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 ('Get live cryptocurrency prices and top 24h movers') and enumerates the concrete outputs (BTC, ETH, SOL, gainers/losers). It does not explicitly differentiate itself from crypto-adjacent siblings like get_dex_quotes or get_gas_prices, but the resource is unambiguous.

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 scope (live spot prices plus movers) implies when it is appropriate, but there is no explicit when-to-use guidance or routing to alternatives such as get_dex_quotes. Usage must be inferred from the data it returns.

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, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds genuinely non-obvious context: this is a paid call (0.002 USDC per call via x402 on Base) and it returns a single aggregate route without independent venue comparison, which shapes both cost expectations and result interpretation.

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, each carrying distinct information: what it returns, what it does not do, and what it costs. Nothing is padded and the core action is front-loaded.

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

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

With no output schema, the description does state the return shape (expected output plus route components) and the payment requirement. It leaves unsupported-pair failure behavior and any rate/latency expectations unstated, but covers enough 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 100%, so from/to/chain/amount are already documented with formats and examples. The description adds no parameter-level detail beyond 'supported pair', so the 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 concrete verb+resource: fetch one live ParaSwap aggregate route for a supported token pair, and scopes it with 'no independent venue comparison'. That scope line separates it from a hypothetical multi-venue router, though no sibling tool is named explicitly.

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

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

Usage is implied by 'for a supported pair' and the per-call cost, which helps an agent weigh whether the call is worth making. There is no explicit when-to-use versus siblings like get_crypto_prices, and no stated when-not or prerequisites.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new behavioral facts: a per-call cost of 0.008 USDC via x402 micropayment on Base (an auth/payment requirement) and an explicit data-quality caveat that fees and basis risk are excluded from the spread comparison. This is exactly the kind of context annotations cannot carry.

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

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

Three short sentences, front-loaded with the core capability, then the comparison caveat, then the cost. Every sentence carries distinct, decision-relevant information 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 no output schema, the description should carry return-shape information; it conveys that both current and predicted rates are returned as spreads, which is reasonably complete for a two-optional-param read tool. It stops short of describing per-asset field structure or ordering, so it is strong but not exhaustive.

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 both parameters (asset, min_spread) are already fully documented, including the basis-point unit and the omit-for-all-assets behavior. The description adds context about spreads being 'indicative' and fee-excluded, which mildly informs min_spread, but does not extend parameter meaning beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Get hourly perpetual funding rates') and names the exact data sources (Hyperliquid, dYdX v4), so the agent knows precisely what it returns. It does not explicitly differentiate itself from siblings like get_dex_quotes or scan_yields, which keeps 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?

The mention that 'current and predicted rates are compared as indicative spreads' implies the arbitrage-comparison use case, and the min_spread parameter reinforces it. However, there is no explicit when-to-use statement, no when-not-to-use, and no named alternative tool, so guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds meaningful context the annotations cannot convey: the exact return shape (slow/standard/fast tiers in gwei plus estimated USD cost) and a per-call payment requirement of 0.001 USDC via x402 on Base, which is critical for an agent to budget for.

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, front-loaded with the core capability and followed by the return format and cost. Every clause carries information an agent needs; no filler or restated 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 output schema, the description compensates by describing the return values (tier names, gwei units, USD estimates) and the payment mechanism. For a zero-parameter, read-only tool this covers everything an agent needs to invoke and interpret it correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. Schema coverage is 100% on an empty object, meaning nothing is left ambiguous.

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 clear verb+resource ('Get current gas prices') and enumerates the exact chains and tier structure returned, so the agent knows precisely what comes back. It does not, however, explicitly contrast itself with the nearest sibling get_crypto_prices, so a 4 rather than 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?

The description offers no when-to-use guidance, no conditions for choosing this over get_crypto_prices or get_dex_quotes, and no exclusions. The only usage-relevant signal is the per-call cost, which is a constraint rather than 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely non-redundant behavior: a 0.008 USDC x402 micropayment on Base is required per call, and results may be partial. It does not describe pagination or response shape.

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

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

Three short sentences, tightly front-loaded: capability first, then limitations, then cost. No filler and every clause carries actionable 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 no output schema, the description compensates by naming the returned data (balances, transaction counts) and its partial-coverage nature. It omits any response format or error behavior, but for a simple 2-parameter read tool the description is close to 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 description coverage is 100%, so both parameters are fully documented in the schema and a 3 is the baseline. The description adds little parameter-level detail and even introduces mild ambiguity: the address param says 'Ethereum or Base', while the chain param's examples include arbitrum and polygon.

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 ('Read priced public wallet balances and available transaction counts') and names the data source (Blockscout), which cleanly separates it from siblings like get_crypto_prices, scan_token, and track_whales. The explicit coverage caveats further sharpen the boundary of what this tool returns.

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 gives clear when-not guidance by naming what is unavailable (DeFi positions, PnL, risk score), which steers the agent away for those needs, and discloses the per-call cost as a selection factor. It stops short of naming an alternative sibling tool to use instead, so it falls just short of a 5.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds genuinely new operational context: unavailable metrics return null, and each call costs 0.003 USDC via x402 on Base. That payment requirement is the kind of pre-call constraint an agent must know. Rate limits and failure modes are not covered, keeping 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?

Three tight sentences, front-loaded with what it reads and closled by the cost. Every clause carries actionable information (scope, not-an-audit caveat, null behavior, price, payment rail); nothing is redundant.

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

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

For a two-parameter idempotent read tool with no output schema, the description covers the essential gaps: what is returned, how missing values appear, the limitation of the heuristic, and the payment model. An agent has everything needed to decide and call 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%, so both parameters (chain with its default, token with address-or-symbol format) are fully documented in the schema. The description adds no additional parameter semantics, which is the correct baseline 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?

States a specific verb (Read) and resource (GoPlus ERC-20 security flags plus a risk heuristic), and immediately bounds the claim with 'this is not an audit.' None of the siblings (prices, gas, quotes, whales, yields, funding, wallet profile) overlap, so an agent can route to it unambiguously.

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 'this is not an audit' clause functions as an explicit when-not boundary, and the micropayment cost implies a paid-scan context. It does not name an alternative tool or describe when a scan is warranted versus simply reading on-chain data, so it stops short of 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?

Annotations already cover readOnly/idempotent/openWorld/non-destructive, and the description adds two high-value facts beyond them: a per-call cost of 0.005 USDC via x402 micropayment on Base, and the caveat that APY/TVL are provider-reported with no safety rating. Both materially affect invocation decisions.

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, front-loaded with the resource and scope, then the payment and caveat details. No filler; every clause carries decision-relevant 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 no output schema, the description still tells the agent what comes back (provider-reported APY and TVL), the absence of a safety rating, and that a micropayment is required. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented with examples and defaults. The description's filter mention adds no syntax or format detail beyond the schema, so the 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 ('Scan') and resource ('top DeFi yield opportunities') and enumerates the covered protocols (Aave, Compound, Morpho, Lido, Pendle). This is distinguishable from siblings like get_dex_quotes or get_crypto_prices, which return prices/quotes rather than yield opportunities.

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 names the filter dimensions (chain, asset, min TVL) but never states when to prefer this tool over alternatives such as get_dex_quotes or get_funding_rates, nor any when-not-to-use condition. Usage context is implied rather than explicit.

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

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

Annotations already cover read-only, idempotent, open-world, non-destructive semantics, so the bar is lower. The description adds genuinely new operational context not in any structured field: a 0.005 USDC x402 micropayment on Base, and the crucial data limitation that results are a sample rather than a full holder distribution.

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

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

Three tight sentences, front-loaded with what is returned, followed by limitations and cost. Every sentence carries distinct information with no 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 no output schema, the description does the work of characterizing the return (sampled top holders, supply share) and flags what it deliberately omits, which is what an agent needs to judge fitness. It could say slightly more about the shape or size of the sample, but it is sufficient 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 100% with only two parameters, so the schema fully documents chain and token formats. The description adds no parameter-level detail beyond what the schema already provides, making 3 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: reading a GoPlus sample of top ERC-20 holders plus reported supply share. It is clearly distinct from siblings like scan_token or profile_wallet, though it does not explicitly name any sibling to route against.

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 exclusion clause ('full distribution, Gini, and recent transfer history are unavailable') usefully bounds expectations, and the cost note implies a deliberate-call context. However, it never says when to prefer this over scan_token or profile_wallet for holder analysis.

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