Agent Data Tools: Chain data

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

Adds real context beyond the annotations: freshness (latest block, read live), what is returned (wei and ETH), and the paid-call model ($0.001 USDC on Base via x402, charged per successful call). Note the tension with readOnlyHint=false, though the disclosed per-call payment plausibly explains why the invocation is annotated as non-read-only while the underlying chain access is a pure 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 tight sentences, front-loaded with what is returned and from where, then the usage context and cost. Every clause carries information; nothing is redundant or 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 output schema, the description supplies the return shape (wei and ETH), the chain and freshness semantics, and the payment requirement — everything an agent needs to decide and call correctly. Nothing material is missing for a single-parameter read tool.

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

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

Only one parameter, and the schema already documents it at 100% coverage ('0x wallet or contract address'). The description's 'any address on Arbitrum One' reinforces the accepted input but adds no syntax, validation, or format 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 concrete verb+resource with full scope: native ETH balance of any address on Arbitrum One, returned in wei and ETH, read live at the latest block. This cleanly separates it from siblings like arb_token-balance (ERC-20 vs native) and eth_balance/base_balance (different chains) without needing to open a 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 triggering context: check whether a wallet is funded before sending, paying gas, or settling. It stops short of naming alternatives (e.g., use arb_token-balance when the asset is an ERC-20 rather than native ETH), which would matter given the very large sibling set.

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

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

Annotations only declare the generic profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false); the description adds the material operational fact that each successful call costs $0.001 in USDC on Base via x402, plus the default-to-latest behavior. It does not explain what happens on failure or whether the paid call is charged only on success (it does say 'per successful call'), leaving a small gap.

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 in a deliberate order: what it returns, when to use it, what it costs. No filler, no repetition of the name, and the highest-value details (chain, returned fields, price) are front-loaded.

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

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

With no output schema, the description correctly compensates by listing the returned fields (hash, timestamp, tx count, gas used/limit, base fee, producer address), and it discloses the x402 payment requirement. Minor omissions remain (error/payment-failure behavior, whether results are cached), but nothing needed to invoke the tool is missing.

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

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

Schema description coverage is 100% for the single 'number' parameter, and the schema already documents the 'latest' default. The description's 'by number, or the latest one' merely restates that, adding no new format or edge-case semantics, so the baseline 3 applies.

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

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

States a specific verb+resource ('A block on Arbitrum One by number, or the latest one') and enumerates the returned fields, which distinguishes it from the many sibling *_block tools (base_block, eth_block, op_block) by chain. An agent can identify the tool and its output shape without opening any 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 clear context for use ('Use for timestamps, confirmations and chain-activity checks'), which is more than most siblings provide. It stops short of naming an alternative or an exclusion (e.g., when to prefer arb_tx or arb_receipt), so it is clear context without 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?

Discloses two traits annotations do not cover: the tool is paid ($0.001 USDC on Base per successful call via x402) and it is a live snapshot that can inform waiting. The payment rail plausibly explains the readOnlyHint=false annotation, though the description never says whether calls fail if payment is absent, which leaves a minor gap.

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 returned values, then the use case and pricing. Every clause earns its place with no filler.

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

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

With zero parameters, no output schema and no nested objects, the description fully covers what an agent needs: what is returned, why to call it, and the fact that it costs money. Nothing material is missing.

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

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

The tool takes no parameters (schema is an empty object at 100% coverage), so there is nothing to document; baseline 4 applies. The description correctly implies a zero-argument, network-scoped call.

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

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

States a specific resource (current gas on Arbitrum One) and enumerates exactly what is returned: gas price, base fee, suggested priority fee in gwei, and the cost of a 21,000-gas ETH transfer. The chain name 'Arbitrum One' cleanly separates it from the many sibling *_gas tools (base_gas, eth_gas, op_gas, polygon_gas).

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 timing guidance: 'Use before sending a transaction or to decide whether to wait.' That is a clear use context, though it never names an alternative tool or states when this is the wrong choice (e.g. L2 vs L1 gas queries).

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

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

Adds material context beyond the annotations: the $0.001 USDC-on-Base cost, the x402 payment mechanism, and the 'per successful call' billing condition. This explains the readOnlyHint=false/openWorldHint=true combination that would otherwise look odd for a query. It stops short of stating what happens on a failed or contested lookup or any 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?

Two sentences, zero filler. The capability is front-loaded and the operational caveat (action trigger, price, payment rail) is packed tightly into the second sentence.

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 fully compensates by naming every returned field (contract vs wallet, bytecode size, proxy status, implementation address) and disclosing the paid-call model. Nothing needed to invoke it correctly is missing.

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

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

Only one parameter with 100% schema description coverage, so the schema already carries the load; baseline is 3. The description adds that the address is expected to live on Arbitrum One, which is marginal but real added meaning over the schema's bare '0x address'.

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 and resource and enumerates the exact payload: contract-vs-wallet determination, bytecode size, EIP-1167 minimal-proxy flag, and implementation pointer. The chain scoping ('on Arbitrum One') distinguishes it from the many sibling is_contract tools (base_, eth_, op_, polygon_).

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

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

Explicitly states the use case: 'Use before sending funds or approving a spender.' That is a clear when-to-use, but it never names an alternative or exclusion, nor does it say why one would pick this over eth_is_contract/base_is_contract beyond the implicit chain difference.

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 annotations present, the description still adds meaningful context: the $0.001 USDC/x402 cost, that charging applies only on success, and that it returns up to 100 logs. This is genuinely beyond what the hints convey. The readOnlyHint=false is explained by the payment side effect rather than contradicted by the read-oriented prose.

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 purpose, then tacks on returns, usage and cost in short declarative sentences. Efficient overall, though the cost sentence sits at the end and could be folded in earlier.

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 usefully spells out the return shape (block, transaction hash, topics) and the 100-log cap. Covers purpose, params, returns, cost and usage; only failure/empty-result behavior 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%, so blocks, topic0 and address are already documented. The description restates the 'up to 1,000 blocks' bound and clarifies topic0 as an event signature hash, but adds little beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('event logs emitted by a contract on Arbitrum One') and scopes it precisely to the last N blocks. The chain qualifier cleanly distinguishes it from its near-identical siblings eth_logs, base_logs, op_logs and polygon_logs without needing to name them.

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?

Offers a light use case ('Use to watch transfers or contract events') but no when-not guidance and no routing to alternative chains or the other log tools. Usage is implied rather than specified.

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

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

Beyond the annotations, the description discloses the pricing mechanism ($0.001 USDC on Base, x402) and, crucially, that billing is per successful call — cost/authorization behavior an agent cannot see in the schema. It also clarifies that the returned figure combines confirmed and pending counts, which matters semantically. Note that annotations mark readOnlyHint=false even though this is a pure query, a mild tension the description neither confirms nor resolves.

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, and the core definition is front-loaded ahead of the usage hint and pricing note. 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?

For a one-parameter, no-output-schema tool, the definition covers what it returns conceptually (confirmed + pending counts), when to use it, and the cost of calling it. The only gap is the return shape — it implies two values but doesn't say how they are structured, which an agent must discover at call time.

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

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

There is a single parameter with 100% schema description coverage ("0x address"), so the schema already carries the parameter documentation. The description adds only that the address is on Arbitrum One; it gives no format details 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 precise verb+resource: the transaction count (nonce) of an address, explicitly scoped to Arbitrum One and covering both confirmed and pending counts. That scope cleanly separates it from arb_balance, arb_tx, and the same tool on other chains (eth_nonce, base_nonce, op_nonce, polygon_nonce) without opening another 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 to build the next transaction or to tell whether an address has ever sent anything" gives two concrete use cases, which is real when-to-use guidance. It stops short of naming an alternative or an exclusion (e.g. use arb_tx for history), so it lands at 4 rather than 5.

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

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

Annotations declare openWorldHint=true and readOnlyHint=false but say nothing about cost, which the description supplies: '$0.001 in USDC on Base per successful call, paid with x402' — a material behavioral fact (payment-gated, charged only on success). It also discloses the return contents. It does not cover pending/not-found transaction behavior, which for a receipt lookup is a notable omission.

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 return payload and followed by the use case and the pricing note. The field enumeration is dense but each item earns its place; no filler.

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

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

With no output schema, the description correctly carries the return-value burden and adds the pricing model. It stops short of explaining failure modes (reverted vs pending vs unknown hash) or how it differs from arb_tx, which an agent choosing among ~150 siblings would benefit from.

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 a single 'hash' parameter documented as '0x transaction hash'. The description adds no format, chain-prefix, or validation nuance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Receipt of a Arbitrum One transaction') and enumerates exactly what the receipt contains: status, gas used, effective gas price, fee in ETH, log count, and created contract. This distinguishes it from arb_tx (full transaction payload) and from the base_/eth_/op_ receipt siblings by naming the chain.

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 to confirm a payment or call went through' gives a clear triggering scenario. However, it never routes the agent between this and its near-identical siblings (arb_tx, base_receipt, eth_receipt) nor states exclusions, so the when-not guidance is absent.

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

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

