legible-check

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

With no annotations, the description carries the full burden, and it does disclose two valuable non-obvious traits: the data source (CoinGecko) and a per-call cost of 0.001 USDC via x402 on Base, which affects whether an agent should call it at all. It omits error behavior for invalid ids, data freshness/latency, and whether an empty ids list returns anything, which matter for an unannotated 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 tight sentences: what it returns, when to use it, what it costs. The most decision-relevant facts are front-loaded and nothing is padding.

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 2-param read tool with no output schema this covers the essentials, and mentioning 24h change and market cap usefully signals the return shape. However, all params are optional in the schema while the description says "one or more ids", and it never says what happens if ids or vs are omitted, which leaves a real calling ambiguity unresolved.

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 baseline is 3. The description adds illustrative id values (bitcoin, ethereum, solana) and pins the unit to USD, but never explains the `vs` parameter as the override for that currency, leaving its role only implied by the schema example.

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 (crypto/token price in USD with 24h change and market cap) sourced from CoinGecko ids, so an agent knows exactly what data comes back. It does not explicitly distinguish itself from the sibling dex_quote, which is the nearest conceptual neighbour for price-related needs, but the resource itself is unambiguous.

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

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

Gives explicit usage context: "Use it when an agent needs a current price before quoting or sizing a trade." That routes the agent well for the common case. It stops short of exclusions or naming alternatives, so the boundary with dex_quote (spot price vs executable swap quote) is left 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?

No annotations are provided, so the description carries the whole burden, and it does substantial work: it discloses returned data (USD price, liquidity, 24h volume), cross-chain coverage, and the payment/auth model (0.002 USDC per call over x402 on Base). It omits failure modes, staleness/data-freshness, and rate limits.

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 use case, then cost. No filler; each sentence carries distinct information an agent needs.

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

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

With no output schema and no annotations, the description supplies both the return shape and the cost/auth model, which is most of what an agent needs. The remaining gap is explicit differentiation from crypto_price, the closest sibling.

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%, but the only schema text is the uninformative 'Example: USDC'. The description compensates by clarifying that the query accepts a token or a pair, which the schema does not say, adding genuine meaning over the structured field.

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

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

Names a specific verb+resource (DEX quote and liquidity) and enumerates the returned fields: USD price, liquidity, 24h volume, across chains. The phrase 'live pair quotes for a token or pair query' pins down the scope enough that an agent can separate it from a plain spot-price tool like crypto_price 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?

'Use it to compare venues before a swap' gives a concrete usage context with a clear decision point. It never names an alternative such as crypto_price or states when not to use it, so it stops short of full routing guidance.

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

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

There are no annotations, so the description carries the full burden. It does disclose the per-call cost of 0.002 USDC over x402 and the return contents (wei, ETH, block height). It does not mention that the call is read-only, whether it needs a payment wallet or auth setup, or how payment failures behave.

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 return contents. The middle sentence is redundant 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?

There is no output schema, and the description partly compensates by listing the returned fields. Gaps remain: the meaning and defaults of chain, payment prerequisites, and guidance on choosing among the closely related balance siblings.

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 nominally 100%, but the schema descriptions are only examples. The description says "on Base" yet does not explain the optional chain parameter: whether other chains are accepted or what the default is. The description adds little 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 the resource precisely: the native ETH balance on Base for any address, returned in wei and ETH with block height. "Native ETH" implicitly separates it from evm_token_balance and evm_portfolio, but neither sibling is named.

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 it to read a wallet balance" restates the purpose and offers no real guidance. It never says to use evm_token_balance for ERC-20 balances or evm_portfolio for a full holdings view, which is where an agent is most likely to choose wrong.

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

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

With no annotations, the description carries the full burden, and it does useful work: it discloses the payment model ('0.001 USDC per call over x402 on Base'), which an agent must know before invoking, and it lists the returned data fields since there is no output schema. It omits any note on error behavior, rate limits, or freshness/latency guarantees.

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 plus a short pricing line; purpose is front-loaded and nothing is padded. The only wart is the redundant repetition of 'on Base' in the first and last sentences.

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

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

For a zero-required-parameter read tool with no output schema, the description covers what is needed: the data returned, when to call it, and the cost. The one gap is whether the optional 'chain' parameter permits anything other than Base, since the description implies Base-only while the schema suggests a variable chain.

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 baseline is 3. The description's 'on Base' does weakly constrain the chain value, but it adds no syntax, allowed values, or default behavior beyond what the schema's 'Example: base' 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?

States a specific verb-and-resource pairing ('Block number on Base') and enumerates exactly what is returned: block height, timestamp, age, base fee, gas used, transaction count. It does not explicitly differentiate itself from siblings like evm_gas or evm_tx, 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?

