SiteCheck Crypto & Finance

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses critical behavioral details: that quotes are indicative (not executable), the cost ($0.002 per successful call), the payment mechanism (x402 on Base, Solana or Arc), and that failed calls are not charged. This adds substantial value not captured by annotations.

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 a single dense paragraph that is front-loaded with the core purpose and key caveats. It is efficient but could be slightly more structured (e.g., separate pricing details) for faster scanning.

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

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

Given the presence of an output schema, the description still provides a comprehensive preview of return values (amount out, USD values, gas, price impact, pools/DEXes, which aggregator gives more). It also covers chain support, cost, payment, and failure behavior, leaving no critical gaps for an agent 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 parameter meanings are already well-documented in the schema. The description only reiterates the chain list and confirms tokenIn/tokenOut can be native or contract addresses, adding marginal value beyond the existing schema.

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

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

The description states a specific verb ('Best swap quote') and resource ('for a token pair on an EVM chain'), and explicitly names the compared aggregators (KyberSwap, Velora/ParaSwap). It distinguishes itself from single-DEX routing siblings like sushiswap_route_quotes by virtue of being an aggregator comparison tool.

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 provides clear context: 'Indicative quotes, not executable orders' and lists supported chains. However, it does not explicitly name an alternative tool or state when to use this over a single-DEX quote tool, 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?

Annotations already declare readOnlyHint and openWorldHint, so safety is covered; the description goes beyond them with the payment model ($0.002 USDC per successful call via x402 on Base/Solana/Arc) and the important detail that failed calls are not charged. It does not state rate limits or data freshness/latency, which would be the remaining behavioral gaps.

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 what the tool returns, followed by filtering behavior, scope restriction, and pricing. Every clause carries information an agent needs; nothing is redundant with the name or 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-value detail is unnecessary, and the description covers scope, filtering defaults, and cost. It stops short of handling edge cases such as a symbol with no matching Aave reserve or how the frozen/paused flags interact with a queried symbol.

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 there is only one optional parameter, so the schema already documents 'symbol' with examples. The description restates the default behavior (first 20 reserves) but adds no semantics about unknown symbols or case sensitivity, 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?

Names the specific protocol, version, and market ('Aave v3 Ethereum main-market reserves') and enumerates the exact metrics returned (APY, utilization, LTV, liquidation threshold, caps, frozen/paused flags, liquidity). An agent can distinguish this from crypto_compound_market_stats or crypto_defillama_tvl_oracle immediately.

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?

States the two invocation modes clearly: filter by symbol, or default to the first 20 reserves, plus the hard scope limit 'Ethereum main market only.' It does not name a sibling alternative for other chains or protocols, which keeps it 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 only say readOnly/openWorld; the description adds operationally critical context an agent cannot get elsewhere: pricing ($0.002 USDC per successful call), the payment rail (x402 on Base/Solana/Arc), and that failed calls are not charged. It also discloses the upstream dependency, Ethereum mainnet via Etherscan API V2.

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 resource and keeps cost/payment in a separate second sentence. The field enumeration makes the first sentence long and comma-heavy, but nearly every clause carries informational value about the returned record.

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?

Covers data source, scope, cost, and billing behavior, and an output schema exists so return values need no further explanation. It is still silent on routing relative to the many sibling L2/gas tools and on pagination/recency bounds for 'latest' batches.

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 'batches' parameter is fully documented there (range 1–10, default 5). The description echoes the 'latest batches' notion but adds no format or behavior detail beyond the schema, 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 specific resource (Arbitrum One rollup batch postings to L1) and enumerates the exact fields returned (batch number, L1 block/time, blob vs calldata, poster, gas, fees, totals). An agent can tell this apart from a generic gas tool, though it never names a sibling it overlaps with, such as crypto_ethereum_gas_telemetry or crypto_linea_consensys_rollup.

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?

Use is only implied by the content — an agent infers it is for inspecting Arbitrum batch posting costs and L1 data availability. There is no explicit when-to-use, when-not-to-use, or named alternative among the many rollup/L2/gas 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses important behavior: the tool is paid ($0.002 USDC per successful call via x402 on Base, Solana, or Arc), failed calls are free, and some API-reported liquidity values are implausible and intentionally uncorrected. These are exactly the kinds of cost and data-quality caveats an agent needs before invoking the 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?

The description is compact and front-loaded: it begins with the resource and ordering, then lists fields, then caveats, then pricing. Every clause carries useful information, with no filler or redundant restatement.

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-only, open-world data tool with an output schema, the description is complete. It covers what is returned, the result cap, data-quality caveats, and payment behavior, so an agent has enough context 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 coverage is 100% and the single limit parameter is fully documented in the schema, including its 1-to-20 range and default of 5. The description's mention of 'Top 1 to 20' reinforces the schema but does not add new syntax or selection meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states the resource and scope: Balancer V2 pools ordered by total liquidity in USD, with an explicit list of returned fields and a 1-to-20 cap. It does not explicitly differentiate the tool from adjacent siblings such as generic DEX pool liquidity or Curve pool tools, so it falls short of a 5 despite being clear on its own.

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 a scope and a result limit, but it does not say when to choose this tool over alternatives like crypto_dex_pool_liquidity or finance_curve_finance_pools. An agent is left to infer usage from the resource name rather than from explicit 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?

Adds substantial context beyond readOnlyHint/openWorldHint: data source is public RPC, the hard 5,000-block window, what decoding is applied, what is excluded, and — critically for a paid endpoint — that each successful call costs $0.002 USDC via x402 while failures are free. An agent can budget and predict behavior from this.

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 dense sentences with the resource and scope front-loaded, followed by limits, exclusions, and pricing. Nothing is repeated from the annotations and every clause carries 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?

Output schema exists so return shape needn't be spelled out, annotations cover safety, and the description supplies the remaining gaps: cost model, chain ID, data provenance, lookback ceiling, and decoding behavior. Nothing an agent needs 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 goes further by explaining that the event name comes from a signature database, the topic filter is a signature hash, and the block window maps to roughly 2.8 hours of history. That adds real interpretation value over the bare schema descriptions.

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 — recent event logs for a contract on Base (chain 8453) — plus the exact payload returned (block, time order, tx hash, log index, event name, topics/data, decoded ERC-20/721 Transfer/Approval). An agent knows precisely which resource and which chain this targets, and no sibling in the list covers Basescan contract logs.

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 concrete operating boundaries: look back at most 5,000 blocks (~2.8 h), optional event-signature filter, and an explicit exclusion ('Internal transactions are not included'). It doesn't name an alternative tool or say when a different scanner would be preferred, 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 declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful behavioral context beyond that: data source is the public Berachain RPC, the call costs $0.002 USDC via x402 on Base/Solana/Arc, and failed calls are not charged. It also discloses the important limitation that per-gauge and per-validator splits are omitted. It stops short of covering latency, rate limits, or authentication details beyond payment.

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 dense but front-loaded: it opens with the resource and core metric set, then adds the billing and exclusion details. Every sentence carries useful information, though the long metric list and payment clause make it slightly heavy for a zero-parameter tool.

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 explain return values. For a zero-parameter, read-only telemetry tool, the description is complete enough: it identifies the data source, enumerates the reported metrics, states what is excluded, and discloses the per-call payment model.

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 baseline is 4. There are no parameter semantics to explain, and the description correctly focuses on scope, metrics, and billing rather than inventing parameter guidance.

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

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

