APEX EVM Reads

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

No annotations exist, so the description carries the full burden, and it does well: it discloses cost ($0.001 per call), payment rails (x402 USDC on Arc/Base/Solana, XNT on X1), the two-phase signing flow, and that the read is on-chain/read-only. It omits failure behavior for unsupported symbols and any rate limits, keeping it out of 5 territory.

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 core capability before payment mechanics, and every clause carries information (feed source, cost, rails, flow). It is slightly dense/run-on, but nothing 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?

No output schema exists, yet the description names the returned fields (feed address, round id, age) and fully explains the two-call payment handshake. For a paid, single-purpose read tool this covers everything an agent needs to 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%, so both `payment` and `symbols` are already documented in the schema. The description reinforces the payment flow and the 1-5 ticker limit but adds no new syntactic or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Crypto token price in USD read on chain from Chainlink price feeds on Ethereum') and scopes it with 'up to 5 tickers per call'. It is clearly distinguishable from siblings like fx_rate (fiat) and evm_token_info (metadata).

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

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

Gives an explicit operational flow: call once without `payment` to get terms, sign with your own wallet, call again with `payment`. It also caps input at one-to-five tickers. It does not name alternative price tools or state when-not-to-use, so it falls short of full sibling 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, so the description carries the full burden, and it does well: it discloses pricing ($0.002 per call), accepted payment methods (USDC on Arc/Base/Solana, XNT on X1), the auth/settlement flow, and a behavioral guarantee about reverse-record filtering. It omits failure modes and invalid-input 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?

Three tight sentences, front-loaded with the core purpose before pricing and the call protocol. Every sentence carries information; density is high but nothing is padded.

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

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

With no annotations and no output schema, the description supplies purpose, cost, payment protocol, and a key output constraint. It leaves error handling and exact return shape unspecified, which is a minor gap for this level of complexity.

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 beyond the schema by clarifying the forward-verification guarantee that constrains what the address lookup returns, and by explaining the payment parameter's role in the call sequence (terms vs. settled purchase).

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 (resolve ENS on Ethereum) and covers both directions: .eth name to address and address to primary ENS name. It also carves out a distinct guarantee (forward-verified) that separates it from the generic evm_* 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?

Explicitly describes the two-step payment flow: call once without payment for terms, sign with your wallet, call again with payment. It also notes name-vs-address selection. It stops short of naming sibling tools or stating when another lookup tool is preferable.

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 meaningful traits: per-call cost ($0.001), accepted payment rails (USDC on Arc/Base/Solana or XNT on X1), and a two-step payment handshake requiring the caller's own wallet. It stops short of describing the exact return shape, but the read-only nature is evident from the query 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 tight sentences that are front-loaded with purpose, followed by cost, then invocation flow. Every sentence carries distinct information 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?

Without annotations or an output schema, the description must supply the behavioral context, and it covers cost, payment rails, and the two-call payment pattern. The only gap is that the exact return representation is not spelled out, though the query semantics imply it.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds workflow-level meaning to `payment` that the schema does not: the first call without it returns terms, and the second call with the signed payload completes the purchase. This clarifies why the parameter is present but optional.

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 (ERC20 allowance) and defines exactly what is computed: how much a spender may move from an owner and whether it is unlimited. It also scopes the supported chains, which cleanly separates it from siblings like evm_token_balance or evm_call.

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 procedural guidance for the x402 purchase (call once without `payment`, sign, call again with `payment`), which implies how to use it, but never states when to prefer this over alternatives or any exclusions/limits on repeated calls. Usage is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does much of it: it discloses the cost ($0.005/call), the accepted payment assets and chains, the payment handshake, and the atomicity guarantee (all reads at one block via Multicall3). It omits behavioral edges an agent would want — read-only nature, behavior on invalid addresses, retry/reuse of a signed payment, or rate limits — so it is strong but not complete.

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 well front-loaded: capability and limits come first, then price, then the payment procedure. Every sentence carries information, though the payment-asset enumeration (USDC on Arc/Base/Solana, XNT on X1) is heavy for a description and could be trimmed.

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

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