The sentence 'Use it when an agent needs the current block number or the chain head' gives a clear, affirmative usage context. It does not name alternatives or when-not-to-use conditions (e.g., 'for gas estimates use evm_gas'), so it stops short of full routing guidance.

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

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

With no annotations, the description carries the burden and does add real behavioral context: it discloses the paid x402 flow (0.003 USDC per call on Base), which is a prerequisite an agent must know before invoking. It also signals conditional output ('ABI when available'), implying unverified/EOA addresses return partial results, though it stops short of describing error or rate-limit behavior.

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

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

Two sentences, both earning their place: the first front-loads what is returned, the second front-loads the pricing constraint. No filler or restatement of the tool name.

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

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

With no output schema, the description properly enumerates the return payload (contract flag, bytecode size, Sourcify status, ABI) and notes the ABI is conditional. It is nearly complete for a one-parameter read tool; only the response shape for non-contracts and failure modes are 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?

Schema coverage is 100% for the single address parameter, so the baseline is 3. The description adds only the chain scoping ('on Base'), which narrows the meaning of the address slightly but adds no format or validation detail beyond the schema's example.

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 ('Contract check and ABI for an address on Base') and enumerates exactly what is determined: contract-ness, bytecode size, Sourcify verification, and ABI. This clearly separates it from siblings like evm_balance or evm_token_info, which report holdings rather than code properties.

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 you call this when you need to know whether an address is a contract or need its ABI. There is no explicit when-to-use/when-not, no mention of alternatives (e.g. evm_decode for ABI-driven decoding), and no guidance for EOA inputs.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the decoded output fields and the per-call x402 price on Base, but it does not clarify read-only guarantees, chain defaults, failure behavior, or limits such as only decoding static arguments. It also advertises a calldata-plus-address input mode that is not represented in the schema.

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

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

The description is three efficient sentences and is front-loaded with the core operation and return values. The use case and price follow in a logical order with no 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?

There is no output schema, so the description correctly explains the return shape: selector, known signatures, and decoded static arguments. However, the input-mode mismatch with the schema and the lack of chain/default behavior details leave meaningful gaps for correct invocation.

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

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

Schema description coverage is high, so the baseline would be 3. However, the description says the tool accepts "raw calldata plus a contract address" while the schema only defines optional hash and chain, and requires hash. This introduces nonexistent parameters and omits useful semantics for chain.

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: "Decode an EVM transaction" and explains the exact return content (selector, known signatures, decoded static arguments). It is clear enough to separate decoding from sibling tools like evm_tx, but it does not explicitly name or contrast any sibling.

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 a clear use case: "Use it to explain what a transaction does before signing or reporting it." That helps an agent decide when this tool is appropriate, but it does not state when not to use it or name alternatives such as evm_tx or evm_receipt.

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

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

With no annotations, the description carries the burden and does well: it discloses the paid, metered nature of the call (0.001 USDC per call over x402 on Base), which is exactly the kind of cost/auth context an agent needs before invoking. What it omits is freshness/caching behavior (is the gas price live or cached?) and whether the payment requires prior setup, which keeps it from a 5.

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

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

Three short sentences: what it returns, when to use it, what it costs. Front-loaded with the payload description and zero filler; each sentence earns its place.

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

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

There is no output schema, so the description properly enumerates the return values (base fee, priority fee, block) and specifies units (gwei). It is complete enough to call correctly; the only real gap is the interaction between the fixed "Base" wording and the `chain` parameter, plus lack of data-freshness guidance.

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% for the single optional `chain` parameter, so the baseline is 3. The description phrase "on Base" implies Base is the supported/default chain, which adds a little meaning over the schema's terse "Example: base", but it never says whether other chains are accepted or what happens if `chain` is omitted.

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 precise resource (gas price on Base, in gwei) and enumerates the returned components: base fee, priority fee, and the block it was read at. This is unmistakably distinct from every sibling (evm_block, evm_balance, evm_tx, etc.), so an agent can select it 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?

"Use it to estimate gas fees before sending a transaction" gives a clear triggering context. There are no explicit exclusions or named alternatives, but no sibling is a plausible substitute for gas estimation, so the guidance is sufficient in practice.

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

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

With no annotations, the description carries full behavioral burden and does disclose the x402 payment requirement and per-call price, which is valuable. However, it omits whether the nonce reflects pending or latest state when the mempool is busy, error behavior for malformed/unused addresses, and whether calls are rate-limited or cached.

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

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

Three short sentences: what it returns, when to use it, and what it costs. The most decision-relevant fact (the returned resource) is front-loaded and nothing is redundant.

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

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