The description states a specific verb+resource: it reads Berachain Proof-of-Liquidity telemetry from the public RPC, naming concrete metrics such as BGT supply, latest/safe/finalized blocks, finality lag, gas price, gas used %, and average block time. It is clear about what is not included (per-gauge and per-validator splits), but it does not distinguish itself from sibling telemetry tools such as crypto_ethereum_gas_telemetry.

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 through scope exclusions: the description says per-gauge and per-validator splits are not read or reported, which implicitly tells an agent not to use it for those breakdowns. However, it names no alternative tool and gives no explicit when-to-use or when-not-to-use guidance relative to the many sibling crypto telemetry tools.

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 mark it read-only and open-world, but the description adds valuable context: it is a snapshot (not streaming), depth is computed only from returned levels, max 100 levels per side, and pricing is $0.002 per successful call via x402 with failed calls free. These details go well beyond the annotations.

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 a single dense paragraph with no wasted sentences. It front-loads the core purpose and outputs, then adds scoping and pricing details in a logical order.

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

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

Given the full input schema and the presence of an output schema, the description covers everything an agent needs: what data is returned, the snapshot nature, level limits, and payment mechanics. No critical behavioral gaps remain.

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 fully documented in the schema. The description only reinforces 'one pair' and 'up to 100 levels per side', which adds little beyond the schema's own descriptions; baseline 3 is appropriate 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 states a specific verb (snapshot), resource (Binance spot order book), and concrete outputs (best bid/ask, spread, USD depth, 24h stats). It explicitly scopes to Binance spot and excludes merged multi-exchange books, distinguishing it from aggregated depth siblings.

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 'Snapshot only; Binance market data, not a merged multi-exchange book' clarifies when not to use it, and the overall context implies appropriate use for Binance-specific depth. However, it does not name a specific alternative (e.g., crypto_coingecko_market_depth or crypto_hyperliquid_perps_depth) for merged or non-Binance needs.

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 and openWorldHint, so the bar is lower, yet the description adds genuinely useful operational context: the upstream source (mempool.space) and, critically, the payment model — $0.002 USDC per successful call via x402 on Base/Solana/Arc, with failed calls not charged. That cost/billing disclosure materially affects an agent's decision to call. It does not cover freshness/caching or latency.

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 metric list, and the second sentence carries pricing that cannot be inferred elsewhere. Dense but every clause maps to a returned field or a cost the caller must know; 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, the description need not explain return shapes, and it still pre-summarizes the key metrics, names the data source, clarifies network-wide scope, and discloses pricing. Only the absence of explicit sibling routing keeps it from a 5.

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 and the baseline of 4 applies. The description correctly implies a parameterless, snapshot-style call.

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 enumerates exactly what is returned: hashrate in EH/s with 3-day averages, current difficulty, epoch progress and expected change, plus miner revenue over the last 144 blocks. The 'network-wide figures from mempool.space, not per-miner' clause scopes it clearly. It stops short of naming the sibling it should be chosen over (e.g. crypto_bitcoin_mempool_stats), so it is clear but not sibling-differentiated.

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: an agent can infer this is for Bitcoin network health/miner-economics questions, and the 'not per-miner' note rules out miner-level use. There is no explicit 'use this instead of X when Y' guidance despite several closely related siblings (crypto_bitcoin_mempool_stats, finance_mempool_bitcoin).

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 and open-world behavior, so the bar is lower; the description nonetheless adds material context beyond them: this is a point-in-time snapshot with no historical retention, and the pricing/cost model ($0.002 USDC per successful call via x402, no charge on failure). The payment rails and failure-charging rule are exactly the kind of behavioral detail annotations cannot express.

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 payload metrics are front-loaded in a single dense sentence, followed by the snapshot limitation and pricing as secondary clauses. It is efficient, though the metric enumeration is list-like and slightly crammed.

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?

A rich output schema exists, so return-shape explanation is correctly omitted; the description instead covers scope (snapshot only) and cost. For a parameterless external-data tool, this is nearly complete, with only minor room for clarifying freshness/update cadence of the snapshot.

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; there is nothing for the description to disambiguate beyond what the empty schema already conveys.

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 exact resource (Bitcoin mempool congestion) and its source (mempool.space), then enumerates the specific metrics returned: unconfirmed tx count/size, recommended fee rates in sat/vB, difficulty-adjustment progress and retarget date, and blocks to halving. This is specific enough to separate it from adjacent siblings such as crypto_bitcoin_hashrate_difficulty, which covers mining stats rather than mempool state.

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 'Current snapshot only; no history' tells the agent this is unsuitable for time-series work, which is useful. However, no sibling is named as an alternative for historical fee data, and no conditions (e.g., when congestion matters versus when hashrate/difficulty stats are wanted) are 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?

The description adds substantial behavioral context beyond the annotations: it discloses that each successful call costs $0.002 in USDC via x402 (Base, Solana, or Arc) and that failed calls are not charged. It also explains what is not reported (Gold/DApp points) and provides interpretation for the share price multiplier. These details give the agent a clear picture of cost, payment mechanics, and data boundaries.

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 primary purpose and then adds necessary context about data returned, exclusions, and pricing. It is dense but every sentence contributes useful information, though a slightly more structured format (e.g., bullet points) could improve readability.

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 that the tool has no parameters, a rich output schema, and read-only/open-world annotations, the description covers the essential context: what data is returned, what is omitted, and the payment model. It leaves no significant gaps for an agent to call the 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?

The tool takes no parameters, so the baseline is 4. The description focuses on output semantics rather than input parameters, which is appropriate given the empty 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 returns Blast L2 native yield data for USDB and WETH predeploy contracts, including total supply and share price, plus block and gas metrics. It also explicitly clarifies that Gold/DApp points are not reported, which disambiguates the misleading name. However, it does not name any sibling tool or explicitly state how it differs from other yield or L2 tools, keeping it from 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 implies the tool is for querying Blast L2 native yield metrics, and it clearly notes that Gold points are not available, which serves as an exclusion. It does not, however, specify when to use this tool versus alternatives like crypto_defillama_yields or crypto_ethereum_staking_rewards, leaving usage guidance to inference.

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?

Beyond the readOnly/openWorld annotations it discloses concrete operational traits: per-call price of $0.002 USDC, the x402 payment rails (Base, Solana, Arc), that failed calls are not charged, and — importantly — that heartbeat and deviation thresholds are NOT reported. That last negative disclosure prevents an agent from assuming data the tool does not supply.

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 what is returned, followed by the feed constraint, data limitations, and cost. Every sentence carries distinct information (payload, scope, caveat, billing); nothing is repeated 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?

An output schema exists, so return-value details are covered structurally; the description fills the remaining gaps an agent needs — network, supported feeds, non-reported fields, and payment/billing behavior. Nothing material is missing 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% and the single 'feed' parameter already documents its two valid values and default. The description only restates the supported feeds and adds the chain (mainnet), which is marginal value over 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?