For a paid, mutating-handshake tool with no annotations and no output schema, the description covers invocation well but never says what comes back — per-address balance mapping, partial failures for bad addresses, or whether the block number is returned. Those gaps matter when output schema is absent, so it is adequate rather than complete.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds real meaning beyond it: the hard 50-address ceiling and the constraint that all addresses share a single token (native coin or one ERC20), which the schema's 'optional ERC20' wording does not convey. It adds nothing extra for chain or payment beyond what the schema already says.

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 (bulk wallet balances), the exact scope (up to 50 wallets, one chain, native coin or one ERC20, one block via Multicall3), and the four supported chains. This clearly differentiates it from the single-address siblings evm_wallet_balance and evm_token_balance without the agent needing to open either schema.

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

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

Gives explicit operational context: use it when you need up to 50 balances at a single block, and a precise two-step payment procedure ('call once without payment for the terms, sign them, call again with payment'). It stops short of naming the single-wallet alternative or stating when not to use the bulk form (e.g. for one address), which keeps it from 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 discloses genuinely non-obvious behavior: a $0.001 per-call x402 charge, accepted payment assets/networks, and the fact that omitting `payment` returns terms rather than block data. It is silent on latency, caching, or failure modes if payment is rejected, so not quite a 5.

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

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

Two sentences, front-loaded with the resource and return payload; the payment mechanics follow. The second sentence is dense (currency/network list plus call sequence) but each clause carries information the 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, the description compensates by listing the returned fields, and it fully specifies the paid-invocation protocol. What remains missing is routing context relative to gas-related siblings like evm_gas_estimate, which an agent would need to choose 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%, so the baseline is 3, but the description adds real context for `payment` — that passing it completes the purchase inside this call — and confirms the default chain is ethereum. That goes beyond restating the schema field 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?

Opens with a specific verb+resource ('Latest block and gas price') and enumerates the returned fields (block number, time/age, gas price, base fee, tx count, chain id), so an agent knows exactly what it gets. It does not explicitly distinguish itself from the overlapping sibling evm_gas_estimate, which is the one gap 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 second sentence gives an explicit call sequence: call once without `payment` to get terms, sign with your own wallet, call again with `payment` to complete the purchase. That is actionable when-to-use guidance for the paid flow. It stops short of naming when to prefer this over evm_gas_estimate or evm_call.

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, so the description carries the full burden, and it delivers: read-only semantics, no signing/sending, pricing ($0.001 per call), payment mechanisms (x402 USDC on Arc/Base/Solana, XNT on X1), and a two-call x402 handshake. This is rich behavioral context an agent cannot infer from 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?

Three dense sentences, front-loaded with the core action and outcome, then payment mechanics. No filler; every clause conveys operational 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, and the description compensates by naming the return (bytes or revert reason). Combined with the payment flow and no-signing disclosure, an agent has everything needed to call correctly across the two-step x402 purchase.

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 meaning beyond the schema by explaining the two-state `payment` parameter – call without it to get terms, call again with the signed payload to complete purchase. It does not add syntax for `to`/`data`/`from`/`chain`, but the payment semantics are the non-obvious part and are well explained.

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: 'Read-only contract call (eth_call)' with named chains, and clearly distinguishes itself from evm_tx by stating 'Nothing is signed or sent.' It also states the return value (bytes or revert reason), which siblings like evm_tx do not.

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?