Annotations (readOnlyHint=false, openWorldHint=true) are sparse, so the description carries real weight and delivers: it discloses live on-chain reading, the $0.001 USDC per successful call cost, and the x402 payment mechanism — all things the annotations do not convey. It omits what happens on failure (e.g., whether failed calls are charged) and any wallet/x402 setup prerequisite, keeping 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 tight sentences: what it returns, when to use it, and the cost. Return-field enumeration is front-loaded and earns its place given there is no output schema, though the sentence carries a slightly dense clause chain.

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 compensates by naming the return shape (raw amount, decimals, symbol, human-readable amount). Cost, payment method, and chain are all present; only error/failure semantics and any x402 setup requirement are missing.

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

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

Schema description coverage is 100% for both parameters ('0x ERC-20 token contract address', '0x wallet address'), so the schema already documents them. The description adds no parameter-level detail (no address format nuance, no checksum guidance), which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb+resource with chain scoping: 'ERC-20 token balance of a wallet on Arbitrum One', and enumerates the returned fields. This cleanly separates it from the many sibling chain variants (eth_token_balance, base_token_balance, op_token_balance, polygon_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?

Gives a concrete usage context: 'Use to check stablecoin or token holdings before a transfer, payment or trade.' It does not name an alternative tooling path or state exclusions (e.g., when to use arb_balance instead for native ETH), so it stops short of explicit alternatives.

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

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

The description discloses that data is read live from the contract and states the exact cost ($0.001 in USDC via x402), which is critical behavioral context not covered by annotations. Annotations show readOnlyHint=false, but the description clarifies it is a read operation with a payment side effect. It does not detail error behavior or payment failure handling.

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 concise sentences: the first states what is returned and where it is read from; the second gives use cases and payment terms. No extraneous information, and the most important information is front-loaded.

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

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

For a single-parameter read tool with no output schema, the description covers purpose, usage, data source, and payment requirements. It could mention the return format (e.g., object with name, symbol, decimals, supply), but annotations and schema fill most gaps.

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

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

Schema coverage is 100% and the single parameter is already described as a 0x ERC-20 token contract address. The description does not add format or validation details beyond the schema, so baseline 3 applies.

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

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

The description states a precise verb and resource: it returns name, symbol, decimals, and total supply of an ERC-20 token on Arbitrum One, read live from the contract. It is clearly distinguishable from sibling tools like arb_token_balance, which likely returns balances rather than 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?

The description explicitly gives two use cases: identifying an unknown token address and formatting raw token amounts correctly. This tells the agent exactly when to use this tool rather than a balance or price tool.

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

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

The description adds genuinely useful behavioral context that the annotations do not: cost ($0.001 USDC on Base per successful call) and the x402 payment mechanism, plus the fact that a nonexistent hash is a meaningful outcome. It does not, however, address the tension between its implied read-only lookup semantics and the annotations' readOnlyHint=false / idempotentHint=false, nor error behavior for malformed hashes.

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 action and scope, then the return fields, then usage and price in three compact sentences. The field enumeration is dense but earns its place given there is no output 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, listing the returned fields is the right compensation, and the pricing/payment details cover the main hidden cost of invocation. It stops short of describing error/not-found handling or confirming that the hash must reference an Arbitrum One transaction.

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

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

There is a single parameter ('hash') and schema description coverage is 100%, with the schema already stating '0x transaction hash'. The description says only 'by hash' and adds no format, chain-scoping, or validation detail beyond the schema, so the baseline 3 applies.

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

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

It names a specific verb/resource ('A transaction on Arbitrum One by hash') and enumerates the returned fields (sender, recipient, value, nonce, gas limit, selector, block), so an agent knows exactly what it retrieves. The chain qualifier separates it from eth_tx/base_tx/op_tx, but it never distinguishes itself from the closely related arb_receipt or arb_logs, so sibling differentiation is only partial.

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 to check what a transaction did or whether it exists' gives a clear use case and implicitly covers the not-found outcome. However, no alternative is named (arb_receipt for status/gas-used/logs, arb_logs for events) and there are no stated exclusions or prerequisites beyond payment.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, and the description adds materially beyond that: the $0.002 USDC x402 per-call cost (a rate/pricing constraint) and the interpretation of an unlimited approval as a risk signal. The non-read-only hint for a query tool is somewhat surprising, but it is consistent with the disclosed per-call payment rather than contradicted by the text, so no clear contradiction exists.

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

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

Two sentences, zero filler: purpose/return contents first, then usage scenarios, then cost. The most decision-relevant information is front-loaded, and the pricing detail is short and factual.

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, yet the description enumerates the return payload (raw and formatted allowance, token symbol, decimals, unlimited flag), plus the cost model and the decision context for calling it. An agent has everything needed to invoke it correctly without external assumptions.

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 each parameter already carries a role description ("Wallet address that holds the token", "Address allowed to spend, usually a router or protocol contract", "ERC-20 token contract address on Base"). The description restates the owner/token/spender relationship as part of the purpose but adds no format, default, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a precise verb and resource: checking a spender's ERC-20 allowance on Base, with the exact owner/token/spender triple implied. It also enumerates what is returned (raw and formatted allowance, symbol, decimals, unlimited flag), which cleanly separates it from base_token_balance and base_token_info in the sibling list.

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

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

"Use before a swap or deposit to see if an approve transaction is needed, and to audit a wallet for risky unlimited approvals" gives two concrete triggering scenarios. It does not name an alternative tool or a when-not-to-use case, so it stops just short of the explicit routing guidance that would earn 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 annotations only covering safety hints, the description supplies genuinely useful behavioral facts: output is returned in both wei and ETH, the read is live at the latest block (no caching), and each successful call costs $0.001 USDC via x402. The paid-call disclosure also plausibly explains why readOnlyHint is false despite a read operation, rather than contradicting it.

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

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

Two tight sentences: the first identifies the resource, units, chain and freshness; the second gives the use case and the cost. Nothing is redundant and the most important facts lead.

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

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

With no output schema available, the description compensates by stating the return units (wei and ETH) and freshness guarantee, and it discloses the monetary cost of the call. For a one-parameter read tool, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the single address parameter is already documented as a '0x wallet or contract address'. The description adds only that 'any' address is accepted, which is marginal; 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 (reads balance), resource (native ETH), and scope (any address on Base, at the latest block), and explicitly distinguishes itself from the ERC-20 siblings in the list by specifying 'Native ETH' versus token balances, and from other chains' balance tools by naming Base.

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 to check whether a wallet is funded before sending, paying gas or settling' gives a concrete decision context for invoking it. It stops short of naming an explicit alternative (e.g. base_token-balance for ERC-20 holdings) or stating when not to use it, so it is clear but not complete.

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

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

The description discloses a real behavioral trait the annotations do not convey: a $0.001 USDC charge on Base per successful call via x402, which also explains why readOnlyHint=false and idempotentHint=false are set for an otherwise read-like operation. It does not cover failure behavior (e.g., unknown block number or payment failure), 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 compact sentences plus a short cost sentence, with the resource and return fields front-loaded and the usage cue following. Every clause carries information; 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?

With no output schema, the description usefully enumerates the returned fields (hash, timestamp, tx count, gas used and limit, base fee, producer) so the agent knows what it gets back. Annotations cover safety flags and the payment note covers cost; only error/edge-case behavior is unaddressed for this otherwise simple one-parameter tool.

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

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

Schema description coverage is 100% and the single 'number' parameter is already documented as 'Block number, or latest (default)'. The description's 'by number, or the latest one' restates that same semantics without adding format details (hex vs decimal, ranges, errors on out-of-range). Baseline 3 for a fully documented single-param schema.

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

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

The description names a specific resource (a block on Base) and the retrieval modes ('by number, or the latest one'), and it enumerates the returned fields (hash, timestamp, tx count, gas used/limit, base fee, producer). The chain qualifier plus the base_block name separate it from eth_block/arb_block/op_block/polygon_block siblings, though the contrast is implied by naming rather than stated.

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 for timestamps, confirmations and chain-activity checks' gives concrete use cases that tell an agent when this tool is the right pick. It stops short of naming an alternative (e.g., base_tx or base_receipt) or stating when not to use it, so it is clear context without routing.

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

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

Annotations cover the safety/side-effect profile (readOnlyHint=false, openWorld=false-style hints), and the description adds genuinely non-redundant context: the $0.002 USDC cost on Base, the x402 payment rail, and that billing is per successful call. It does not discuss failure handling, rate limits, or latency, which keeps it below 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?

Front-loaded with the resource and chain, then the return contents, then the usage trigger, then the cost. Roughly two dense sentences with no filler – every clause carries actionable information.

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

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

With no parameters and no output schema, the description carries the return-value burden itself and does so thoroughly (every field listed), plus discloses pricing. Nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4 by the rubric; there is no parameter surface for the description to clarify or obscure. Describing the returned-fee fields is useful but is return-value semantics rather than parameter semantics.

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

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

States a specific verb+resource – live gas prices on Base (chain 8453) – and enumerates the exact fields returned (base fee, priority fee, maxFeePerGas, block fullness, estimated ETH/ERC-20 transfer cost). The chain ID explicitly disambiguates it from the many sibling gas tools (eth_gas, arb_gas, op_gas, polygon_gas).

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 before sending a transaction on Base or to decide whether to wait for lower fees" gives clear context for invocation and implies the decision it supports. It does not explicitly name an alternative tool or state a when-not condition, so it falls short of the 5 rubric.

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

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

Annotations declare openWorldHint, non-readOnly, non-idempotent, and non-destructive. The description adds critical behavior beyond annotations: a $0.001 USDC cost per successful call via x402, and the return contents (bytecode size, EIP-1167 proxy status, implementation address). It omits auth/header details and error behavior, keeping 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 the core purpose, then usage advice, then cost. Every sentence earns its place and no information is redundant.

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

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

With no output schema, the description carries the return-value burden and does so by naming key return fields. It also covers chain, cost, and use case. It could be more explicit about the x402 payment flow or error cases, but it is otherwise complete for a paid single-address query.

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, and the schema already documents it as a 0x address. The description adds only 'address on Base', which does not meaningfully extend parameter semantics 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 chain (Base), the exact check (smart contract vs plain wallet), and extra outputs (bytecode size, EIP-1167 minimal proxy, implementation address). This distinguishes it from sibling is_contract tools on other chains and even from a generic contract check.

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 says when to use it: before sending funds or approving a spender. Clear context, but does not name alternatives or state when not to use it (e.g., use eth_is_contract for Ethereum addresses).

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

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

Adds real context beyond annotations: the 100-log result cap, the 1,000-block retention window, and the $0.001 USDC x402 payment per successful call, which explains why readOnlyHint is false for a query-shaped tool. It stops short of stating whether truncated results can be paged or completed, 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?

Four tight sentences, front-loaded with the core behavior and scope, then the return shape, then the use case, then the cost. Nothing is redundant and every sentence carries 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, the description covers the return payload (up to 100 logs with block, tx hash and topics), the scan window, the filter, and the payment cost — enough to call the tool correctly. It omits how to retrieve results beyond the 100-log cap, which is the only notable gap.

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

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

Schema description coverage is 100%, so the schema already documents blocks (1-1000, default 50), topic0 (0x event signature hash) and address. The description largely restates these (the 1,000 cap, topic0 as 'event signature hash') and adds only the implicit constraint that address is a contract, so the baseline 3 applies.

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

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

States a specific verb and resource ('recent event logs emitted by a contract'), names the chain (Base), the lookback scope (last N blocks, up to 1,000) and the optional filter (topic0). An agent can distinguish this from the sibling log tools (eth_logs, arb_logs, polygon_logs, op_logs) purely from the description.

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 positive use case ('Use to watch transfers or contract events') but no when-not guidance and no routing to alternatives such as eth_logs for other chains or base_receipt for a single transaction. Usage is implied rather than explicitly bounded.

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

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

Annotations declare openWorld and non-destructive, but the description adds genuinely new behavior: the result covers both confirmed and pending transactions, and the call costs $0.001 USDC via x402 payment. The pricing/payment requirement is important operational context not present in the structured fields. It does not explain what happens on a failed payment, keeping it short of a 5.

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

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

Two tight sentences with zero filler, front-loading the resource definition and following with usage and cost. 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?

For a single-parameter read tool with no output schema, the description covers purpose, usage, and pricing, and even hints at the return shape (confirmed vs pending). A brief note on what the two returned values are would make it fully 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?

Only one parameter, and schema coverage is 100%, so the schema already documents the 0x address. The description adds no format or constraint detail beyond it; baseline 3 applies.

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

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

States a specific resource (transaction count/nonce) with chain (Base) and scope (confirmed plus pending). An agent can immediately distinguish it from the many sibling *_nonce tools (eth_nonce, arb_nonce, op_nonce, polygon_nonce) by chain.

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 when-to-use cases: building the next transaction or checking whether an address has ever sent anything. It does not name an alternative tool or an exclusion, but the usage context is clear and actionable.

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

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

Annotations cover only the safety/open-world profile, and the description adds materially more: an explicit price ($0.001 USDC on Base), the payment rail (x402), and the important nuance that billing occurs 'per successful call'. That last detail is genuinely useful behavior an agent cannot get from structured fields. It stops short of describing failure behavior for a pending or unknown hash.

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

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

Three sentences, front-loaded with the resource and its returned fields, then usage, then cost. The field enumeration is dense but every item is informative; no filler 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?

With no output schema, the description correctly compensates by listing what comes back, and it discloses the payment model. The remaining gap is edge-case behavior (unknown/pending hash, reverted-vs-not-found handling) for a paid lookup that charges only on success.

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

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

Schema coverage is 100% and the single 'hash' parameter is documented as '0x transaction hash' in the schema itself, so the description adds no syntax or format detail. Baseline 3 applies when the schema fully carries parameter semantics.

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

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

Names a specific verb+resource ('Receipt of a Base transaction') and enumerates the exact fields returned (status, gas used, effective gas price, fee in ETH, log count, contract created). It implies scope versus the network siblings (base-tx, base_block) via 'Use to confirm a payment or call went through', but never explicitly contrasts itself with base-tx, which likely returns raw transaction data.

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 to confirm a payment or call went through' states a use context, but there is no when-not guidance and no named alternative. An agent choosing between base_receipt, base-tx, base_tx and base_logs gets only a weak hint.

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 output schema, the description usefully discloses the return shape and the live-contract read, plus a genuinely non-obvious behavioral trait: a $0.001 USDC per-successful-call fee via x402, which affects how an agent should budget calls. It does not explain rate limits or failure/prerequisite behavior, so it falls short of full transparency.

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, each with a distinct job: what it returns, when to call it, what it costs. The scoping detail (on Base) is front-loaded before the usage hint, 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?

For a two-parameter read tool with no output schema, the description covers the chain scope, the return fields, the cost mechanism, and the intended use case. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters (token, address) are already documented as 0x addresses. The description adds no clarification over the schema, e.g. that `token` must be the contract address rather than a symbol, which is the most common misuse. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb+resource (ERC-20 token balance of a wallet) scoped to the Base chain, and it enumerates what is returned (raw amount, decimals, symbol, human-readable amount). The chain qualifier cleanly separates it from the many sibling *token_balance tools (eth_, arb_, op_, polygon_).

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 to check stablecoin or token holdings before a transfer, payment or trade" gives a clear triggering context. It stops short of naming alternatives (e.g. use eth_token_balance for Ethereum, or base_token_info for metadata), so there is no explicit routing or when-not guidance.

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

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

Annotations are present but thin (readOnlyHint=false, openWorldHint=true), and the description adds valuable behavior beyond them: the live-read semantics and the $0.001 USDC x402 cost charged only 'per successful call' – a meaningful billing detail. It omits rate limits and failure/payment-failure behavior, keeping it below a 5.

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

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

Three tight sentences: what it returns, when to use it, what it costs. Zero filler and the output fields are front-loaded.

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

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

For a one-parameter read tool with no output schema, the description supplies exactly what is missing: the returned fields and the payment requirement. Nothing an agent needs to invoke it correctly is absent.

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

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

Schema description coverage is 100% with a single well-documented 'token' parameter, so the schema carries the load. The description adds no format or validation detail beyond the schema's '0x ERC-20 token contract address'.

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 (reads live) and resource (name, symbol, decimals, total supply of an ERC-20 token on Base), enumerating the exact returned fields. This cleanly separates it from the sibling base_token_balance, which returns amounts rather than 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 two clear use cases: identifying an unknown token address and formatting raw token amounts. It does not name an alternative or state when not to use it, so it falls short of the explicit routing seen in top-tier definitions.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, and non-idempotent, which for a pure lookup is counterintuitive; the description resolves this by disclosing the x402 payment model and the $0.003 USDC cost per successful call. That addition explains the surprising annotation. It omits rate limits/retry cost behavior, so it lands at 4 rather than 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 primary lookup then the return fields, followed by the usage cue and the cost. Despite the long field enumeration, every clause maps to a return value an agent needs, so 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?

With no output schema, the description fully enumerates the return fields, plus usage guidance and the payment/auth requirement. An agent can call this correctly and interpret the result without further information.

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%: the hash parameter is fully specified in the schema (0x + 64 hex chars). The description only restates 'by hash' and adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

Names a specific verb (look up) and resource (any transaction on Base) keyed by hash, and enumerates the full payload returned (status, sender/receiver, value, method id, block/time, confirmations, gas, fee, contract creation). It is clearly distinguishable from siblings like base_receipt, base_block, and the chain-prefixed *_tx tools.

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

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

States a concrete when-to-use: 'confirm that a payment or contract call went through before acting on it.' That gives an agent clear trigger context. It stops short of naming alternatives (e.g., base_receipt for receipt-only data) or exclusions, so it doesn't reach a 5.

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

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

Annotations cover the openWorld/write-shape profile, but the description adds genuinely non-structured behavior: a $0.003 USDC cost on Base, charged per successful call via x402. This is important operational context an agent must know before invoking. It does not explain why readOnlyHint is false, but the payment disclosure largely accounts for it.

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

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

Three tight sentences: what it returns, when to use it, then the cost. Front-loaded with the resource and scope, and no filler.

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

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

With no output schema, the description compensates by enumerating the returned fields (sats and BTC balances, unconfirmed amount, received/sent totals, tx counts). Usage context and the pricing/payment mechanism are also present, leaving nothing critical missing for a one-param read.

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 parameter with 100% schema description coverage, so baseline is 3. The description's mention of legacy/P2SH/bech32 roughly mirrors the schema's '1..., 3... or bc1...' format note and adds no syntax or edge-case 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 resource (Bitcoin mainnet address) and enumerates exactly what it returns: confirmed balance, unconfirmed pending, total received/sent, tx counts. The Bitcoin-specific framing cleanly separates it from the many sibling balance tools (eth_balance, base_balance, polygon_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?

Gives three concrete use cases: payment verification, deposit arrival checks, and wallet monitoring. It provides clear context for when to reach for this tool but names no explicit alternatives or exclusions among the dozens of sibling balance/chain tools.

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

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

Annotations alone would look odd for a data fetch (readOnlyHint=false, idempotentHint=false); the description resolves this by disclosing the x402 payment model, cost ($0.002 USDC on Base), and that billing is per successful call. Return format is not described, but an output schema exists, so that gap is acceptable.

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

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

Two sentences, front-loaded with what is returned, then usage, then the cost disclosure. No filler; every clause carries 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 0 params, an output schema for return values, and annotations covering the safety profile, the description supplies the remaining essentials: usage trigger and the paid-call cost model. Nothing required to invoke it correctly is missing.

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

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

Zero parameters, so baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter semantics.

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

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

Specific verb+resource: it enumerates exactly what the call returns (next-block/half-hour/one-hour/economy sat/vB rates, cost in sats of a typical payment, mempool size, pending fees, latest block height). This clearly distinguishes it from siblings like btc_price or btc_address even without opening a 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?

Explicitly says when to use it: 'before sending a Bitcoin transaction or to decide whether to wait for lower fees.' That is concrete decision context, though it names no alternative tool (e.g., other gas/fee siblings) or when-not-to-use case.

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

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

Annotations already cover read-only/open-world/idempotency, and the description adds genuinely non-obvious context: live mainnet read, and a $0.002 USDC charge on Base via x402 billed 'per successful call'. That cost detail also explains why readOnlyHint is false (spending funds is a side effect) despite the tool being a read, resolving what would otherwise look like a mismatch.

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?

Four tight sentences: what it does, its two directions, the data source, then when to use it, then cost. The core capability is front-loaded and every sentence carries 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, the description usefully names the return values it produces (wallet address, avatar, primary name) and discloses the payment model and data source. It is nearly complete for a one-parameter read tool; only failure/error behavior under x402 payment is left unstated.

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

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

Schema description coverage is 100% and the single 'name' parameter already documents that it accepts either an ENS name or a 0x address for reverse lookup. The description restates the same dual-input semantics without adding format, normalization, or error-handling detail, so it is baseline-equivalent 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 verb and resource (resolve an ENS name to address/avatar) plus the reverse direction (address to primary ENS name), and pins the data source as live Ethereum mainnet. An agent can distinguish this from generic siblings like 'domain', 'domain-report', or 'wallet' without opening a 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 two concrete use cases: turning a human-readable name into a payable address, and displaying a readable name for a counterparty address. Clear application context, but it names no exclusions or alternative sibling tools (e.g. when to prefer 'domain' instead), so it stops short of full routing guidance.

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

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

Annotations already carry the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds meaningful context beyond them: freshness ('latest block') and the billing behavior ('$0.001 in USDC on Base per successful call, paid with x402'), which explains the non-read-only annotation and the cost/auth requirement. It does not cover failure modes or rate limits, so not a 5.

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

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

Three tight sentences, front-loaded with what it does, then when to use it, then cost. Every sentence earns its place with no redundancy.

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

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

For a one-parameter read with no output schema, the description is nearly complete: it names the return units ('in wei and in ETH'), the data source, usage context and pricing. It omits any error/empty-address behavior, which keeps it from a 5.

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

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

Schema coverage is 100% for the single 'address' parameter, so the schema already documents it. The description adds no format or constraint detail beyond 'any address'. 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 ('Native ETH balance of any address on Ethereum') and pins down the chain and data source ('read live from the chain at the latest block'). It distinguishes itself from siblings like eth_token-balance and eth_nonce, and from the same-named tools on other chains (base_balance, arb_balance). An agent can route correctly 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 explicit when-to-use context: 'check whether a wallet is funded before sending, paying gas or settling.' That is a concrete trigger for selecting this over eth_token-balance or eth_nonce. It does not name alternatives or exclusions explicitly, so it stops short of a 5.

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

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

Annotations carry the safety profile, so the bar is lower, and the description still adds real operational context: pricing ('$0.001 in USDC on Base per successful call') and the payment protocol (x402). It does not explain pagination or failure/error behavior, and it is silent on the fact that readOnlyHint=false sits oddly against a pure retrieval 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?

Three tight sentences, front-loaded with the resource and the returned fields before usage and cost. Dense but every clause carries information; nothing is redundant.

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

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

With no output schema, the description compensates by enumerating the returned fields, and it documents the payment requirement, which is essential for a paid endpoint. For a zero-required-parameter read tool this is complete enough to call correctly.

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

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

Schema description coverage is 100% for the single 'number' parameter, so the schema already documents the accepted value and the 'latest' default, and the description only echoes 'by number, or the latest one'. Baseline 3 is appropriate since the description adds no format or edge-case detail beyond the schema.

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

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

Names a specific verb+resource ('A block on Ethereum by number, or the latest one') and enumerates exactly what is returned (hash, timestamp, tx count, gas used/limit, base fee, producer address). This clearly distinguishes it from siblings like eth_tx, eth_receipt and eth_gas without needing to open any 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 for timestamps, confirmations and chain-activity checks' gives concrete use cases, which is stronger than implied usage. It stops short of naming alternatives or exclusions — e.g. it never says to use eth_gas/eth_tx instead when the agent wants gas price or transaction detail.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true). The description adds real behavioral context beyond them: the call has a monetary cost ($0.001 USDC on Base per successful call, paid via x402), which also explains why readOnlyHint is false despite the read-like nature. It does not discuss freshness/latency of the quoted gas values.

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

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

Three short sentences, front-loaded with what is returned, then when to use it, then the cost. No filler and nothing buried.

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

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

With no input parameters and no output schema, the description carries the burden of describing what comes back, and it does: gas price, base fee, priority fee, and a concrete 21,000-gas transfer cost. The payment precondition is also disclosed, so an agent has everything needed 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?

The tool takes zero parameters, so the baseline is 4. There is nothing parameter-related for the description to clarify or omit.

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 (fetch current gas) and enumerates the returned quantities: gas price, base fee, suggested priority fee in gwei, plus the ETH-transfer cost. The chain is explicit in the name and description, so it is cleanly distinguishable from arb_gas/base_gas/op_gas/polygon_gas 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?

Gives a clear usage trigger: 'Use before sending a transaction or to decide whether to wait.' However, it never names an alternative or a when-not condition (e.g., which sibling to use for a different chain), so it stops short of full routing guidance.

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

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

Annotations already declare open-world, non-idempotent, non-destructive behavior, so the bar is lower; the description adds real context by disclosing a hard payment requirement ($0.001 USDC on Base per successful call via x402), which is a consequential trait not captured by any structured field. It stops short of describing error behavior (e.g., non-existent addresses) or confirmation timing, and the readOnlyHint=false annotation for what reads as a pure query goes unclarified.

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 front-loaded: the capability and its return fields first, then the usage trigger, then the cost. No filler and nothing redundant with the schema or annotations.

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

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

With no output schema, the description carries the return-value burden and does it well by naming bytecode size, proxy status, and implementation address. For a paid, open-world query it omits only edge-case behavior (nonexistent address, non-Ethereum input) and what happens if payment fails.

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

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

Schema description coverage is 100% and the schema documents the single required 'address' (0x address) parameter, so the baseline is 3. The description adds no format detail (e.g., checksummed vs. lowercase, ENS support) beyond what the schema already provides.

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 (check whether an Ethereum address is a contract) and enumerates the exact outputs: bytecode size, EIP-1167 minimal-proxy detection, and the implementation it points to. The 'on Ethereum' scoping distinguishes it cleanly from arb_is_contract, base_is_contract, op_is_contract, and polygon_is_contract 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?

Gives a concrete when-to-use trigger: 'Use before sending funds or approving a spender,' which tells the agent the decision this tool informs. It does not explicitly exclude or compare against the other chains' is_contract tools, but the chain qualifier makes the selection inferable.

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

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

The description adds genuinely useful behavior beyond the annotations: per-call cost of $0.001 USDC on Base via x402 (effectively the auth/payment requirement) and a hard result cap of 100 logs against a scanned window of up to 1,000 blocks. It does not explain pagination or whether older history is reachable, which is the remaining gap. No contradiction with the annotations.

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

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

Four compact sentences, front-loaded with what the tool returns and the scope constraint, with cost last. Every sentence carries information, though the block-window limit is stated twice (description and 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 compensates by naming the return fields (block, transaction hash, topics) and the 100-log cap, and it covers the payment requirement. It is nearly complete for a 3-parameter read tool; only pagination/history limits 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 description coverage is 100%, so blocks, topic0 and address are already documented in the schema. The description only restates the same facts (block window cap, topic0 as event signature hash), adding no format or syntax detail beyond the schema.

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

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

States a specific verb and resource with scope: 'Recent event logs emitted by a contract on Ethereum over the last N blocks', plus the optional topic0 filter and result shape. This clearly reads as distinct from eth_receipt (logs for one tx) or eth_tx, though it never names a sibling to contrast against.

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

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

One sentence of usage context is given ('Use to watch transfers or contract events'), which is enough to imply the intent, but there is no when-not guidance and no explicit routing to alternatives such as eth_receipt or the equivalent base_logs/arb_logs/polygon_logs siblings for other 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 annotations present the bar is lower, and the description still adds real value: it discloses the x402 payment cost ($0.001 USDC on Base per successful call) and that no output schema exists but the value covers confirmed + pending nonce. This helps explain the otherwise-surprising readOnlyHint=false (a payment settles on Base) and idempotentHint=false. It does not state error or failure-charging behavior, keeping it from 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, front-loaded with the core semantics before the use cases and the cost. Every sentence earns its place with no filler.

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

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

For a single-parameter read tool with no output schema, the description covers what is returned (confirmed + pending nonce), why to call it, and the monetary cost of calling. The one gap is the lack of any hint about failure/refund behavior when the x402 payment does not yield a result.

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

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

Only one parameter and schema description coverage is 100% ('0x address'), so the schema already carries the semantics. The description adds nothing about address formatting or normalization, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('Transaction count (nonce) of an address on Ethereum') and qualifies the scope as both confirmed and pending. 'Ethereum' cleanly disambiguates it from the arb_/base_/op_/polygon_nonce siblings, so an agent can pick the right chain without opening a 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 two concrete use cases ('build the next transaction', 'tell whether an address has ever sent anything'), which is clear contextual guidance. It stops short of explicit when-not or naming an alternative tool, so it does not reach 5.

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

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

Annotations declare openWorldHint=true and destructiveHint=false but leave the payment model unstated. The description adds genuinely useful context beyond the annotations: the $0.001 USDC-on-Base cost per successful call via x402, which an agent must know before invoking.

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

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

Front-loads what the receipt contains, then the use case, then the cost in three tight sentences. No filler or redundancy.

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

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

With no output schema, the description correctly carries the return-value burden by listing the receipt fields, and it discloses the x402 cost. Slightly incomplete only in that it doesn't address behavior on a pending or unknown hash.

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

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

Only one parameter and schema coverage is 100%, so the schema fully documents the 0x transaction hash. The description adds no format or syntax detail beyond it, which is the expected baseline here.

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 (Ethereum transaction receipt) and enumerates the concrete fields it exposes (success/reverted, gas used, effective gas price, fee in ETH, log count, created contract). This field list implicitly separates it from sibling eth_tx, though it never names an alternative directly.

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 to confirm a payment or call went through" gives a clear use case, but offers no when-not guidance and does not point to sibling tools such as eth_tx or eth_logs that an agent might otherwise reach for.

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

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

Annotations cover the safety profile, and the description adds genuinely non-structured context: the value is read live from the contract (not cached), and the call costs $0.001 USDC on Base via x402 per successful call. It does not explain the zero-balance/error path, and doesn't reconcile the read-only-looking operation with readOnlyHint=false and idempotentHint=false, though those flags are defensible given the x402 payment side effect.

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 is returned, then when to use it, then the cost — each sentence carries distinct information with no filler or repetition of the 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 does the work of describing the return shape (raw amount, decimals, symbol, human-readable amount) and discloses the pay-per-call cost model. It stops short of covering failure modes (invalid token address, non-ERC-20 contract) that an agent calling this live contract read might encounter.

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 ('token' as 0x ERC-20 contract address, 'address' as 0x wallet address) are already fully documented in structured form. The description adds no syntax, format, or edge-case detail beyond what the schema provides, so the baseline 3 applies.

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

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

Names a specific verb+resource ('ERC-20 token balance of a wallet on Ethereum') and distinguishes itself from the native-coin sibling eth_balance by scoping to ERC-20 contracts. It also enumerates the returned fields (raw amount, decimals, symbol, human-readable amount), so an agent knows exactly what it gets without opening a 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 to check stablecoin or token holdings before a transfer, payment or trade" gives concrete triggering scenarios. It does not explicitly name alternatives (e.g., eth_balance for native ETH, eth_token_info for metadata), so routing between siblings is left partly 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?

Annotations declare readOnlyHint=false and idempotentHint=false, which is somewhat odd for a read operation, but the description clarifies it reads live from the contract and discloses cost ($0.001 USDC on Base via x402) — non-obvious operational context not in annotations. It doesn't contradict annotations and adds payment/auth info.

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 is returned, then usage and cost. No wasted verbiage.

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

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

Given a single-parameter read tool with full schema coverage and no output schema, the description covers purpose, use cases, and payment model. Since there's no output schema, it could explicitly state the return shape (e.g., object with those four fields), hence not a 5.

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

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

Schema coverage is 100% and the single parameter 'token' is fully described as a 0x ERC-20 contract address. The description adds no format details beyond the schema, so baseline 3 is appropriate.

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

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

States precisely what is retrieved (name, symbol, decimals, total supply) for a specific resource (ERC-20 token on Ethereum), read live from contract. This distinguishes it from siblings like eth_token_balance (which returns balance) and arb_token_info/polygon_token_info (different chains).

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

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

Explicitly says 'Use to identify an unknown token address or to format raw token amounts correctly', giving clear use cases. It doesn't explicitly exclude alternatives, but the chain-specific naming and siblings' purposes make the boundary clear.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely new context absent from them: a $0.001 USDC-on-Base cost per successful call paid via x402. The payment detail also explains why readOnlyHint is false despite a lookup-style tool, so there is no contradiction.

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

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

Front-loaded with the resource and returned fields, then the use case, then pricing. The field enumeration is longer than strictly necessary but each element earns its place by compensating for the missing output schema. No filler 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?

With no output schema, the description usefully enumerates the returned fields and discloses the x402 payment model, which is the key operational detail for this family of paid tools. It could go one step further on error behavior (e.g., what happens when the hash does not exist), which keeps it from a 5.

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

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

With a single parameter at 100% schema description coverage, the schema already documents 'hash' as '0x transaction hash'. The description confirms the input is a hash but adds no format, validation, or lookup-failure semantics beyond the schema, so baseline 3 applies.

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

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

The description names the exact resource (an Ethereum transaction identified by hash) and enumerates the fields it returns (sender, recipient, value in ETH, nonce, gas limit, function selector, block), making it clearly distinguishable from siblings like eth_receipt, eth_logs, and eth_block without opening any 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?

It gives one concrete use case ('Use to check what a transaction did or whether it exists'), which implies when to reach for it, but never names a sibling alternative or an exclusion condition (e.g., use eth_receipt for status/gas-used). Usage is therefore implied rather than explicit.

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

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

Annotations declare the safety profile, but the description adds the crucial trait they cannot express: a $0.001 USDC on Base charge via x402 per successful call. That cost side-effect also rationalizes the otherwise odd readOnlyHint=false / idempotentHint=false, since repeated calls incur repeat payment. It does not state the output encoding, keeping it at 4.

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 front-loaded sentences with no filler: purpose first, use case second, cost last. Slightly denser than necessary but every sentence carries 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?

No output schema exists, but a hash's return (hex digest) is self-evident from the name, and the payment requirement is fully disclosed. The only minor gap is not stating the output format or length explicitly, which is acceptable for this tool.

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

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

Schema coverage is 100% and the single `text` parameter is already documented as accepting text or 0x-prefixed hex bytes, so the schema does the heavy lifting. The description reinforces the dual-input mode and adds the 0x-hex use cases, but contributes no syntax or format detail beyond the schema.

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

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

States a specific verb+resource ('Keccak-256 hash') and pins down the exact variant versus generic siblings like hash and hmac. It also names the concrete domain (function selectors, event topics, storage slots), so an agent can distinguish it from other hashing tools immediately.

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

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

'Use when building or decoding EVM calls' gives clear positive context for selection. It stops short of explicitly contrasting with the generic `hash` sibling or stating when a different hash is preferable, so it is a strong 4 rather than a 5.

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

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

Annotations only supply generic hints, and the description adds genuinely useful context beyond them: the operation does not pay the invoice, the output surface is listed, and the cost is $0.002 USDC on Base via x402 charged per successful call. It stops short of describing failure behavior for malformed invoices, which is the only real gap.

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, and the safety-relevant constraint ('without paying it') is front-loaded before the return-field list and cost. Every clause carries 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, the description fully enumerates the returned fields (network, amount in sats and BTC, description, payment hash, creation/expiry times, expired flag) and discloses the payment requirement. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100% and the single parameter is documented there (BOLT11 string starting with ln, lnbc mainnet). The description adds no syntax or format detail beyond what the schema already supplies, so baseline 3 applies.

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

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

States a specific verb (Decode) and resource (BOLT11 Lightning Network invoice) and immediately bounds the scope with 'without paying it'. No sibling tool decodes LN invoices, and the enumerated return fields make the operation's surface 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?

'Use to check what an invoice asks for before an agent pays it' gives a clear triggering condition. No explicit alternative or exclusion is named, but there is no competing sibling that would need one.

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

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

Annotations only provide generic hints (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false); the description adds the crucial non-obvious behavior that each successful call costs $0.001 in USDC on Base and is paid via x402. That pricing/payment disclosure goes meaningfully beyond the annotations, though it does not say what happens on payment failure or how the facts are returned.

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: the content list comes first, the intended use second, and the cost disclaimer last. Every clause carries information (which fields, when to use, what it costs) with no filler.

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

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

With no output schema, the description does the heavy lifting by enumerating the returned fields (chain id, USDC address/decimals, explorer, RPC URLs, x402 network id) and disclosing the payment model, which is enough to invoke it correctly. It could be slightly fuller on return format and payment-failure behavior, but nothing essential is missing.

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

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

The schema has zero parameters with 100% coverage, so there is nothing for the description to clarify. Per the rubric, a no-parameter tool gets the baseline of 4; the description correctly implies no inputs are required, though it never states this explicitly.

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 concrete resource ('Reference facts for paying and reading on Base mainnet') and enumerates exactly what is returned: chain id, native USDC contract and decimals, block explorer and public RPC URLs, and the x402 network identifier. This makes it immediately distinguishable from sibling on-chain tools like base_balance, base_gas, or eth_tx, which perform lookups rather than return static configuration constants.

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 an explicit use case: 'Use to configure an x402 or Base client.' That is clear guidance on when to reach for this tool, but it names no alternative tools and states no conditions under which not to use it (e.g., when an agent just needs a balance or gas estimate from the base_* siblings).

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

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

Goes well past annotations by disclosing the freshness guarantee (latest block), the return shape (wei and ETH), and the economic/auth behavior: $0.001 USDC on Base per successful call via x402, which implies failed calls are not charged. This also explains the otherwise puzzling readOnlyHint=false, since the call settles a payment on Base even though the Optimism read itself changes nothing.

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

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

Three sentences, front-loaded with purpose, then use case, then cost/payment. Every sentence carries distinct information (what, when, price) with no repetition of the schema or title.

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

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

For a one-parameter read tool with no output schema, the description supplies everything an agent needs: chain, asset, freshness, units returned, and the payment mechanism. Nothing material to a correct invocation is left out.

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% ('0x wallet or contract address'), so the single parameter is already fully documented. The description only reinforces the scope with 'any address on Optimism' and adds nothing about address format or validation, so the baseline 3 applies.

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

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

States a specific verb+resource ('Native ETH balance of any address on Optimism') and pins the chain, asset type and read semantics ('read live from the chain at the latest block'). Naming the chain and 'native ETH' implicitly separates it from op_token-balance (ERC-20 on Optimism) and eth_balance (same asset, wrong chain), so an agent can pick the right sibling without opening a 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 when-to-use context: 'check whether a wallet is funded before sending, paying gas or settling.' No exclusions or explicit alternative routing (e.g. pointing to op_token-balance for ERC-20 or op_nonce for sequencing), but the trigger condition is clear and actionable.

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

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

Annotations supply the safety profile (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false), but the description adds materially: the call costs $0.001 in USDC on Base via x402. That payment/auth requirement is behavioral context the annotations don't carry. Return-shape and failure behavior are not described.

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 resource, then the field list, then usage and cost. The field enumeration is slightly list-heavy but earns its place given there's no output 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 single-param, no-output-schema tool, the description is nearly sufficient: it lists the returned fields and discloses the payment model. It doesn't cover edge cases like invalid block numbers or error/refund behavior, which would round it out.

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 only one parameter, so the schema already documents 'number'/'latest' (default). The description restates 'by number, or the latest one' without adding format detail, so baseline 3 is appropriate.

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

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

States a specific resource (an Optimism block, by number or latest) and enumerates the returned fields (hash, timestamp, tx count, gas used/limit, base fee in gwei, producer). The chain name cleanly distinguishes it from the many sibling *_block tools (arb_block, eth_block, base_block, etc.).

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 for timestamps, confirmations and chain-activity checks' gives clear intended use cases. It stops short of naming when NOT to use it or pointing to an alternative (e.g. op_gas/op_tx), so it's 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?

Adds real behavioral context beyond the annotations: the $0.001 USDC-on-Base cost and x402 payment mechanism, which is critical for an agent to know before calling. The only tension is that readOnlyHint=false for what reads as a pure reader, but the description's payment disclosure plausibly accounts for the non-read-only flag, so this is a mild tension rather than a contradiction.

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 returned payload, then the use case, then the cost. Every sentence carries distinct information with no repetition.

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

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

For a zero-parameter tool with no output schema, the description covers the essentials: what is returned, in what units, the practical interpretation (transfer cost), when to call it, and the billing model. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description adds return-shape context (units in gwei, transfer cost at 21,000 gas) that is useful even though it concerns output rather than input.

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 (current gas on Optimism) and exactly what is returned: gas price, base fee, suggested priority fee in gwei, plus the cost of a 21,000-gas ETH transfer. The network naming cleanly disambiguates it from the many sibling gas tools (eth_gas, base_gas, arb_gas, polygon_gas).

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 says when to use it: 'before sending a transaction or to decide whether to wait.' That is a clear contextual trigger, though it does not name an alternative tool or state any exclusion, so it stops short of full routing guidance.

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

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

Annotations cover the safety profile, but the description adds material context they don't: a $0.001 USDC-on-Base charge per successful call settled via x402, meaning the agent must be prepared to pay. It also discloses the return content (bytecode size, proxy status, implementation), which matters since there is no output schema. It does not reconcile the readOnlyHint=false annotation with what reads like a pure lookup.

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 clauses: what it returns, when to call it, what it costs. No filler, and the most decision-relevant information (result shape and payment) is front-loaded.

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

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

With no output schema, the description fully carries the return-value burden by enumerating contract/wallet, bytecode size, proxy flag, and implementation. The payment requirement, which an agent must know before invoking, is also 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?

Single parameter with 100% schema description coverage, so the schema already documents the 0x address. The description only implies the address must live on Optimism; it adds no format or validation detail beyond the schema, which is the expected baseline here.

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 (address on Optimism → contract vs. wallet) and explicitly names the extra payload: bytecode size, EIP-1167 minimal-proxy detection, and implementation address. The chain qualifier cleanly separates it from eth_is_contract, base_is_contract, arb_is_contract, and polygon_is_contract.

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 before sending funds or approving a spender" gives a concrete trigger for calling it, which is real guidance. It stops short of naming when NOT to use it or pointing at the other chain-specific is_contract siblings, 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?

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false), and the description adds genuinely non-redundant behavior: a $0.001 USDC cost on Base per successful call paid via x402, and an output cap of 100 logs. That payment detail is important given readOnlyHint=false. It does not contradict the annotations — the mutation-adjacent flag is explained by the paid x402 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?

Well front-loaded: purpose first, then filter, return shape, use case, and cost. Four sentences with little waste, though the cost sentence is appended rather than integrated and the returns sentence partly duplicates the schema's role.

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 compensates by naming the return shape (up to 100 logs with block, transaction hash, topics) and discloses the payment model and network. Gaps are minor: no error/failure behavior and no note on what happens when zero logs match.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema (including the 1-1000 range and default 50). The description restates the block cap and topic0 filter but adds no syntax, format, or edge-case 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?

The description states a specific verb and resource — recent event logs emitted by a contract — and pins the scope (Optimism, last N blocks up to 1,000, optional topic0 filter). The chain name 'Optimism' alone separates it from the eth_logs/base_logs/arb_logs/polygon_logs siblings without opening a 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 to watch transfers or contract events' gives an implied usage context, but there is no when-not guidance and no routing to the closest siblings (op_tx, op_receipt) which also surface on-chain activity. The agent gets a hint, not a decision rule.

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

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

Annotations cover the safety profile, but the description adds non-obvious context: the call costs $0.001 USDC on Base via x402, which explains both the payment/auth requirement and why readOnlyHint is false despite this being a query. It also discloses that the returned nonce includes pending transactions, useful for correctness. Return format beyond that is unspecified, keeping it at 4.

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: the core value is front-loaded, the use cases follow, and the cost caveat comes last. Every sentence earns its place with no filler.

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

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

For a single-parameter query with no output schema, the description adequately conveys what is returned (the nonce, confirmed + pending) and the payment precondition. Only minor gaps remain, such as the exact return shape or error behavior on a non-existent address.

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 parameter with 100% schema description coverage, so the schema already documents the address field. The description adds no syntax or format detail for the address (e.g., chain-specific handling or validation), so the baseline 3 applies.

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

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

States a specific verb+resource: the transaction count (nonce) of an address, scoped to Optimism, and clarifies the value is both confirmed and pending. This distinguishes it cleanly from siblings like op_tx, op_balance, op_receipt and from the same-named nonce tools on other chains (eth_nonce, arb_nonce, polygon_nonce).

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 two concrete use cases (to build the next transaction, or to tell whether an address has ever sent anything), which tells the agent when this tool is the right pick. It stops short of naming alternatives or stating exclusions (e.g., using a different chain's nonce tool), so it lands at clear context without explicit routing.

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

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

Annotations cover the generic profile (openWorldHint=true, idempotentHint=false, destructiveHint=false, readOnlyHint=false), and the description adds genuinely useful behavior beyond them: the $0.001 USDC fee on Base, charged only per successful call, via x402. That cost/payment model materially affects whether an agent should call this tool. It does not say what happens for pending or nonexistent hashes, so it falls short of full transparency.

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 receipt contains, then use case, then cost — every clause carries information. Minor grammar awkwardness ("a Optimism") and a dense enumeration in the first sentence keep it just below ideal.

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 takes on the burden of describing return values (status, gas, fee, logs, contract creation), and it covers usage and payment. It omits edge-case behavior such as unrecognized or pending hashes and whether the tool is Optimism-mainnet specific, leaving a small gap.

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

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

There is a single parameter with 100% schema description coverage ("0x transaction hash"), so the schema already carries the semantics. The description adds no format, validation, or chain-selection detail about the hash, which matches the baseline 3 when the schema does the heavy lifting.

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

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

The description gives a specific resource (an Optimism transaction receipt) and enumerates its contents — status success/reverted, gas used, effective gas price, fee in ETH, log count, contract created — which functionally separates it from siblings like op_tx or op_logs. It never names a sibling explicitly, so the differentiation is implicit rather than stated.

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 to confirm a payment or call went through" gives a concrete when-to-use context, and the pricing sentence scopes it to paid calls. It stops short of naming alternatives (e.g., use op_tx for input data or op_logs for decoded events) or stating 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?

Describes live on-chain read and the exact cost ($0.001 USDC on Base, x402). However, it contradicts the annotations: the description says it's a read of a balance, yet has readOnlyHint=false, and it mentions a payment requirement while annotations declare non-idempotent, open-world behavior. It doesn't explain what happens on failed call or payment failure. The annotations mislead here.

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 concise sentences: first the payload, then usage, then cost/payment. It is front-loaded and each sentence adds distinct value.

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

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

Given only 2 params and no output schema, the description provides enough context for an agent to call it correctly: on-chain read, cost, payment chain. It could mention rate limits or failure behavior, but is effectively complete for a lightweight read tool.

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

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

Schema coverage is 100%, both parameters are documented with types and formats. The description does not add format or constraint details beyond the schema, so baseline 3 is suitable.

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: reads the ERC-20 token balance of a wallet on Optimism, and enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It is clearly distinguishable from sibling op_token_info (metadata) and op_balance (native ETH).

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 concrete usage scenario: check holdings before a transfer, payment or trade. It does not explicitly name alternatives such as wallet_portfolio or explain when not to use it, but the use case is clear.

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

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

The annotations declare readOnlyHint=false and idempotentHint=false, but the description explicitly frames this as a read ('read live from the contract', returning metadata only) with no state mutation described. That is a direct conflict for an agent deciding whether the call is safe. Real added context is present — the $0.001 USDC-on-Base x402 cost per successful call and the fact that values come live from chain rather than cache — but the read/write contradiction dominates.

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, no filler: what is returned, when to use it, what it costs. The payload is front-loaded so an agent can match it on the first clause, and the pricing sentence is last where it belongs.

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 enumerating the returned fields, and it discloses the payment mechanism an agent must satisfy before calling. It omits failure behavior (e.g., what happens for a non-contract or non-ERC-20 address) and any indication of whether the response is cached, but nothing critical to invoking it is missing.

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

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

Only one parameter, and the schema documents it at 100% coverage ('0x ERC-20 token contract address'), so the schema carries the load. The description adds the chain qualifier ('on Optimism'), which implies the address must be an Optimism contract, but no format, checksum, or validation detail beyond the schema.

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

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

Names the exact fields returned (name, symbol, decimals, total supply) for a specific resource (ERC-20 contract) on a specific chain (Optimism), and 'read live from the contract' establishes it is a fetch, not a write. The op_ chain prefix plus the metadata-vs-balance distinction separates it from op_token_balance and eth/arb/base/polygon_token_info implicitly, though sibling routing is never stated in words.

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 to identify an unknown token address or to format raw token amounts correctly' gives two concrete use cases, which is more than most definitions offer. It stops short of naming alternatives (e.g., price_token for valuation, op_token_balance for balances) 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?

The description depicts a pure lookup ('check what a transaction did or whether it exists'), i.e. a read operation, while the annotations declare readOnlyHint=false and idempotentHint=false. That is a direct conflict about the tool's side-effect profile. The cost disclosure ("$0.001 in USDC on Base per successful call, paid with x402") is genuinely useful added context, but it does not resolve the read/write contradiction.

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

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

Three sentences, front-loaded with the resource and its returned fields, then usage, then cost. Every sentence carries 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?

With no output schema, the description usefully enumerates the returned fields, and it discloses the payment model an agent must know before calling. It omits behavior for a missing/invalid hash or error conditions, which keeps it short of 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?

Only one parameter (hash) with 100% schema description coverage, so the schema already carries the meaning. The description adds nothing about the hash format, and per the high-coverage baseline a 3 is appropriate.

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

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

The description states the resource precisely (an Optimism transaction, looked up by hash) and enumerates the exact returned fields (sender, recipient, value, nonce, gas limit, selector, block), which implicitly separates it from siblings like op_receipt or op_logs. It lacks an explicit action verb, opening instead with a noun phrase, but the scope 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?

'Use to check what a transaction did or whether it exists' gives a clear usage context, but no when-not guidance and no named alternative among the many op_* siblings (op_receipt, op_logs, op_block). Usage is implied rather than routed.

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

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

The description adds substantial behavior the annotations do not convey: the value is read live at the latest block (freshness), is returned in both wei and POL (units), and carries a $0.001 USDC-on-Base x402 charge per successful call. It also implicitly reconciles the surprising readOnlyHint=false by disclosing that the call spends money, though it never states that explicitly or covers payment/auth failure 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: what it returns and from where first, then the use case, then the cost. Every clause earns its place and nothing is repeated from the schema or annotations.

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

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

For a single-parameter read tool with no output schema, the description covers return format (wei and POL), data freshness (latest block), the reason to call it, and the non-obvious cost/payment mechanism. Nothing an agent needs in order to decide and invoke correctly is missing.

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

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

Schema description coverage is 100% and the single 'address' parameter already documents '0x wallet or contract address', so the schema carries the parameter burden. The description adds only the 'any address' framing and implied chain scoping, which is the baseline 3 when structured data is complete.

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

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

States a specific verb (read) and resource (native POL balance) scoped precisely to one address on Polygon PoS, and the qualifier 'Native POL' implicitly separates it from polygon_token-balance and from the eth_/base_/arb_/op_balance siblings on other chains. An agent can identify the exact tool without opening any 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?

It names concrete triggering situations ('check whether a wallet is funded before sending, paying gas or settling'), which is clear context for when to reach for it. It stops short of any when-not statement or explicit pointer to a sibling (e.g. for ERC-20 balances use polygon_token-balance), so it lands at 4 rather than 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 annotations present, the description adds real behavioral context the annotations cannot: the call costs $0.001 in USDC on Base via x402 and is billed per successful call, which also explains why readOnlyHint is false despite being a data lookup. It does not cover failure behavior, latency, 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?

Three tight sentences, front-loaded with what the tool returns, followed by usage and cost. Every clause earns its place, including the cost line, which is non-obvious and material to invocation.

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

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

No output schema exists, so enumerating the returned fields (hash, timestamp, tx count, gas used/limit, base fee in gwei, producer) is essential and present. Parameter and payment behavior are covered; only edge cases such as invalid block numbers or payment failure handling 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% and the single 'number' parameter is already documented as 'Block number, or latest (default)'. The description repeats the same number-or-latest semantics without adding format details (hex vs decimal, block tags), so the baseline 3 applies.

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

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

Names a specific resource and scope (a block on Polygon PoS, by number or latest) and enumerates the returned fields, which lets an agent tell it apart from eth_block/arb_block/base_block by chain. It stops short of explicitly stating it is not for other chains, so sibling differentiation is implicit rather than stated.

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 for timestamps, confirmations and chain-activity checks' gives clear positive context for when to reach for this tool. There is no explicit when-not guidance or named alternative (e.g. polygon_tx for transaction-level lookups), so it does not reach the top of the scale.

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

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

Annotations are present (openWorldHint=true, readOnlyHint=false, etc.), so the bar is lower, and the description still adds material context they don't carry: the $0.001 USDC-on-Base cost per successful call via x402 payment. That payment obligation meaningfully explains the readOnlyHint=false designation and warns the agent before calling. It does not disclose freshness/caching or rate-limit behavior, so not a 5.

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

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

Three tight sentences, front-loaded with what it returns, then when to use it, then cost. Every sentence earns its place and nothing is redundant with the empty 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 parameters and no output schema, the description carries the full burden and does so: it enumerates the returned values and the POL-transfer estimate, states usage timing, and discloses the per-call cost. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies for a no-parameter tool.

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

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

States a specific resource and chain ('Current gas on Polygon PoS') plus exactly what is returned: gas price, base fee, suggested priority fee in gwei, and the cost of a 21,000-gas POL transfer. This cleanly separates it from sibling chain tools like arb_gas, base_gas, eth_gas, and op_gas without needing 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?

Explicitly names the trigger conditions: 'Use before sending a transaction or to decide whether to wait.' That is clear contextual guidance. It stops short of naming an alternative tool or any exclusion, so it lands at 4 rather than 5.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds critical cost information ($0.001 USDC on Base per successful call, paid via x402), which is not in annotations. It does not explain error handling or the exact return format, but the cost disclosure is a significant behavioral addition.

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: first states the core function and extra data, second provides critical usage and pricing context. No wasted words; front-loaded with purpose.

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 read-only check with one parameter and no output schema, the description covers purpose, usage, and cost. It does not mention what happens on failure or exact return structure, but overall sufficient for an agent to call correctly.

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

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

Schema coverage is 100% and the single parameter 'address' is fully documented. The description does not add syntax or format details beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb+resource: determines whether an address on Polygon PoS is a smart contract or plain wallet, and discloses bytecode size and EIP-1167 minimal proxy status. Clearly distinct from siblings like polygon_balance or eth_is_contract (different chain).

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

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

Provides a clear usage context: 'Use before sending funds or approving a spender.' Does not explicitly name alternatives or exclusions, but the purpose is narrow enough that an agent knows when to invoke 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?

Goes well beyond the annotations by disclosing the scan cap (1,000 blocks), the hard result cap (100 logs), the returned fields, and the $0.001 USDC-on-Base x402 payment per successful call — genuine cost/auth context. Note the mild tension with readOnlyHint=false, since the described behavior is a pure read; the paid call arguably justifies the conservative annotation, so this is not treated as a contradiction.

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?

Four sentences, correctly front-loaded: purpose and scope first, return shape second, usage third, cost last. Only 'Use to watch transfers or contract events' is close to filler, keeping it just short of a 5.

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 carries the return contract (up to 100 logs with block, tx hash, topics), plus cost and filtering semantics — enough to call it correctly. Ordering of logs, empty-result behavior, and why the 1,000-block cap exists are left unstated, but these are minor for a read tool.

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

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

Schema description coverage is 100%, so all three parameters (address, blocks, topic0) are already documented, including the 1-1000/default-50 range. The description restates the block cap and the meaning of topic0 but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource+chain: event logs emitted by a contract on Polygon PoS, with an explicit scan window and topic0 filter. The polygon_ prefix plus 'event logs' vs 'receipt'/'tx' makes it separable from the sibling chain tools without opening any 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 to watch transfers or contract events' gives an implied use case but no explicit when-not and no routing to alternatives such as polygon_receipt (single-tx events) or polygon_tx. An 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.

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

With annotations supplied, the description still adds real behavior: the call costs $0.001 in USDC on Base per successful call via x402, and the returned count includes pending transactions — both material facts not derivable from readOnlyHint/openWorldHint/idempotentHint. It doesn't describe failure/billing-on-error behavior or auth flow beyond naming x402, 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?

Three short sentences: what it is, when to use it, what it costs. Scope is front-loaded before usage and pricing, 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?

For a one-parameter read tool with no output schema, the description covers purpose, usage, and payment. The only ambiguity is the return shape — 'both confirmed and including pending' could mean two values or one combined count — which a missing output schema leaves 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?

One parameter with 100% schema description coverage ('0x address'), so the schema already carries the parameter contract. The description only references 'an address' generically and adds no format, chain-scoping, or validation detail beyond it — the prescribed baseline of 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 specific resource and chain: 'Transaction count (nonce) of an address on Polygon PoS,' and qualifies the scope as 'both confirmed and including pending transactions.' It does not explicitly distinguish itself from siblings such as polygon_tx or polygon_balance (or from the parallel eth_nonce/base_nonce/op_nonce variants), 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 two concrete use cases: 'Use to build the next transaction or to tell whether an address has ever sent anything.' That is clear when-to-use context, but there is no when-not guidance and no named alternative (e.g. when to prefer polygon_tx for history).

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

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

The description carries the highest-value behavioral detail not present in annotations: it costs $0.001 USDC on Base per successful call via x402, and the per-successful-call phrasing implies failures are not billed. Annotations mark readOnlyHint=false, which would look inconsistent for a read tool, but the paid x402 settlement plausibly explains it, and destructiveHint=false / openWorldHint=true align with chain data reads. No contradiction, and useful context beyond structured fields.

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

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

Three tight sentences: output contents first, then purpose, then price — effectively front-loaded with the most useful identifying information. The field enumeration is a list, but each item is a distinct return value that would otherwise be unknown given the missing output 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 compensates by enumerating return fields, and it discloses the payment mechanism and cost. The remaining gap is edge-case behavior — what is returned for a pending, dropped, or unknown hash — which matters for a receipt tool but is a minor omission for a single-parameter lookup.

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

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

Only one parameter (hash) and the schema documents it fully at 100% coverage, so baseline 3 applies. The description adds no format detail such as hash length, casing, or behavior on an unknown hash, but nothing is required given schema completeness.

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

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

The description names the specific resource (receipt of a Polygon PoS transaction) and enumerates what it returns: status, gas used, effective gas price, fee in POL, log count, contract created. This is far more specific than the vague siblings and distinguishes a receipt lookup from a raw transaction fetch, though it never explicitly contrasts itself with polygon_tx or polygon_logs.

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

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

'Use to confirm a payment or call went through' implies the usage context, and the per-call pricing gives a cost-aware trigger. However no alternative is named — an agent choosing between polygon_receipt, polygon_tx, and polygon_logs gets no explicit routing rule, and there are no exclusions or failure-path guidance.

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

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

Adds real behavioral context beyond annotations: values are read live from the contract (not cached) and each successful call costs $0.001 USDC on Base via x402. This pricing/auth detail is exactly the kind of thing annotations cannot express and materially affects invocation. Note the mild tension between 'read live from the token contract' and readOnlyHint=false/idempotentHint=false, which the per-call payment plausibly explains rather than contradicts.

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, front-loaded sentences: identity first, then usage, then cost. No filler, no repetition of the name or title.

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

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

There is no output schema, and the description compensates by naming the return shape (raw amount, decimals, symbol, human-readable amount), plus the chain and the payment model. For a 2-parameter read with full schema coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, with both params ('token', 'address') documented as 0x addresses. The description adds no syntax, format, or validation detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource+chain: 'ERC-20 token balance of a wallet on Polygon PoS', and enumerates the returned fields. An agent can immediately distinguish it from polygon_balance (native) and polygon_token_info (metadata) without opening a 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 use case: 'check stablecoin or token holdings before a transfer, payment or trade.' It does not name alternatives or state when-not to use it (e.g., versus polygon_token_info or polygon_balance), so it falls short of an explicit routing rule.

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

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

The description adds genuinely useful context the annotations do not carry: data is read live from the contract, and each successful call costs $0.001 USDC on Base via x402, which is a real behavioral constraint. There is mild tension with readOnlyHint=false and idempotentHint=false for what is described as a live read, though the x402 payment makes the call not strictly side-effect-free, so this is a discrepancy to note rather than a hard contradiction.

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

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

Three short sentences, front-loaded with what is returned, then when to use it, then the cost caveat. Every sentence earns its place 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?

There is no output schema, so the description correctly enumerates the returned fields itself, and it discloses the payment requirement, which an agent must know before invoking. For a one-parameter read tool this is 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% for the single 'token' parameter and it is documented as a 0x ERC-20 contract address. The description adds no format or validation detail beyond that, so the schema does the heavy lifting — the baseline of 3 applies.

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

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

States a specific verb/resource (read ERC-20 metadata) and enumerates exactly what comes back: name, symbol, decimals and total supply. It also pins the chain (Polygon PoS) and distinguishes itself from the sibling polygon_token_balance, which returns balances rather than 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 two concrete situations for calling it (identifying an unknown token address, formatting raw amounts) which is clear usage context. It stops short of naming an alternative tool or stating when not to use it, so it falls one step below the explicit routing seen in the best definitions.

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?

Discloses a real behavioral trait not in the annotations: a $0.001 USDC-on-Base cost per successful call via x402, plus the "per successful call" billing condition. The annotations are thin on their own (readOnlyHint=false is odd for a pure lookup) and the description doesn't reconcile that, but the payment disclosure is genuinely useful added context.

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

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

Three dense sentences: what it returns, when to use it, what it costs. Zero waste, front-loaded with the resource and field list, with the cost caveat placed last.

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 usefully enumerates the response fields and discloses the payment model, which is what an agent most needs for a paid single-hash lookup. It stops short of stating error behavior when a hash is unknown, though "whether it exists" hints at 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% and the single parameter is fully documented ("0x transaction hash"), so the schema carries the load; baseline 3. The description adds "by hash" but no additional format or constraint detail beyond the schema.

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

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

States a precise verb+resource (fetch a Polygon PoS transaction by hash) and enumerates the returned fields (sender, recipient, POL value, nonce, gas limit, selector, block). It does not differentiate itself from the very similar sibling polygon_receipt, so an agent must infer the tx-vs-receipt distinction on its own.

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

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

"Use to check what a transaction did or whether it exists" gives clear trigger context for calling it. However, it names no alternatives or exclusions — notably polygon_receipt, which an agent could easily confuse this with — so routing is left partly 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 annotations present, the description adds real behavioral context beyond them: the $0.005 USDC-on-Base cost per successful call via x402, the EOA-nonce caveat (outgoing transactions only), and the explicit statement of what data it does not return. That pricing and nonce-semantics detail is not available anywhere in the structured fields.

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

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

Front-loaded with the core resource and contents, then caveats, then the use case, then pricing. Dense but every clause carries information; the long token enumeration in the first sentence is the only mild bloat.

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 (balances, nonce, account type) and the payment model. What an agent needs to decide and call is largely present; only the return shape for the extra-token addresses is left implicit.

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 (address, tokens) are already documented in the schema; the description's 'up to 20 extra token addresses you pass' merely restates the schema's max-20 constraint. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

The description names a specific resource and scope ('live snapshot of any address on Base') and enumerates exactly what the snapshot contains: ETH balance, a named list of major tokens, up to 20 extra tokens, nonce, and account classification (EOA/contract/EIP-7702). It also fences off what it is not (transaction/token-transfer/trading history). It stops short of naming the sibling primitives it bundles (base_balance, base_nonce, base_is-contract), so an agent must infer the overlap rather than being told.

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 to check a counterparty's holdings' gives one concrete use case, and the 'not full transaction history' clause implies when to look elsewhere. However, no alternative is named (e.g. use base_balance for a single-token check, wallet-audit for deeper inspection), and there is no explicit when-not guidance beyond the history exclusion.

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