The description names a specific verb+resource (Chainlink on-chain price feed, latest round answer in USD with round id and timestamps) and pins the network (Ethereum mainnet) and supported feeds. It is unambiguous what the tool returns, but it never distinguishes itself from the many oracle/price siblings (crypto_pyth_network_oracles, finance_dia_crypto_oracle, finance_coingecko), so sibling differentiation is left implicit.

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

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

It states a hard constraint ('Only the two feeds listed here are supported') and a default, which bounds usage, but gives no when-to-use/when-not guidance or pointer to an alternative for other assets or non-Chainlink oracle data. Usage is implied by the data list rather than explained.

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 and openWorldHint, yet the description adds genuinely new behavior: pricing ($0.002 in USDC per successful call), the x402 payment rails (Base, Solana, Arc), and that failed calls are not charged. That cost/payment context is material for an agent deciding whether to call. Output semantics are omitted, but an output schema exists, so this is acceptable.

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 what the tool returns, followed by the scope restriction and then the price. Each sentence carries distinct information, though the "Narrowed:" framing is slightly wordier than needed.

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?

All parameters are schema-documented, an output schema exists so return values need no prose, and the description covers the two gaps an agent could otherwise hit: the attestation limitation and the paid-call model. Nothing essential to calling this tool 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% and both parameters (source/destination domain ids with defaults 0 and 6) are already documented in the schema. The description only restates the concept as a "source-to-destination domain pair" without adding format, constraints, or enum-like semantics beyond the schema, so baseline 3 applies.

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

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

The description names a specific resource (Circle CCTP fast-burn allowance and fee tiers) scoped to one source-to-destination domain pair, and explicitly carves out per-transfer attestation. It is clearly distinct from generic bridge-flow or cross-chain siblings, though it never names a sibling tool it is often confused with.

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?

"Narrowed: the attestation status of a specific transfer needs its burn transaction hash, which this tool does not take" is an explicit when-not statement that steers an agent away from a plausible misuse. It stops short of pointing to the tool that does handle per-transfer attestation, so it does not reach 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavioral details: the data is aggregated level-2 only, the source is Coinbase Exchange rather than Advanced, calls cost $0.002 in USDC per successful call via x402 on Base, Solana or Arc, and failed calls are not charged. This adds substantive context an agent needs before invoking a paid data endpoint.

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 resource and scope, followed by the enumerated metrics and payment details. It is dense but every sentence and metric list contributes useful selection or invocation context, 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?

Given the tool has an output schema, the description does not need to explain return values in detail. It sufficiently covers the source venue, product scope, aggregation level, pricing model, and payment behavior, which is complete for an agent to decide whether and how to 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?

The schema already documents the single required parameter at 100% coverage, including examples like BTC-USD and ETH-USD. The description adds only that the order book is for one product, which is implied by the singular required parameter, so the baseline score for high schema coverage is appropriate.

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

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

The description clearly states a specific resource and scope: Coinbase Exchange US spot order book for one product, with named fields such as best bid/ask, spread, USD depth, 24h volume, RFQ volume, and high/low. It also distinguishes the data source from Coinbase Advanced and other venues, though it does not explicitly name the nearest sibling tool for historical orderbook candles.

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

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

It gives clear usage context by specifying that the tool is only for Coinbase Exchange US spot data and not Coinbase Advanced or other venues. However, it does not explicitly route the agent to alternatives for related needs such as historical candles or product metadata.

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 read-only/open-world safety profile, and the description adds substantial operational context beyond them: cost of $0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls not charged, and that data refreshes on CoinGecko's own schedule. The row-level structure clarification (one exchange pair per row) also prevents a common misread of the output.

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

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

Front-loaded with the core purpose and metrics, and every clause adds usable information. It is dense and slightly run-on, packing metrics, row semantics, source cadence and pricing into a few sentences, but 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?

With an output schema present, the description needn't explain return values, and it still covers the row granularity, data source, update cadence and payment/cost model. For a single-param read tool with rich annotations, an agent has everything needed to select and invoke 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% with a single param that already documents the CoinGecko id format with examples (bitcoin, ethereum, solana). The description only restates 'for one coin' and adds no format or edge-case detail, 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+resource (CoinGecko per-exchange market depth for one coin) and enumerates the exact metrics returned: 2% up/down liquidity cost, 24h volume, last price, bid-ask spread over the 15 top-volume pairs. The explicit note that each row is one exchange pair, not a merged order book, cleanly separates it from order-book siblings like crypto_binance_orderbook_depth or crypto_hyperliquid_perps_depth.

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

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