Explicit two-step payment flow: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`.' This is exactly the when/how guidance an agent needs and is absent from all 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the cost ($0.001 per call), the payment rails (USDC on Arc/Base/Solana, XNT on X1), and the mandatory two-step payment protocol. It omits failure modes, rate limits, and confirmation of read-only-ness, so it falls short of a 5.

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

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

Two sentences, front-loaded with the core question and its answer set, then the payment mechanics. The parenthetical enumerating payment tokens is dense but genuinely necessary for the agent to proceed. No filler sentences, though the payment clause is slightly stacked.

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 and no annotations exist, so the description must stand alone; it names the returned fields (code size, proxy implementation, delegation) and the pricing/payment contract. It never sketches the response shape or units (e.g., whether code size is bytes or whether a non-contract returns zero), leaving a small gap for a fully self-sufficient definition.

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 real meaning beyond the schema by explaining why `payment` is optional and what the no-payment call returns (payment terms), turning a bare 'signed x402 payment' field into an actionable two-phase workflow. It adds a bit less for `chain` and `address`, which the schema already documents.

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 opens with a precise verb+resource question ('Is this address a contract') and enumerates the exact outputs: code size, EIP-1967/ZeppelinOS proxy implementation, and EIP-7702 delegation. It also names the supported chains, which cleanly separates it from siblings like evm_call or evm_token_info that read state rather than inspect bytecode.

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 well-scoped: call it to determine contract-ness or resolve a proxy implementation, and only on the four listed chains. The x402 handshake ('call once without payment for the terms, sign them with your own wallet, call again with payment') tells the agent exactly how to invoke it. It stops short of explicitly contrasting with sibling tools like evm_call, so not 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 must carry the full behavioral load, and it does most of it: no side effects ('Nothing is sent'), required auth/payment (x402, $0.001/call, accepted currencies), and the two-step payment handshake. It omits error/refund behavior if a signed payment is invalid or expired, and any rate or freshness 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?

Front-loaded with the core purpose and safety note in the first two clauses; the payment sentence is information-dense and slightly overloaded with the multi-currency parenthetical, but every 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?

No output schema exists, yet the description enumerates the return values (gas units, gas price, fee, or revert reason) and covers chains, cost, and the payment flow. An agent has everything needed to call this 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%, so every parameter including `payment` is already documented in the schema and the baseline is 3. The description largely restates that surface (chain list, what `payment` is) rather than adding syntax or format detail beyond it.

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 (estimate gas before sending) plus the exact return payload (gas units, gas price, fee, or revert reason) and the supported chains. An agent can distinguish this from siblings like evm_call or evm_tx, which don't price a transaction without broadcasting.

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 'Gas estimate before sending' and 'Nothing is sent' clearly frame the pre-flight/read-only use case, and the payment instructions spell out the exact call sequence (call once without `payment`, sign, call again with `payment`). It does not, however, explicitly contrast itself with siblings such as evm_call or state when a caller should skip an estimate.

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 the material traits: cost ($0.001 per call), payment rails accepted (x402 USDC on Arc/Base/Solana or XNT on X1), and the auth/terms workflow. It omits any note on rate limits, error handling, or how pending vs confirmed nonces are derived, 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?

Two sentences, front-loaded with what the tool returns and followed by cost and payment mechanics. Dense but each clause earns its place; the pricing sentence could arguably be trimmed but is operationally relevant.

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-param read tool with no output schema and no annotations, the description covers purpose, returned values, pricing, and the payment handshake, which is enough to invoke it correctly. Minor gaps remain around default chain confirmation and repeated-call cost implications.

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; however, the description adds real meaning around the `payment` parameter by explaining the call-once-then-sign-then-call-again sequence, which the schema's terse PAYMENT-SIGNATURE note does not convey. Chain and address semantics are left to 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 resource (wallet nonce), enumerates the supported chains, and unpacks what it returns (confirmed count, next nonce, pending transactions). The resource is distinct enough from siblings like evm_balances_bulk or evm_allowance that an agent can route correctly, but no sibling is named, so it stops short of a 5.

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

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

Gives clear procedural context for the two-step x402 flow: call once without `payment` for terms, sign, call again with `payment`. It does not state when to prefer this over a sibling such as evm_tx or how it relates to nonce fields there, so there are no explicit alternatives or exclusions.

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 full burden, and it does substantial work: discloses the $0.001 per-call price, accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), and the two-phase terms-then-payment behavior. It does not cover failure modes, rate limits, or caching of the block read.

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 capability before the pricing and protocol instructions. Every clause earns its place, though the payment/pricing sentence is information-dense and could be split for 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?

With no output schema, the description correctly enumerates the return fields (raw balance, decimals, symbol, token-unit balance, block), and it documents the payment lifecycle and chain options. It stops short of describing error behavior or what the terms payload contains on the first call.

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% (baseline 3), and the description still adds meaning: it explains `payment` as the x402 signed payload that completes the purchase inside the call, and confirms `chain`/`token`/`address` semantics via the scope sentence. The extra payment-protocol context lifts it above baseline.

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

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

States a specific verb+resource with scope: 'ERC20 token balance of any wallet on Ethereum, Base, Arc or BNB Chain', and enumerates the returned fields (raw balance, decimals, symbol, token-unit balance, block). This distinguishes it from evm_wallet_balance (native) and evm_token_info (metadata) without needing to open schemas.

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 call protocol: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`.' That is genuine when/how guidance for the x402 flow, though it never names an alternative sibling or states when to prefer evm_balances_bulk or evm_wallet_balance 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?

With no annotations, the description carries the full burden and does well: it discloses that the call is paid ($0.001 per call), the accepted payment tokens (USDC on Arc/Base/Solana or XNT on X1), and the x402 two-phase handshake needed before a purchase completes. It does not state failure behavior for an invalid token/chain or any rate limits, so it is strong but not exhaustive.

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

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