For a simple 2-parameter read tool with no output schema, the description covers purpose, usage trigger, and the otherwise-hidden payment/cost model. The remaining gap — exact return semantics (pending vs latest nonce, failure cases) — is modest but real.

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, making 3 the baseline. The description adds only marginal semantics — 'for any address' and 'on Base' hint that the chain parameter is effectively Base-only, but it does not explain the chain param's accepted values or defaults.

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 the exact resource returned — 'the next transaction nonce for any address' on Base — which goes beyond restating the name by specifying it is the pending/next nonce. The resource is naturally distinct from sibling tools like evm_balance or evm_tx, but no sibling is named, so this lands just short of a 5.

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

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

'Use it to build a transaction without racing the mempool' gives a concrete when-to-use scenario that an agent can pattern-match on. It offers no when-not conditions or alternatives (e.g., use evm_tx_status to check confirmation instead), so it stays at 4.

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

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

With no annotations, the description carries the burden and does well: it names the supported chains, caps token lookups at ten, and discloses the paid x402 model (0.005 USDC per call on Base) — a material behavioral trait agents rarely get. It omits failure behavior for unsupported chains or malformed token addresses, and doesn't explicitly state the operation is read-only.

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, capability first, selection guidance second, pricing last. Nothing is redundant with the schema; every clause adds information.

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

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

No output schema exists, and the description compensates by enumerating what comes back (balance, nonce, token amounts with symbol and decimals). The free-form 'tokens' parameter format and the omitted-chain default are the only remaining gaps for a 3-param 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% so baseline is 3, but the description adds real semantics: which chains the 'chain' param accepts (Base, Polygon, Arbitrum) and that the 'tokens' param takes up to ten ERC20 addresses with symbol/decimals returned. Only the default chain behavior when 'chain' is omitted remains unaddressed.

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 (portfolio snapshot for a wallet) plus exact contents: native balance, nonce, and up to ten ERC20 token balances with symbol and decimals. The 'one call / instead of many calls' framing distinguishes it from siblings evm_balance, evm_nonce, and evm_token_balance.

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 it when an agent needs a full wallet snapshot instead of many calls' gives a clear selection rule and implicitly routes away from the single-purpose siblings. It stops short of naming an explicit exclusion (e.g. use evm_token_balance when you need only one token) or stating what to do for unsupported chains.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the output fields, the chain (Base), and an explicit per-call cost of 0.002 USDC over x402, which is a real behavioral constraint an agent must budget for. It stops short of describing error behavior for hashes that are not yet mined or do not exist.

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

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

Two sentences, no filler, front-loaded with what is returned before the usage hint and the price. Slightly dense enumeration of fields, but every clause earns its place.

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

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

Covers return contents, chain, cost, and a usage cue for a one-parameter read tool with no output schema, which is close to sufficient. The notable remaining gap is the lack of any stated behavior for reverted/pending/not-found hashes and no pointer to the overlapping siblings.

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?

One required parameter at 100% schema coverage, so the schema already documents the hash and even supplies an example. The description adds nothing about the hash beyond what the schema provides; 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 pairing: it returns a transaction receipt on Base with an enumerated set of fields (status, block, gas used, effective gas price, log count, created contract). That is well beyond the name. It does not, however, distinguish itself from the sibling evm_tx_status, which the agent will see alongside 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?

"Use it to confirm a transaction or read its status" gives a usable context, but it is exactly the usage that the sibling evm_tx_status implies, and the description never says when to prefer one over the other or what happens for a pending/unknown hash.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the call runs on Base, resolves raw units/decimals/symbol on-chain, and costs 0.003 USDC via x402, but it omits error behavior, rate limits, and whether non-ERC20 tokens are rejected.

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 short and front-loads the core resource and return details. The sentence 'Use it to read a token balance' is largely redundant, but the pricing sentence earns its place.

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

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

For a simple two-parameter read tool with no output schema and no annotations, the description covers the chain, return fields, and cost. It could be more complete by clarifying parameter types and alternatives, but the essential calling context is present.

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. The description adds that the balance is for an ERC20 token and an address, and that symbol/decimals are resolved, but it does not clarify that the `token` parameter is a contract address rather than a symbol.

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 chain: ERC20 token balance on Base. It is clear what the tool returns, but it does not explicitly distinguish itself from sibling tools such as evm_balance or evm_portfolio.

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 only usage guidance is the tautological 'Use it to read a token balance.' It does not say when to choose this over evm_balance, evm_portfolio, or evm_token_info, nor does it state exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, and it does add valuable non-schema context: the x402 cost of 0.002 USDC per call on Base. It never states the read-only nature explicitly, nor what happens for a non-ERC20 or wrong-chain address, which are the realistic failure modes for this 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?

Two sentences, zero filler, with the returned fields front-loaded and the cost disclosure trailing. Nothing repeats the schema or the tool name.

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

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

For a one-param lookup with no output schema, the field enumeration effectively documents the return shape, and the cost model is disclosed. What's missing is error/edge behavior (non-ERC20 contract, unverified token) rather than anything structural.

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?