Usage is implied by the metrics described (you'd use it to gauge per-exchange liquidity), but there is no explicit when-to-use/when-not guidance or named alternative among the many overlapping depth/price tools. The agent must infer selection from the data-source and granularity cues rather than being told.

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 readOnlyHint/openWorldHint annotations by disclosing the cost model: $0.002 in USDC per successful call, payable via x402 on Base, Solana or Arc, with failed calls not charged. It also names the data source ('the page's embedded data', 'reads the public page, not the paid API'), which matters for freshness and reliability 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?

A single dense paragraph in which every clause earns its place: field list, scope exclusion, source, and billing terms. Scope and cost information are both front-loaded before an agent commits to a paid call.

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 explained, yet the description still enumerates the fields returned. Combined with the explicit pricing, payment rails, and failure-billing policy, 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?

Only one optional parameter (limit) exists and the schema documents it fully at 100% coverage, including the 1-100 range and default of 10. The description adds nothing about the limit parameter, so the baseline of 3 applies since the schema carries the 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?

States a specific verb and resource ('Recently added tokens on CoinMarketCap') plus the exact field set returned (name, symbol, date added, price, 24h change, 24h volume, market cap). It also carves out scope by naming what is NOT included ('Exchange volume rank is not on this page and is not reported'), which lets an agent distinguish it from broader CoinMarketCap offerings without opening the 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?

Makes clear this is the public new-listings page rather than the paid API, which is the key routing decision against the sibling finance_coinmarketcap entry. It gives clear context for use but does not explicitly name the alternative tool or state exclusions like 'use finance_coinmarketcap for historical or ranked data'.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses a concrete economic behavior — $0.002 USDC per successful call via x402 on Base, Solana or Arc, with failed calls not charged. Pricing and payment-rail details are exactly the kind of behavior an agent must know before invoking.

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: the first front-loads what data is returned, the second covers market selection and cost. Dense but every clause carries information an agent needs; nothing is redundant with the schema or annotations.

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

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

An output schema exists, yet the description still summarizes the payload shape, and it covers market selection, defaults, and payment. Nothing an agent needs to call this correctly or anticipate cost 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 baseline is 3. The description adds value beyond the schema by mapping each market to its Comet contract (cUSDCv3/cWETHv3) and restating the default, though it adds no further syntax or constraint 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?

States a specific verb and resource — on-chain Compound v3 (Comet) market stats on Ethereum — and enumerates the exact fields returned (utilization, supply/borrow APY, totals, collateral assets with factors and caps). This is instantly distinguishable from sibling lending/protocol tools like crypto_aave_lending_markets.

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?

Clear scope: only two markets (usdc/cUSDCv3 or weth/cWETHv3) on Ethereum, with the default stated. It gives strong context for when the tool is applicable, but does not explicitly name an alternative tool or state exclusions for when not to use 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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the payment model: $0.002 in USDC per successful call via x402 on Base, Solana, or Arc, with failed calls uncharged. It also clarifies that votes are Snapshot tallies and that certain wallet-level data is not reported.

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

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

The description is front-loaded with the core resource and returned fields, then adds only useful clarifications about vote tallies, exclusions, and pricing. Every sentence contributes information an agent would need to select and invoke the tool correctly.

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-only tool with an output schema, the description supplies the source, scope, returned fields, exclusions, and payment behavior. Nothing material is missing for correct selection or 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%, and the single limit parameter already documents the 1-to-20 range and default. The description reinforces the 1-to-20 range but adds no format or meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific resource and scope: Convex Finance (cvx.eth) governance on Snapshot, returning the newest proposals with named fields. An agent can distinguish this from general crypto price, pool, or validator tools 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?

The description provides clear context that this tool reports Snapshot governance proposals and explicitly excludes vlCVX lock balances and per-wallet voting power. It does not name a specific alternative sibling tool, but the exclusions meaningfully guide when not to use 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 declare read-only/open-world behavior, but the description adds substantial context beyond them: exact output scope, explicit exclusions, per-call pricing, payment networks, and that failed calls are not charged. No annotation contradiction is present.

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 returned data, then adds the important exclusions and billing behavior. Every sentence carries operational value and there is 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?

Given zero parameters, an output schema, and clear annotations, the definition is complete enough to select and invoke correctly. It also clarifies the main data boundaries and cost model.

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

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

The tool has zero parameters, so there are no parameter semantics to explain and the baseline is 4. The description does not need to compensate for param gaps.

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: CoW Protocol on Ethereum, latest batch auction result. It also enumerates the returned auction/solution fields and says order details and clearing prices are excluded, making the tool's purpose 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?

Usage is clearly implied for fetching the latest batch auction outcome, and the exclusion of order details and clearing prices tells the agent when not to use it. It does not name an explicit alternative for those excluded data needs, so it falls short of a 5.

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

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

Annotations only declare readOnly and openWorld. The description adds material behavior the annotations cannot convey: exact cost ($0.002 USDC per successful call via x402, payable on Base/Solana/Arc), that failed calls are free, and a data-quality caveat that unpriced transfers are counted but excluded from USD sums.

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 what the tool returns, then scope boundary, then data caveat, then pricing. Four dense sentences with no filler; each one adds 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?

An output schema exists, so return-shape explanation is unnecessary. Given a one-parameter, read-only tool, the description covers source, window semantics, aggregation caveat, and cost model — everything an agent needs 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 coverage is 100% and the single 'limit' parameter already documents the 1–100 range and default 50. The description restates the same range without adding format or edge-case guidance, so the schema is doing the work. 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?

Specific verb+resource: cross-chain transfer volume from Wormholescan (Wormhole), grouped by source and destination chain over the newest N transfers. The scope wording clearly separates it from chain-level TVL or trend tools 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 states the usage boundary: 'A recent window, not total bridge TVL or long-term trends,' which steers the agent away from using it for TVL/trend questions. It stops short of naming the exact alternative sibling (e.g., defillama_tvl_oracle), so it isn't a full when/when-not/alternative statement.

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?

Beyond readOnlyHint/openWorldHint, the description discloses freshness ('new rounds appear within days'), a real data-quality caveat ('amounts as DefiLlama lists them and can be missing for undisclosed rounds'), and the cost/payment mechanics ($0.002 USDC per successful call via x402 on Base, Solana or Arc; failed calls not charged). The billing and auth requirement is exactly the context an agent needs before invoking a paid 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 dense sentences: what/where first, filter capability second, data-quality and pricing caveats last. No filler, and the most decision-critical facts (source, cost) are 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 an output schema present and full parameter documentation, the description needn't explain return values, and it still covers source, freshness, gaps and payment. The only residual gap is result ordering/pagination behavior when limit truncates a large window.

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 every parameter already carries defaults, ranges and examples; the baseline is 3. The description adds only indirect meaning (that amounts may be missing, relevant to minAmountUsd), without clarifying filter interaction such as chain/category matching 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 names the exact resource (crypto/Web3 venture funding rounds with project, date, round type, amount, valuation, investors, category, chains) and its source (DefiLlama Raises page), so the agent knows precisely what data comes back. It does not explicitly distinguish itself from adjacent siblings such as finance_pitchbook_investors or finance_sec_form_d, which keeps it below 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?

It lists the filter dimensions available (date window, investor, category, chain, round, minimum amount), which implies how to narrow results, and the schema notes that 'days' is ignored when 'since' is given. However, there is no explicit when-to-use guidance, no statement of when-not to use it, and no named alternative for non-crypto funding data.

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?

Beyond the readOnly/openWorld annotations, the description discloses concrete operational behavior: the paid cost ($0.002 USDC), accepted payment rails (x402 on Base, Solana, or Arc), and the fact that failed calls are not charged. It also bounds the dataset to the public page's top 1–50, which clarifies scope without contradicting annotations.

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 and front-loads the resource and returned fields, then adds scope limits and pricing. Every sentence contributes useful selection or execution context.

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

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

Given the simple one-parameter schema, readOnly/openWorld annotations, and an output schema, the description supplies everything else an agent needs: dataset boundaries, excluded content, and payment/failure semantics. No material calling context 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 limit parameter is already well documented in the schema with its 1–50 range and default of 10. The description reinforces the top 1–50 scope but adds no syntax or behavioral detail beyond the schema, making the baseline 3 appropriate.

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

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

The description names a specific resource — the Rekt News leaderboard of the largest crypto hacks and exploits — and lists the exact fields returned (rank, incident name, audit status, loss, date). It is clear what the tool retrieves, though it does not explicitly differentiate itself from nearby crypto-data siblings such as liquidations or wallet-risk 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?

Usage is clearly implied by the leaderboard framing and strengthened by an explicit exclusion: root-cause write-ups and attack techniques are not included. It does not name an alternative sibling tool, so it stops short of full when-to-use/when-not-to-use routing.

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

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

With readOnlyHint/openWorldHint already declared, the description adds genuinely useful context the annotations cannot: the sampling window (latest 100 fills, not a 24h total), the single-venue limit, and the commercial model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls free). Cost and billing semantics are exactly the kind of behavior an agent needs before invoking.

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 dense sentences, front-loaded with what the tool returns before constraints and pricing. Minor redundancy between 'for one underlying' and 'Covers OKX only', but every sentence still carries distinct 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?

Output schema exists so return-value detail is not needed, and annotations cover the safety profile. The description fills the remaining gaps an agent needs for a paid, venue-limited feed: data window, venue scope, and per-call cost with failure handling.

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 sole parameter 'uly' is already documented with examples, so the schema carries the weight. The description only reinforces that a single underlying is accepted ('for one underlying (e.g. BTC-USD)'), adding marginal meaning beyond the schema.

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

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

States a specific verb+resource: OKX perpetual-swap liquidations for one underlying, with the metric breakdown (long vs short liquidated USD) and the payload (largest events). It is immediately distinguishable from siblings like crypto_binance_orderbook_depth or crypto_hyperliquid_perps_depth, which are depth tools on other venues.

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 explicit boundaries: 'Covers OKX only' and 'the window is the latest 100 events, not a fixed 24h total', plus 'Other exchanges' liquidation streams are not reported'. This tells an agent when not to use it and prevents misreading the result as a 24h aggregate; the only gap is that no alternative tool is named (none exists among the 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?

Beyond the readOnly/openWorld annotations, it discloses the paid-call model ($0.002 USDC per successful call via x402 on Base, Solana or Arc) and that failed calls are not charged, which is critical pre-invocation context. It also warns that 'Small pools can show very high APR', flagging a data-quality pitfall the agent would otherwise misread as signal.

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?

One dense paragraph, front-loaded with the payload fields before caveats and pricing. Every sentence carries information, though the pricing clause is long and could be tightened.

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 only two optional parameters, an output schema present, and safety hints in annotations, the description covers everything an agent needs: scope, defaults, sort/limit behavior, exclusions, data-quality caveat, and the payment requirement.

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, limit) are already documented with defaults and ranges. The description adds the Ethereum default and the 1-50 bound, but that largely restates the schema rather than adding new 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 definition names the exact resource (Curve Finance gauges for a single chain) and enumerates the returned fields — CRV emission APR range, inflation rate per second, working supply, pool name and addresses. It also states the sort order and row cap, and explicitly excludes relative gauge weights and bribe yields, which separates it from the Curve pools sibling tool.

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 clear context (single chain, default Ethereum, sorted by CRV APR, top 1-50) and negative scoping ('Relative gauge weights and bribe yields are not in this source'), which tells an agent when this dataset is the wrong choice. It stops short of naming a concrete alternative sibling such as finance_curve_finance_pools for pool-level data.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the pricing model ($0.002 USDC per successful call via x402 on Base, Solana or Arc, failed calls not charged) and the shape of the aggregation. That pricing/charge semantics is genuinely additive context annotations cannot convey.

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 sentence is front-loaded with purpose and coverage, then return structure, then pricing — every clause carries information. It is long, but nothing is purely redundant; slight trimming of the enumerated position types would help.

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 an output schema exists, the description needn't enumerate return fields, yet it still summarizes the aggregation and debt totals. Combined with disclosed pricing, chain coverage and annotations, 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 both parameters are already documented (address format, limit range). The description reinforces that positions are returned but adds no new syntax or default detail, 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 specific verb+resource ('multi-chain wallet net worth with DeFi positions and debt') plus concrete scope (40+ EVM chains and Solana, Zerion API) and the exact breakdown returned. This clearly distinguishes it from sibling balance tools like crypto_zapper_token_balances or crypto_solscan_account_tokens.

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

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