Two sentences, zero filler. The chain coverage and returned fields are front-loaded ahead of the payment mechanics, so the agent gets the core capability before the operational detail.

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

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

There is no output schema, and the description compensates by naming the returned fields (name, symbol, decimals, total supply) and explaining the payment flow and cost. It leaves error/edge-case behavior unstated, but for a metadata read tool this is nearly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond that by explaining `payment` as part of a two-call negotiation ('call once without `payment` for the terms, sign them... call again with `payment`'), which clarifies the non-obvious control flow around that 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 (token info + total supply) and enumerates exactly what is returned: name, symbol, decimals, total supply. This cleanly separates it from siblings like evm_token_balance (a wallet's balance) and crypto_price (market pricing), so an agent can route 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?

Gives a clear operational sequence: call once without `payment` to obtain terms, sign with your own wallet, then call again with `payment`. That is actionable context most tools lack. It stops short of naming alternatives or stating when not to use this tool (e.g., versus evm_token_balance).

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 provided, the description carries the full burden and does substantial work: it discloses the $0.002 per-call cost, the accepted payment assets (USDC on Arc/Base/Solana, XNT on X1), and the two-call handshake required to complete a purchase. It does not describe error behavior for unknown or pending hashes, which keeps it out of the top band.

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 the core purpose and chain scope before the payment mechanics. Every clause carries information, though the return-field enumeration and the payment sentence together make it longer than the minimum needed for a single-hash lookup.

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 payment-gated, no-output-schema tool this is close to self-sufficient: supported chains, returned fields, price, and the payment handshake are all covered. What remains unstated is failure behavior (invalid hash, transaction not yet mined, insufficient payment), which an agent would need when the call goes wrong.

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 adds real meaning beyond the schema: it explains that omitting `payment` returns terms rather than failing, and that supplying it completes the purchase inside the same call. That turns a cryptic signed-payload parameter into an understandable two-phase contract.

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 ('Transaction status and receipt by hash') and enumerates what comes back: success or revert, from, to, value, contract created, gas used, fee paid, block and time. It also scopes the supported chains, which cleanly separates it from siblings like evm_block, evm_call, and evm_token_info.

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 x402 flow is spelled out explicitly: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`.' That is a genuine when/how-to-use instruction an agent could not infer. It stops short of naming sibling alternatives or stating when not to use this tool (e.g., pending vs mined hashes).

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 does well: it discloses cost ($0.002/call), the accepted payment assets/rails, and that the first un-paid call is a non-error terms handshake. It omits failure modes and any rate limits, but the pricing and payment mechanics are unusually well surfaced.

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 is returned, then payment cost and the invocation sequence. No filler and no redundancy with 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?

With no output schema, the description correctly enumerates the return contents (native balance, USDC/ERC20 balances, nonce, is-contract flag), so an agent knows what it gets back. The payment flow is covered; only edge-case behavior (payment rejection, partial token failures) is 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%, so the schema already documents all four parameters including defaults and the base64 PAYMENT-SIGNATURE payload. The description only restates chain names and the 20-token cap, adding no format or syntax detail beyond the schema — 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 clear verb+resource (wallet balance) and enumerates the exact scope: native coin, chain USDC or up to 20 listed ERC20s, nonce, and contract status across four named chains. This implicitly separates it from evm_token_balance (single token) and evm_balances_bulk (multiple addresses), though it never names a sibling explicitly.

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

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

The two-step x402 flow (call without `payment` for terms, sign, call again with `payment`) is spelled out, which tells the agent how to invoke successfully. However, there is no guidance on when to prefer this tool over evm_token_balance, evm_balances_bulk, or evm_nonce, so alternative-selection 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?

With no annotations, the description carries the full burden and does well: it discloses the on-chain Chainlink source, the $0.001 per-call price, the accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), and that the purchase completes inside the call. It omits failure/expiry behavior for signed payments and any note on oracle staleness or 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?

Front-loaded with what the tool does, then source, then assets, then pricing and the call sequence. The currency enumeration is long but is directly actionable for parameter values, and 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?

There is no output schema and no annotations, so the description must cover behavior, and it covers source, cost, assets, and the payment lifecycle well. The one gap is that it never describes the shape of the returned rate/conversion result, which an agent must discover empirically.

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 would be 3, but the description adds real meaning: the enumerated currency list constrains valid `from`/`to` codes, and 'cross rates from two USD feeds' clarifies that both codes may be non-USD. The `payment` flow explanation also contextualizes when that parameter is required, beyond the schema's field-level note.

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 (currency exchange rate and conversion), names the data source (Chainlink FX feeds on Ethereum), and enumerates the supported assets including metals and cross rates. This clearly separates it from the sibling crypto_price, which covers a different asset class.

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 explicit procedural guidance for the two-step x402 flow: call without `payment` to get terms, sign with your own wallet, call again with `payment`. It never states when to prefer this over crypto_price or sanctions_check, so it is clear context without exclusions.

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 well: it discloses the exact cost ($0.001 per call), the accepted payment assets and chains (USDC on Arc/Base/Solana, XNT on X1), and that signing happens in the caller's own wallet. It omits failure/refund behavior on an unsigned or underpaid call.

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

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

Front-loaded with the return payload, then the pricing/payment mechanics in two compact sentences. No filler, though the parenthetical payment-asset list makes the middle sentence 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?

No output schema exists, and the description compensates by enumerating the returned fields. Combined with zero annotations and full payment semantics, an agent has nearly everything needed; only error/payment-failure handling is unaddressed.

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

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

Schema coverage is 100% (baseline 3), but the description adds real meaning beyond it: the two-step payment handshake explains *how* the unusual `payment` parameter is meant to be used relative to a paymentless call, and it confirms the multi-chain `chain` options.

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

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

States a specific verb+resource: returns owner and metadata for an ERC721 token, enumerating the exact return fields (owner, collection name, symbol, tokenURI). The ERC721/NFT scope cleanly separates it from the fungible-focused sibling evm_token_info.

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 prescribes the call sequence: call once without `payment` to get terms, sign with your own wallet, call again with `payment`. That is strong operational guidance. It never names an alternative tool or a when-not-to-use condition, 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?

No annotations are provided, so the description carries the full burden and does much of it: it discloses the price ($0.001 per call), the x402 payment rail and accepted assets (USDC on Arc/Base/Solana, XNT on X1), and that the purchase completes inside the call when `payment` is supplied. Remaining gaps are failure/refund behavior, rate limits, and what happens if the signature is 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?

Two dense sentences, front-loaded with what the tool verifies and followed by the payment mechanics. The price and asset list parenthetical is slightly cluttered but every clause carries information an agent needs to call it 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?

With no output schema and no annotations, the description must stand alone, and it conveys the verification outputs, supported chains, and the paid two-step handshake. It is nearly complete for a paid verification tool, missing only the precise response shape and error conditions.

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 schema already defines hash, to, min, chain, token and payment. The description adds only the sequencing semantics of `payment` (omit to get terms, include to settle), which is useful but largely a restatement of the schema text. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Payment verification') plus the exact questions answered: did a transaction really pay an address, totals per token, whether a minimum was met, confirmations. It also scopes the supported chains (Ethereum, Base, Arc, BNB), which separates it from generic siblings like evm_tx.

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

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

Gives an explicit operating procedure: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`.' That is clear context on how and when to invoke it. It stops short of naming an alternative sibling (e.g. why not just use evm_tx) or stating 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?

With no annotations, the description carries the full disclosure burden and does well: it names the authoritative data source (Treasury's official OFAC list), the paid model ($0.002 per call over x402), accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), the auth/signing requirement, and a legal scope caveat. It omits return shape, latency, and failure/caching behavior, 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 sentences, front-loaded with what the tool returns, then the scope caveat, then cost and the call flow. Every sentence earns its place, though the pricing/payment sentence is dense enough that it reads as slightly overloaded.

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 must hint at returns, and it does by naming the returned fields (entry, programs, list date, freeze status). Combined with full schema coverage on both parameters and explicit payment/auth behavior, an agent has what it needs to invoke correctly; only error and delay behavior are unaddressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the payment parameter's workflow semantics: that omitting it returns terms and that a signed payload passed back completes the purchase inside the same call. That is real added meaning over 'a signed x402 payment'.

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 (sanctions check) and resource (wallet on any chain), then enumerates exactly what is returned: OFAC SDN listing with entry/programs/list date plus USDC and USDT freeze status. Nothing among the siblings overlaps with this, so an agent can route unambiguously.

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

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

Gives explicit procedural guidance for the two-step x402 flow ('call once without payment for the terms, sign them with your own wallet, call again with payment'), which is precisely when-to-call knowledge. It does not name an alternative tool or state when not to use this one, so it falls short of a full 5.

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