Single required parameter at 100% schema coverage, so the schema already documents it, including an example address. The description adds only the constraint that the address must be an ERC20 contract on Base — useful but marginal, matching the baseline 3.

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

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

States a concrete verb/resource pairing ('Token metadata for an ERC20 contract') and enumerates exactly what is returned: name, symbol, decimals, total supply. The chain is pinned to Base, so the agent knows which network's contract to pass. It doesn't explicitly contrast with the sibling evm_token_balance, but 'metadata' vs. 'balance' makes the split reasonably inferable.

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 it before formatting any token amount or price' gives a clear triggering condition tied to a downstream need, which is more than most definitions offer. There is no when-not guidance and no sibling is named as an alternative, 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?

With no annotations, the description carries the full burden and does disclose substantive behavior: the default 5000-block window, newest-first ordering, inclusion of tx hashes, and — critically — that each call costs 0.003 USDC over x402 on Base, which an agent must know before invoking. It does not mention rate limits or what is returned when the window contains no matches.

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, front-loaded with the scope and ordering, followed by the usage cue and cost. Every clause carries information; only the 'incoming' phrasing is wasted because it is unsupported by the 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?

For a 3-parameter paid query tool with no annotations and no output schema, the description does well on scope, cost and ordering, but omits the response shape beyond tx hashes, error/no-result behavior, and the exact semantics of the optional token filter.

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 nominally 100% but the descriptions are only bare examples ('Example: 5000'), so the description adds some real meaning by stating 5000 is a default rather than just a sample. It says nothing about what 'token' filters (a contract address) or whether omitting it returns all tokens, leaving two of three parameters semantically thin.

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 ('ERC20 transfers on Base'), plus scope (last N blocks, default 5000), ordering (newest first) and return content (tx hashes), which separates it from evm_token_balance and evm_tx. The only gap is an internal ambiguity: the schema exposes a 'token' filter while the sentence 'Use it to list incoming token transfers' implies a single direction the schema does not constrain.

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 it to list incoming token transfers' gives an implied use case but names no alternatives (evm_tx, evm_token_balance) and states no when-not conditions. An agent must infer from sibling names which tool wins for outgoing transfers or for a single token contract.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses the chain (Base), the returned field set, and the paid access model (0.002 USDC per call over x402), but says nothing about behavior for a missing/unknown hash, unmined transactions beyond a flag, or retry/error semantics.

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 tightly packed clauses: purpose plus payload, usage, then cost. It is front-loaded correctly, though "Use it to inspect any transaction" borders on redundant with the opening clause.

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

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

With no output schema and no annotations, the description compensates by enumerating the returned fields and the mined/pending distinction, and it flags the per-call cost. The main remaining hole is not-found/error behavior, which an agent calling with arbitrary hashes would benefit from knowing.

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 required parameter with 100% schema coverage, so the schema already establishes the hash input, and the description adds only that it is a Base transaction hash. The schema's 'description' is merely a zero-hash example rather than a format explanation, and the description does not fill that gap (e.g., 32-byte hex).

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 ("Transaction lookup on Base by hash") and enumerates the decoded fields returned plus mined/pending status, so the agent knows exactly what it gets back. It does not distinguish itself from close siblings like evm_tx_status or evm_receipt, which also concern transactions, leaving some ambiguity.

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 it to inspect any transaction" is the only usage guidance and is essentially a restatement of purpose. With evm_tx_status and evm_receipt in the sibling set, the description should say when this full lookup beats a status-only or receipt-only call, but it offers no such 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?

No annotations exist, so the description carries the full burden. It does add genuinely non-schema behavior: the chain is Base and each call costs 0.001 USDC via x402 — valuable cost/venue disclosure. It omits error behavior for unknown hashes, handling of reorgs, and whether 'pending' results are polled or cached.

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, zero padding, with what the tool returns front-loaded before the usage hint and the pricing note. Every clause contributes something an agent can act on.

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

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

With no output schema and no annotations, the description steps in to enumerate the return payload, the chain, and the payment model, which is most of what an agent needs for a single-parameter lookup. Only edge-case behavior (unknown hash, reorg, pending semantics) is left uncovered.

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 there is a single required parameter, so the schema already carries the contract, and the schema's only description is a zero-hash example. The description adds modest meaning by specifying the hash is a transaction hash rather than a block hash, but nothing on format or validation.

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

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

Names a specific verb+resource (transaction status for a given hash), pins the chain (Base), and enumerates the returned fields (status, block number, confirmations, gas used). It stops short of explicitly differentiating itself from close siblings like evm_tx and evm_receipt, which overlap heavily with 'status'.

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 it to check whether a transfer confirmed' gives one concrete scenario, but there is no when-not guidance and no mention of the obvious alternatives (evm_tx for full transaction detail, evm_receipt for logs/events). The agent must infer the boundary itself.

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