Usage is implied by the scope (value an address's holdings and DeFi positions), but there is no explicit when-to-use/when-not and no sibling alternative named as a routing alternative. An agent must infer that this is the portfolio-valuation tool versus token-balance 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing per-call cost ($0.002 USDC, x402 on Base/Solana/Arc) and that failed calls are not charged. It also clarifies that net change is supply change, not separate mint/burn events, preempting a misinterpretation of the metric.

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?

Dense but front-loaded with the metrics first, then invocation, then pricing caveat. A few clauses are packed together, yet every part carries information; 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?

Output schema exists so return values needn't be described; with one fully documented parameter, read-only annotations, metric definitions, and payment terms, an agent has everything needed to call 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?

Schema coverage is 100% and the description largely repeats it (comma-separated tickers, up to 10, default 10 largest). It adds a small example (USDT,USDC) but no new semantic depth beyond the schema.

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

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

States specific metrics (circulating market cap, 1/7/30-day circulating change, peg price, depeg %) and the source (DefiLlama), which separates it from siblings like crypto_defillama_tvl_oracle and crypto_defillama_yields. It's a data-retrieval tool, so the absence of a single verb is fine, but it doesn't explicitly contrast against those siblings.

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?

Explains how to invoke: pass symbols or leave empty for the 10 largest. But it never says when to choose this over the TVL or yields DefiLlama tools, nor any conditions favoring it beyond the obvious subject matter.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavioral details: the call costs $0.002 in USDC via x402 on Base, Solana, or Arc, and failed calls are not charged. It also clarifies that only the current TVL number is returned, not a breakdown or history, which is valuable 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?

The description is three tightly written sentences with no wasted text. The core purpose and scope are front-loaded, followed by the return limitation and payment terms, all of which 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?

Given that an output schema exists and annotations already declare read-only/open-world behavior, the description provides everything needed: what is returned, what is excluded, parameter examples, and payment semantics. No critical invocation detail 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 schema has 100% description coverage for the single parameter, so the baseline would be 3. The description adds concrete examples such as 'aave' and 'uniswap-v3', which help the agent understand the expected protocol slug format beyond the schema's generic lowercase/digit/dash constraint.

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-like operation and resource: fetch the current total value locked in USD for one DeFi protocol from DefiLlama. It also scopes the result by noting that only the single current TVL number is returned, with chain breakdown and history excluded, which clearly differentiates it from broader DefiLlama or historical analytics 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 clear usage context by saying this returns only the current TVL number and not chain breakdown or history, which implies when it should and should not be used. However, it does not explicitly name alternative sibling tools for chain-level or historical TVL data, so it falls short of full when-to-use/when-not-to-use 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 mark it read-only and open-world. Beyond that, the description discloses the 20-pool result cap, that APY is an estimate rather than a guaranteed return, and the paid-per-successful-call x402 billing model (failed calls free). Those are useful behavioral details an agent cannot get from annotations or schema.

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

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

Three efficiently loaded sentences: data returned first, filters and result cap second, data-quality caveat and pricing third. Every sentence carries distinct information and there is no 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?

With an output schema handling return shape and annotations covering safety, the description is nearly complete: it covers fields returned, filters, result limit, data reliability, and payment. The only minor gap is that pagination or behavior beyond the 20-pool cap is not addressed.

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 each parameter has examples (Ethereum/Base/Arbitrum, USDC/WETH-USDC, aave-v3). The description only restates the filterable fields ('project, chain and symbol') without adding syntax, defaults, or matching behavior beyond the schema, so baseline 3 applies.

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

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

Names the specific resource (DeFi pool APY, TVL, APY change, impermanent-loss estimate) and the source (DefiLlama), so an agent knows exactly what data it returns. It doesn't name or distinguish itself from close siblings like crypto_defillama_tvl_oracle, crypto_defillama_stablecoins, or finance_defirate_yields, leaving overlap implicit.

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 filtering options ('Filter by project, chain and symbol') and the 'up to 20 pools by TVL' cap imply the intended usage, but there is no explicit when-to-use guidance and no alternatives or exclusions mentioned. An agent must infer that this is for yield/TVL lookups rather than, say, stablecoin supply or protocol TVL.

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 flag read-only and open-world, and the description adds substantial context beyond them: the x402 payment requirement, the exact cost per successful call ($0.002 USDC on Base, Solana or Arc), and that failed calls are free. It also discloses the methodological limitation (no per-strike delta calls), which is the kind of constraint an agent must know before selecting it.

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?

Purpose and scope are front-loaded, and the pricing line is separate and easy to scan. The main clause is dense with nested parentheticals defining moneyness, which slows parsing slightly, but no sentence is 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, the description need not explain return values, and it covers everything else an agent needs: scope, defaults, the exact skew definition, the delta-skew caveat, and cost/payment behavior.

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

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

Schema coverage is 100% and both parameters already document format and defaults (30OCT26-style expiry, BTC/ETH), so the schema does the heavy lifting. The description restates the defaults but adds no new parameter syntax or validation detail, so the baseline of 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?

The description names the specific resource (Deribit BTC or ETH options for a single expiry) and the exact metrics returned (ATM mark IV and an IV skew at ±10% moneyness). It even defines the skew formula, so an agent knows precisely what it gets and that no sibling tool covers Deribit options.

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

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

It states the default scope (nearest unexpired expiry, BTC) and explicitly rules out a related but different use case: 'This is a moneyness skew, not a 25-delta skew' because Deribit's summary lacks delta. That is a clear when-not signal, though no alternative tool is named for delta-based skew.

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 readOnly/openWorld annotations: discloses data provenance (DexScreener aggregate rather than raw on-chain reads), an explicit limitation (slippage not computed), and a full payment model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failed calls not charged). An agent cannot get any of this from the schema or annotations.

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 core purpose and metric list, then terse caveats and pricing. Three dense sentences with no filler, though the pricing sentence is long and could be tightened slightly.

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 fields need not be explained, and the description covers provenance, limitations, and cost. Minor gaps remain: behavior when a pool is not indexed or a chain is unsupported, and whether data is real-time or cached, are not stated.

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 both `pool` and `chain` documented including a chain slug example, so the schema carries the parameter burden. The description reinforces the one-pool/one-chain constraint but adds no format or validation detail beyond the schema, making the baseline 3 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 and resource (live pool snapshot from DexScreener) scoped to exactly one pool address on one chain, and names the coverage set (Uniswap, Raydium, Curve and other indexed DEXes). This clearly separates it from sibling tools like crypto_uniswap_v3_ticks, crypto_curve_gauge_weights, and crypto_balancer_v2_pools, which return protocol-specific internals rather than an aggregate pool snapshot.

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 usage context ('for one pool address on one chain') and notes slippage is not computed, which hints at when it is insufficient. But it never explicitly says when to pick this over siblings such as uniswap_v3_ticks or the various quote tools, nor does it state prerequisites (supported chain slugs, pool must exist).

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 and openWorld, so the bar is lower, and the description still adds real operational context: the data source is the indexer (not on-chain), calls cost $0.002 USDC via x402 on Base/Solana/Arc, and failures are not charged. That pricing/auth-adjacent detail is exactly the kind of thing an agent can't get from the schema. It stops short of describing behavior on an invalid or missing 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?

Front-loaded with the resource and its returned fields, then the data-source caveat, then the cost. Every clause carries information, though the metric enumeration is long enough to read as an inventory rather than a summary.

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 needn't be explained, and the description covers source and cost well. However it doesn't address the conspicuous gap that 'ticker' is listed as optional (0 required params) while the description insists the tool is 'for one ticker' — an agent gets no signal on what happens if ticker is omitted or invalid.

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 example tickers (BTC-USD, ETH-USD) are already in the schema, so the description adds nothing new about the parameter format. Saying 'for one ticker' reinforces single-market scope but is not new semantic depth. Baseline 3 is right when the schema carries 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?

States a specific verb-and-resource: it returns the dYdX v4 perp market for a single ticker, and enumerates exactly which fields come back (status, oracle price, 24h change, volume, trade count, funding, margins, open interest). The 'dYdX v4 (Cosmos app-chain)' qualifier separates it cleanly from sibling perp/venue tools like crypto_hyperliquid_perps_depth or crypto_binance_orderbook_depth.

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?

'Indexer data only' and 'perpetual market for one ticker' imply the use case (single-market snapshot from indexer rather than an order book or exchange API), so usage is inferable. But it never says when to pick it over the many other perp/price siblings, nor any exclusions or prerequisites. Guidance is implied, not 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?

Beyond the readOnly/openWorld annotations, it discloses the commercial model ($0.002 in USDC per successful call via x402 on Base, Solana or Arc) and that failed calls are not charged — critical for an agent deciding whether to retry. It also pre-empts a false expectation by stating that per-contract gas used is unavailable from this RPC.

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 returned payload, then the limitation, then the price. Nothing is redundant and the most decision-relevant facts (output content, cost) lead.

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-value explanation is optional, and the annotations plus pricing/limitation notes cover the behavioral side well. The only shortfall is the absence of explicit routing guidance against the many sibling crypto data tools, which is minor for a read-only telemetry endpoint.

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 blockCount is fully documented in the schema (100% coverage), so the baseline is 3. The description only indirectly hints at the window via 'recent block' and 'next block's base fee' and adds no format or bounds detail beyond the schema.

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

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

The description names the exact resource (Ethereum EIP-1559 gas per recent block) and enumerates the returned quantities: base fee in gwei, gas used ratio, priority-fee percentiles at 10/50/90 from eth_feeHistory, and the next block's base fee. That level of specificity clearly separates it from neighbouring block-level tools such as crypto_mev_block_analytics or crypto_ethereum_staking_rewards.

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

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

It states a data boundary ('Gas used by contract is not included'), which implicitly tells the agent this is not a per-contract gas consumption tool, but it never says when to prefer it over a sibling or what questions it answers best. Usage is implied by the content rather than declared.

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

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

Adds significant value beyond annotations: discloses cost ($0.002 USDC per successful call), payment method (x402 on Base, Solana, or Arc), and that failed calls are not charged. Also clarifies excluded data. Does not cover rate limits or response format, but output schema exists.

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 purpose, then exclusions, then pricing. Every sentence adds necessary information without waste.

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 zero parameters, readOnlyHint and openWorldHint annotations, and an output schema, the description is complete enough: it defines the snapshot's contents, what is excluded, and the cost model.

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?

No parameters, so baseline 4 applies. Description provides no additional parameter details because none exist, which 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 resource and scope: Lido stETH APR and beacon chain finalized/justified epochs with finality flag. It distinguishes from broader yield tools by explicitly excluding validator queue and churn, but does not name a sibling alternative.

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 implicit guidance by noting what is not reported (validator queue and churn), but does not explicitly state when to use this tool versus alternatives like crypto_lido_steth_peg or crypto_defillama_yields.

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=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the data comes from the label page's embedded data, individual deposit wallets are not listed, CEX deposit tags are not separated, and the call costs $0.002 in USDC with failed calls not charged.

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 and front-loaded with the core resource and data returned. It packs several useful constraints and pricing details into a single paragraph without excessive repetition, though it is dense.

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-value explanation is not required. The description covers the data source, key exclusions, and payment behavior, which is complete for a read-only, two-parameter tool, though it could more explicitly distinguish its niche from similar crypto data 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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds a little semantic context about filtering by name versus taking top labels by total, but does not provide details beyond what the schema already supplies for name and limit.

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 resource and data type: Etherscan public address-label cloud with entity labels and counts of tagged accounts, transactions and tokens. It clearly conveys retrieval of aggregated label data, though it does not explicitly differentiate itself from related sibling tools such as crypto_sanctioned_crypto_wallets or crypto_token_holder_concentration.

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 usage by saying users can filter by name or take the top labels by total, and it gives useful exclusions about what the tool does not list. However, it does not explicitly state when to use this tool versus sibling alternatives or provide more detailed selection 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?

Goes well beyond the readOnly/openWorld annotations by disclosing update cadence (once daily, so intraday polling is pointless), the upstream source and its attribution request, and the exact billing model ($0.002 USDC per successful call via x402 across Base/Solana/Arc, failures not charged). The cost and rate-of-refresh disclosures are exactly the kind of operational facts 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?

Front-loaded with the resource and its metric, then payload contents, then cadence and commercial terms. No filler sentences, though the attribution request and payment terms are packed into the same block as the data description rather than separated, making it slightly denser than necessary.

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, the description does not need to enumerate return fields and instead spends its space on source, freshness, and cost — the things an agent needs to decide and pay correctly. Nothing material is missing for a single optional-parameter read tool.

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

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

Schema coverage is 100% and the single `days` parameter (8–30, default 30) is fully documented in the schema, so the baseline of 3 applies. The description hints at the lookback need by promising 7-day figures, but never connects that to the `days` parameter or explains what changes when it is raised.

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 exact resource and source (Fear & Greed Index from alternative.me) and enumerates precisely what is returned: today's value and label, 1-day and 7-day deltas, 7-day average, and a momentum label. No sibling in the list provides a sentiment index, so it is unambiguously distinguishable from the price/on-chain/DeFi tools around it.

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

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

Usage is implied by the content (market sentiment reading) rather than stated: there is no 'use this when…' clause, no exclusion of alternatives, and no note on when the index is or isn't an appropriate signal. An agent can infer the purpose but gets no 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuine value with negative scope and payment mechanics: it explicitly excludes trader net exposure, vault APY and GM market composition, and states the $0.002 USDC x402 price across Base/Solana/Arc with failed calls not charged. That said, the billing/cost disclosure is partly commercial rather than behavioral, and it says nothing about data freshness, chain coverage limits, or result size.

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, front-loaded with the resource and its fields, followed by the exclusions and pricing. No filler. The field enumeration is slightly long but each item maps to a real output field and helps an agent judge relevance before paying for a call.

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 return shape need not be described, yet the description still summarizes it usefully for pre-call selection. Combined with the explicit exclusions and pricing, an agent has enough to decide and invoke. The missing piece is any statement of update cadence or how this differs from adjacent vault/pool 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 tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly omits any parameter discussion.

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 (GMX v2 Arbitrum GLV liquidity vaults) and enumerates exactly what each record contains: vault name, vault token address, long/short collateral tokens, listed flag, listing date. It is unambiguous what domain object is being retrieved, though it never states the verb (list/retrieve) and does not contrast itself with sibling pool/yield tools like crypto_balancer_v2_pools or crypto_defillama_yields.

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 on when to reach for this tool versus the many sibling liquidity/yield tools, and no prerequisites are given. The only usage-adjacent information is the cost line, which tells the agent a call is billed but not when a call is warranted.

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 readOnly/openWorld; the description adds substantial context they don't cover: per-call pricing ($0.002 USDC via x402 on Base/Solana/Arc), the fact that failed calls are free, and the caveat that simulation outcomes can drift with pool state. This is exactly the kind of behavioral detail an agent needs before paying for a 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?

The core purpose and output list are front-loaded, and the pricing/EVM caveats follow in order of importance. It is dense but every clause carries information; the output enumeration is slightly long given an output schema exists.

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?

Covers what it does, the chain scope, cost model, and reliability caveats. With an output schema handling return values and a fully documented 2-param schema, nothing material is missing 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 coverage is 100%, with both `address` and `chainId` fully documented including the default of 1 and the 0x+40-hex format. The description adds no further parameter semantics beyond reiterating the EVM-only constraint, so baseline 3 applies.

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

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

States a specific verb+resource ('EVM token honeypot check from honeypot.is') and enumerates the exact outputs (buy/sell simulation, verdict, taxes, risk flags, open-source status, DEX pair liquidity). An agent can immediately distinguish this from siblings like crypto_smart_contract_verify or crypto_token_holder_concentration.

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 scopes the tool to EVM ('no Solana') and warns that simulation results vary with pool state, which frames appropriate use. It stops short of naming which sibling to use instead for non-EVM tokens or for contract-level verification, so no explicit alternative routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description goes further by disclosing the concrete billing model ($0.002 USDC per successful call via x402 on Base/Solana/Arc, failures not charged) and the derived-metric basis ('from the 20 returned levels per side'). Cost-per-call is exactly the kind of behavior an agent needs before deciding to invoke, and it is not expressed anywhere in structured fields. It does not cover freshness/latency or whether levels are truncated, so 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?

Three compact sentences, front-loaded with the resource and scope, then the field inventory, then the commercial terms. Every clause carries information an agent would otherwise have to discover — no filler, no 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 an output schema present the description need not explain return structure, yet it names the key metrics anyway so a caller can judge relevance before spending $0.002. Scope limit, data provenance (20 levels per side), and payment mechanics are all covered for a one-parameter read 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?

There is a single parameter with 100% schema description coverage including inline examples ('BTC, ETH, SOL'), so the schema already carries the semantics. The description adds only the ordinal constraint 'for one coin,' which confirms the parameter is single-valued but adds no syntax or validation detail. 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 states a specific verb and resource — a Hyperliquid L1 perpetual market snapshot for a single coin — and enumerates exactly what comes back (best bid/ask, spread, 1% depth, mark/oracle, hourly funding, OI, 24h volume). That level of enumeration distinguishes it from generic orderbook tools like crypto_binance_orderbook_depth or crypto_coingecko_market_depth without naming them. It stops short of an explicit 'not this sibling' routing statement, so it lands at 4 rather than 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 context is implied by 'perpetual market snapshot for one coin' and the explicit scope exclusion 'public market data only; vault PnL is not included,' which tells the agent not to reach for it for vault analytics (a real sibling concern, e.g. crypto_gmx_v2_glv_vaults). However, there is no explicit when-to-use clause, no mention of when a sibling like finance_hyperliquid_perp_funding or a depth tool is the better pick. Adequate but leaves routing to inference.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses key behavior: it returns a quote only, never a transaction, amounts remain in base units because decimals are not looked up, and the call has a specific paid x402 pricing model with failed calls not charged.

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 dense and front-loaded with the core purpose, then adds the quote-only constraint, base-unit caveat, and pricing. Some return-field detail is redundant because an output schema exists, but the text is generally efficient.

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

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

Given the output schema and annotations, the description covers what an agent needs to select and invoke the tool: chain, aggregator, exact-input quote semantics, base-unit handling, read-only behavior, and the cost model.

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 parameter schema already explains amount, inputMint, outputMint, and slippageBps. The description reinforces base-unit semantics and exact-input behavior but does not add syntax or format details beyond the schema.

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

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

The description states a specific action and resource: a Jupiter aggregator quote on Solana for an exact-input swap. It also scopes it as quote-only with no transaction, which cleanly distinguishes it from execution or non-Solana routing 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?

The description gives clear usage context: Solana, exact-input swap, base-unit amounts, and quote-only behavior. It does not explicitly name alternatives such as the sibling 1inch or SushiSwap quote tools, nor does it state 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?

Adds real context beyond annotations (readOnly, openWorld): per-call cost of $0.002 USDC via x402 with payment chains, failed calls not charged, and the caveat that the two prices may be quoted minutes apart. This is exactly the kind of operational detail annotations can't carry, though it stops short of describing latency or caching.

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 purpose and source, then caveats, then billing. No filler; each clause conveys distinct 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?

Output schema exists, so return values need no prose. Data source, staleness caveat, explicit omissions, and payment terms are all covered, leaving nothing an agent needs missing before calling.

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?

Zero-parameter tool, so per the rubric the baseline is 4. The description appropriately spends no text on parameters and instead uses the space for data-source and cost 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?

States a specific verb+resource (Lido stETH vs ETH peg) plus the exact data source and the fields returned (stETH/ETH price, discount/premium %, total staked, market cap). The explicit exclusions (Curve pool balances, withdrawal queue) carve out scope against adjacent DeFi 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?

Usage context is only implied: it says what the tool reports and what it omits, but never states when an agent should pick this versus a sibling like crypto_curve_gauge_weights or crypto_defillama_tvl_oracle. No exclusions phrased as 'use X instead'.

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?

Well beyond what readOnlyHint/openWorldHint convey: it discloses the upstream source (public Linea RPC), an explicit data limitation (batch/proof IDs are not exposed by the RPC and are not reported), and the payment/failure model ($0.002 USDC per successful call via x402 on Base/Solana/Arc; failed calls are not charged). That pricing and non-billing-on-failure detail is directly decision-relevant.

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 resource and metric list, followed by the limitation and pricing caveats — a sensible order. The metric enumeration is dense in one long sentence but every clause names a distinct returned field, so little 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-value explanation is unnecessary; the description covers source, scope, known blind spot, and cost. Only rate limits or freshness/latency expectations for the RPC data are absent, which is minor for a read-only snapshot 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 zero parameters, so the baseline is 4. The description correctly implies a single unfiltered snapshot and adds no spurious parameter discussion, leaving nothing for the schema to conflict with.

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 verb/resource pair — Linea zkEVM rollup telemetry from the public Linea RPC — and enumerates exactly which values it returns (latest/safe/finalized blocks, finality lag, gas price, base fee, gas used %, average block time). This clearly separates it from generic L2 or gas tools in the sibling list, though it never names an alternative 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?

Usefulness for Linea-specific finality and gas telemetry is implied by the enumerated metrics, but there is no statement of when to prefer this over crypto_arbiscan_l2_rollup, crypto_scroll_l2_zk_proofs, or crypto_ethereum_gas_telemetry. The agent must infer the boundary, which for a zero-parameter tool is a real gap since nothing forces dispatch to this tool specifically.

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?

Beyond the annotations, the description discloses the data provenance (DefiLlama yields) and a full billing model: $0.002 in USDC per successful call via x402 on Base, Solana or Arc, with failed calls uncharged. That payment and cost detail is actionable context an agent cannot get from readOnlyHint/openWorldHint.

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: what is reported, what is excluded, and what it costs. The coverage statement is front-loaded and the exclusion follows immediately, 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 described, and the description covers scope, exclusions, provenance and pricing. The one gap is freshness/update cadence for APY figures, which matters for a rates tool and is left unstated.

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 the baseline is 4; there is nothing for the description to disambiguate. It does not state whether optional filters exist because none do, which is appropriate.

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

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

The description names the exact resources (sUSDS/sDAI savings APY and TVL, DAI/USDS price, depeg %, circulating supply) and their sources (DefiLlama yields, Ethereum). It also pre-empts the mismatch created by the tool name by stating that vault collateralization is not reported, letting an agent separate it from siblings like crypto_lido_steth_peg or crypto_defillama_stablecoins.

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 an explicit negative scope: 'Vault collateralization is not in these sources and is not reported,' which tells the agent when not to call it despite the name. It does not, however, name a specific sibling to use instead for collateralization data, so the agent must still infer the alternative.

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 and openWorldHint, so the safety profile is covered. The description adds real value beyond them: the upstream source (public Mantle RPC), the explicit scope exclusions (treasury AUM and per-blob EigenDA stats not reported), and a pricing model ($0.002 per successful call via x402, failed calls not charged).

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

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

The definition is front-loaded with the resource and data source, then enumerates returned fields, exclusions, and pricing. The field enumeration is dense but each clause conveys distinct content, so waste is minimal; it is slightly long but earns its length.

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 needn't be re-explained, yet the description comprehensively states what is and isn't in scope, the data source, cost, and payment mechanism. Nothing an agent needs to call 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?

Parameter count is zero, so there is nothing parameter-specific to document; baseline is 4. No syntax or format details are needed and none are missing.

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: Mantle Network L2 telemetry from the public Mantle RPC, and enumerates exactly which blocks and metrics are returned (latest/safe/finalized, lags, gas price, base fee, gas used %, average block time). This is unmistakably distinct from sibling RPC/L2 tools like crypto_ethereum_gas_telemetry or crypto_arbiscan_l2_rollup, which target other chains.

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

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

Usage is implied by the detailed list of returned fields, and the description usefully scopes out what is NOT available (treasury AUM, per-blob EigenDA stats). However, there is no explicit when-to-use guidance or named alternative the agent should prefer for adjacent queries.

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 and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the $0.002 x402 payment model, that failed calls are not charged, the Flashbots relay source, and the newest-blocks-only limitation.

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 dataset and returned fields, then covers scope, exclusion, and pricing in short, purposeful sentences. Each sentence contributes information needed to judge fit or cost, with no meaningful wasted text.

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

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

Given the output schema, annotations, and full parameter coverage, the description supplies the missing context an agent needs: source, data fields, newest-block scope, sandwich-volume exclusion, and payment behavior. It is complete enough for correct invocation without over-explaining return values.

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 only one parameter and schema description coverage is 100%; the schema already documents that 'limit' selects the newest delivered blocks, accepts 1 to 50, and defaults to 10. The description repeats the same range and scope without adding syntax, formatting, or selection details 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 names the exact dataset and source—Ethereum MEV-Boost delivered blocks from the Flashbots relay—and enumerates the returned fields: block value, transaction count, gas used vs limit, and builder pubkeys. It also distinguishes the data from sandwich volume, though it lacks an explicit retrieval verb such as 'returns' or 'lists'.

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 provides scope ('newest blocks only') and a clear exclusion ('sandwich volume is not in this source'), which implies when the tool is appropriate. However, it does not explicitly state when to use this tool versus a sibling alternative, nor does it name another tool for older blocks or sandwich data.

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?

Beyond the readOnly/openWorld annotations, the description discloses the result depth (newest 50 transfers only), the exact heuristic behind the wash flag (A→B→A round trips), data gaps (no prices/royalties), and the payment model ($0.002 USDC via x402, failed calls free). These are material behavioral facts an agent cannot get from structured fields.

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: scope and returns first, then the wash heuristic, then the data-absence caveat and cost. No filler, and the most decision-relevant facts (what you get, what you don't, what it costs) are 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?