Agent Data Tools: Chain data

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

Adds substantial behavior beyond the annotations: error handling ('malformed address is rejected with 400, uncharged'), pricing ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), and it explicitly reconciles the readOnlyHint=false annotation ('Reads or computes only; not marked read-only because each call is charged'). This disclosure of cost and error semantics is exactly what annotations cannot convey.

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

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

Front-loaded with the core operation, then usage, error, and pricing detail in descending priority. The example address and pricing clauses are relevant but make it denser than a strict minimum, so it falls just short of perfectly economical.

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

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

With no output schema, the description still states the return (wei and ETH), the block context (latest), error behavior, and cost model. An agent has everything needed to call it correctly and interpret the 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?

Schema coverage is 100% for the single 'address' parameter, so the schema already carries the semantics; baseline is 3. The description adds a worked example address and reiterates 'any 0x address', which is marginally useful but not meaningfully 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?

Opens with a specific verb+resource+scope: 'Read the native ETH balance of any 0x address on Arbitrum One at the latest block, in wei and in ETH.' It explicitly names the sibling it is not (arb_token_balance) and the aggregate alternative (wallet_portfolio), so an agent can distinguish it 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 a concrete when-to-use ('check whether a wallet can pay gas or a transfer') and routes to alternatives with explicit conditions ('for ERC-20 tokens use arb_token_balance, for all holdings at once use wallet_portfolio'). Nothing is left to inference.

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

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

Adds substantial behavioral context beyond the annotations: non-existent blocks return 404, that call is uncharged, and each call costs $0.003 with the first 25 free. It even reconciles the readOnlyHint=false annotation by explaining the tool reads but is charged per call. Return shape is described, though pagination/limits are not relevant 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?

Front-loads purpose and returned fields before the usage routing and pricing details. Information-dense with little waste, though the pricing/example tail reads as a run-on that could be tightened.

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

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

With no output schema, the description compensates by listing all returned fields, and it covers error behavior (404), billing, and the read-only rationale. 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 the single parameter is already documented. The description adds the format hint ('decimal number') and an example (number=latest), which is marginally useful but mostly restates the schema's 'Block number, or latest (default)'.

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 (Fetch) and resource (block on Arbitrum One) and enumerates the returned fields (hash, timestamp, transaction count, gas used/limit, base fee, producer). It clearly distinguishes itself from same-chain siblings like arb_tx, arb_receipt, and arb_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 names when to use it (timestamps and confirmation counts) and points to the sibling alternative for a different need (for current fees use arb_gas). Both the condition and the alternative are stated, leaving nothing 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?

The description proactively explains the counterintuitive annotation readOnlyHint=false ('not marked read-only because each call is charged'), which is exactly the kind of annotation-disambiguation that adds value. It also discloses cost ($0.003/call, x402 USDC or card key), the free tier (first 25 free), and that failed calls are free. It does not, however, mention caching/refresh behavior for a non-idempotent price read, which would be the one remaining useful trait.

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?

Five short sentences, none redundant: purpose and return values first, then usage, then routing to the sibling, then pricing, then the annotation rationale. 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 present, the description enumerates the returned fields itself, so the agent knows what it gets back. Combined with cost and the annotation rationale, nothing needed to invoke this zero-param tool correctly is missing.

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

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

Zero parameters, so the baseline is 4. The description explicitly states 'Takes no input,' confirming the empty schema rather than leaving the agent to wonder about implicit arguments.

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 (current gas on Arbitrum One) and enumerates the exact values returned: gas price, base fee, suggested priority fee, plus 21,000-gas transfer cost. The chain qualifier ('Arbitrum One') distinguishes it from the near-identical siblings base_gas, eth_gas, op_gas and 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 an explicit when ('Use before sending a transaction or to decide whether to wait') and routes to the correct alternative with a condition ('for the fee a past transaction actually paid use arb_receipt'). Nothing about selection is left to inference.

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

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

With annotations present the bar is lower, but this description adds real behavioral context: malformed addresses return 400 and are uncharged, failed calls are free, pricing is $0.003/call with 25 free calls, and it proactively explains the otherwise puzzling readOnlyHint=false ('not marked read-only because each call is charged'). That annotation rationale is exactly the kind of disclosure that prevents an agent from misreading the structured hints.

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 question and the returned data before usage, pricing and annotation rationale. Dense but every clause carries information; the payment/free-tier sentence is the only slightly tangential element, though still decision-relevant for an agent weighing a paid call.

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

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

There is no output schema, yet the description enumerates what comes back (bytecode size, proxy flag, implementation), plus error semantics and cost. For a one-parameter tool this leaves nothing an agent needs to call it correctly.

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

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

Schema coverage is 100% for the single 'address' parameter, so the baseline is 3; the description goes beyond it by supplying a concrete example value and defining the malformed-input behavior (400, uncharged). It does not describe accepted address formats beyond the 0x prefix, so it stops short of a 5.

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 a 0x address on Arbitrum One is a smart contract or a plain wallet') and even enumerates the returned facts (bytecode size, EIP-1167 minimal proxy status, implementation address). The chain scoping ('on Arbitrum One') separates it from the sibling eth_is_contract, base_is_contract, op_is_contract, etc., which share the same verb but a different network.

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') and names the better alternative for a different need ('for a fuller risk verdict use check_counterparty'). This is the when/why/alternative triad done properly.

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

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

Adds substantial context beyond annotations: the return shape ('up to 100 logs'), the pricing/credits model, that failed calls are free, and an explicit reconciliation of why readOnlyHint=false ('not marked read-only because each call is charged'). Pricing and the read-only caveat are exactly the behavioral facts annotations cannot convey.

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

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

Front-loaded with the core action and scope, then alternative routing, then pricing. It is a single dense paragraph and the pricing/credits sentence is somewhat long, but each clause carries actionable information for an x402 agent.

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

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

With no output schema, the description still covers return contents (block, tx hash, topics), block-scan limits, filtering, cost, and the read-only flag rationale. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents blocks, topic0 and address. The description restates the blocks range and clarifies topic0 as a '0x 32-byte event signature hash', adding only marginal detail over the schema. Baseline 3 is appropriate.

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

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

States a specific verb (List), resource (recent event logs), scope (contract on Arbitrum One, last N blocks) and optional filter. It also names the sibling arb_receipt for a different use case, so an agent can separate this from the other arb_* 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?

Explicitly says what it is for ('watch transfers or contract events') and names the alternative and the condition that selects it ('for one transaction's outcome use arb_receipt'). When-to-use and when-to-use-something-else are both present.

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

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

Adds substantial context beyond annotations: malformed addresses return 400 and are uncharged, failed calls are free, the first 25 calls are free, and it explicitly reconciles readOnlyHint=false ('reads or computes only; not marked read-only because each call is charged'). The only gap is that it doesn't describe the return payload shape (confirmed vs pending counts), though no output schema exists.

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

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

Purpose is front-loaded in the first clause, followed by usage, error, example, and pricing. Every sentence carries information, though the pricing/keying sentence is dense relative to the tool's simple behavior.

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 with no output schema, the description covers purpose, alternative routing, error semantics, cost model, and a sample call. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema description coverage is 100% for the single 'address' parameter, so the baseline is 3. The description adds a concrete valid example (0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045) and the malformed-input rule, which is a modest but real addition.

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

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

States a specific verb and resource ('Read the transaction count (nonce) of a 0x address on Arbitrum One'), including the confirmed-plus-pending scope. It explicitly names the sibling arb_balance as the tool for a different need, so an agent can separate it from the ~50 other chain/entity tools 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') and routes the balance use case to arb_balance by name. The when-to-use and when-to-use-something-else conditions are both 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?

Goes well beyond the annotations: it discloses the pricing model ($0.003/call via x402 USDC or card key, first 25 free), that failed calls are free, that unknown/pending hashes cost nothing, and it proactively explains why readOnlyHint is false ('not marked read-only because each call is charged'). That last point converts a potentially confusing annotation into understood 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?

Front-loads purpose and return fields, then routing, then input/edge behavior, then commercial terms. Every sentence carries information an agent needs; nothing is redundant filler despite the density.

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 the description compensates by enumerating the returned fields. Combined with the error behavior, pricing, and sibling routing, an agent has everything required to invoke this correctly on the first attempt.

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

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

Schema description coverage is 100% and there is only one parameter, so the schema already carries the format definition. The description restates the 0x-prefixed 64-hex format and adds a concrete example hash, which is a mild invocation aid but largely duplicates structured data. 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 ('Get the receipt of a mined Arbitrum One transaction') and enumerates exactly what comes back: success/reverted status, gas used, effective gas price, fee paid in ETH, event log count, and any contract created. It also distinguishes itself from the sibling arb_tx by naming the fields that belong to that tool instead.

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 when to use it ('Use to confirm a payment or call went through') and routes the agent elsewhere for a different need ('for sender, value and calldata use arb_tx'). It further defines edge-case behavior: a pending or unknown hash returns 404, uncharged, so the agent knows the failure mode without trial.

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: it discloses pricing ($0.003/call via x402 USDC or card key), the free tier (first 25 free, failed calls free), and uncharged failure modes. Crucially it explains the non-obvious readOnlyHint=false — "not marked read-only because each call is charged" — resolving what would otherwise look like a mislabel on a read operation.

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 operation and return fields, then use case, then constraints and cost — a sensible order with no filler sentences. It is dense, packing pricing, error codes and annotation rationale into one paragraph, which slightly taxes scanning but every clause carries information.

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

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

There is no output schema, but the description enumerates return fields itself; it also covers input validation rules, error status codes, and billing/auth requirements. Nothing an agent needs to call this correctly and interpret the result is missing.

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

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

Schema coverage is 100%, so the baseline would be 3; the description adds real value on top by constraining both inputs to 0x addresses of 40 hex characters and mapping failure modes to input types (non-contract 404, non-ERC-20 422). It stops short of naming which param maps to which error, hence a 4 rather than 5.

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

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

States a specific verb and resource — read one wallet's balance of one ERC-20 token on Arbitrum One — and enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It explicitly differentiates from the sibling arb_balance for the native coin, so an agent can route correctly 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?

Names the concrete use case (check stablecoin or token holdings before a transfer or trade) and names the alternative plus the condition that selects it ("for the native coin use arb_balance"). Error conditions (404 for no contract, 422 for non-ERC-20) are also given so the agent knows what inputs are valid.

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 resolves the unusual readOnlyHint=false by explaining 'not marked read-only because each call is charged,' and adds pricing, free-call and 422 error behavior — genuinely beyond annotations. However, openWorldHint and idempotentHint are left unexplained and no return-format detail is given, so it is solid 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?

Front-loads purpose and the sibling alternative before input, example and pricing. All sentences carry weight, though the pricing/credits clause adds some density to an otherwise tight definition.

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, the input format, an example, error behavior and cost. 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 coverage is 100%, so the baseline is 3, but the description adds a concrete example address and the semantics that a non-ERC-20 address returns 422 uncharged. That goes beyond the schema's bare '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 specific verb (look up) and a precise resource set (name, symbol, decimals, total supply of an ERC-20 token), scoped to Arbitrum One and read live from the contract. It distinguishes itself from the sibling arb_token_balance by explicitly routing holder balances elsewhere.

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 use cases ('identify an unknown token address or format raw amounts') and names the alternative for a different need ('for a holder's balance use arb_token_balance'). The when-not condition is concrete.

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: discloses that malformed addresses return 400 uncharged, that failed calls are free, the $0.003/call x402 pricing and 25 free calls, and result behavior (newest first, capped at 50). It also proactively reconciles the non-obvious readOnlyHint=false, which would otherwise look like a mutation signal.

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

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

A single dense paragraph with the core action front-loaded before usage, errors and pricing. Every clause carries information, though the pricing/annotation-rationale tail makes it longer than strictly necessary for 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?

With no output schema, the description supplies the return shape (direction, counterparty, amount, transaction, ordering, cap) plus cost and error semantics. 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%, so token, blocks and address are already documented, and the description largely restates the defaults. It does add one fact absent from the schema (the 50-result cap), but otherwise 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 (List) plus resource and scope: a wallet's ERC-20 transfers on Arbitrum One, in and out, with default token, block window and result ordering. It also names the network implicitly and distinguishes itself from the balance sibling, so an agent can place it without opening the schema.

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

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

Explicit when-to-use ('confirm a payment arrived or see what was sent') and an explicit alternative for the adjacent need ('for the current balance use arb_token_balance'). No inference required to pick between the two.

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 give the safety profile (destructiveHint=false, openWorldHint=true), but this description actively resolves the one thing annotations get wrong-looking: readOnlyHint=false on a read tool, explained as 'not marked read-only because each call is charged.' The pricing model, free-call carve-outs, and the 404/uncharged path for unknown hashes are exactly the kind of context structured fields cannot carry. Deductions for omitting response shape details such as unconfirmed/pending transactions and any pagination or rate-limit behavior.

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

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

Front-loaded with purpose and return fields, then alternatives, then input format, then payment mechanics — a sensible ordering. The final sentence bundles pricing, card keys, free tier, and the read-only rationale into one dense run, which is informative but compressed enough to risk being skimmed past.

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 lookup with no output schema, the description covers return fields, the error path, cost, and the correct sibling for adjacent questions. An agent has everything needed to decide whether to call it and to interpret a 404 without a follow-up.

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

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

Schema coverage is 100%, so the format sentence largely restates the schema, but the concrete 64-hex example and the 'unknown hash returns 404, uncharged' rule add real meaning an agent cannot get from the schema alone. The example is especially valuable for a single opaque hash parameter, which is a common source of invocation errors.

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?

A specific verb ('Look up') applied to a specific resource ('Arbitrum One transaction by hash'), followed by an enumeration of the returned fields (sender, recipient, value, nonce, gas limit, selector, block). The network-qualified naming and explicit routing to arb_receipt and arb_logs make it distinguishable from every 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 an explicit use case ('see what was sent or whether it exists') and names two alternatives with the exact conditions that select them — arb_receipt for success/failure and fees, arb_logs for emitted events. This is the rare definition that fully closes the alternative-selection question.

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?

Despite annotations declaring readOnlyHint=false, the description preemptively explains why ('Reads or computes only; not marked read-only because each call is charged'), removing a potential contradiction. It also discloses pricing, free tier, and failure behavior, plus the return shape.

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

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

Front-loaded with the core purpose, then use cases, then billing/behavioral note. All sentences earn their place, though the pricing detail makes it slightly dense for a simple lookup.

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

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

With no output schema, the description compensates by listing exactly what is returned. Combined with the safety rationale and billing model, 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 coverage is 100%, so the baseline is 3. The description goes further by clarifying the owner/token/spender relationship (a wallet's token a spender contract is approved to move), adding semantic context to what the fields mean.

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 (check allowance) plus resource (ERC-20 approval on Base) and even enumerates the exact return contents (raw/formatted allowance, symbol, decimals, unlimited flag). This clearly distinguishes it from siblings like base_token_balance or base_token_info.

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

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

Gives two concrete use scenarios: pre-swap/deposit approve checks and auditing for risky unlimited approvals. It does not explicitly name an alternative sibling, but the guidance is clear enough for selection.

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 far more than the annotations: malformed addresses return 400 uncharged, failed calls are free, first 25 free, $0.003/call via x402 USDC or card key. Critically, it reconciles the surprising readOnlyHint=false by explaining why (per-call billing), which is exactly the context an agent needs to trust the annotation rather than be confused by 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?

Front-loads capability, then alternatives, then error/pricing terms, all in four tight sentences. The embedded example address is long but pays for itself as a copy-pasteable format cue.

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 the description correctly states both return units (wei and ETH). Input format, error handling, and billing quirks are all covered; nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and there is one parameter, so the baseline is 3, but the description adds the accepted format ('any 0x address'), a concrete example value, and the failure behavior for malformed input, which the schema does not convey.

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), resource (native ETH balance), chain (Base), block scope (latest), and output units (wei and ETH). It is immediately distinguishable from base_token_balance and wallet_portfolio, both of which it names.

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 the concrete use case ('check whether a wallet can pay gas or a transfer') and explicitly routes to siblings for the two nearest alternatives: base_token_balance for ERC-20 and wallet_portfolio for all holdings.

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 behavior beyond annotations: a nonexistent block returns 404 and is uncharged, failed calls are free, and it explicitly explains why readOnlyHint is false (per-call charging despite read-only operation). Adds real context annotations don't carry.

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

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

Front-loaded with the core action and return fields, then tacks on usage, error, example, pricing, and the read-only rationale. Dense but every sentence (pricing, free-failure, 404) 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?

No output schema exists, yet the description covers returned fields, usage context, error semantics, and payment model. For a single-parameter tool this leaves nothing an agent needs unanswered.

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 already documents "Block number, or 'latest' (default)". The description only marginally adds the "decimal" format detail and an example, 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 verb and resource ("Fetch a block on Base") and enumerates returned fields (hash, timestamp, tx count, gas, base fee, producer). It differentiates from base_gas in the next sentence, but does not address the chain-variant siblings (arb_block, eth_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?

Gives explicit when-to-use ("for timestamps and confirmation counts") and names an alternative for a specific case ("for current fees use base_gas"). No explicit when-not guidance beyond that one 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?

Goes well beyond the annotations by explaining the counterintuitive readOnlyHint=false ('not marked read-only because each call is charged'), which prevents an agent from mistaking it for a free read. Adds pricing/rate-limit context ($0.002/call via x402, first 25 free, failed calls free) and confirms it 'reads or computes only'.

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

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

Front-loads the payload (what is read/computed, in what units) followed by usage, then pricing. It is long for a gas tool, but nearly every clause carries distinct information; the pricing sentence is the only one that could be trimmed.

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

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

With no output schema and no parameters, the description carries the full burden and delivers: it enumerates each returned metric and its unit (gwei vs wei), the block context, and the fee estimates. An agent knows exactly what it gets back and what it costs.

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 param-related for the description to clarify. The description's detail about returned fields is descriptive value 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?

Names the specific network (Base / chain 8453) and enumerates exactly what is produced: base fee, priority fee, maxFeePerGas, maxPriorityFeePerGas, block fullness, and execution-fee estimates in specified units. This cleanly distinguishes it from the sibling *_gas tools for other chains.

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

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

States explicit usage moments: 'Use before sending a transaction on Base or to decide whether to wait for lower fees.' It gives clear context but never names an alternative tool (e.g., base_tx or base_block) for adjacent checks, so it stops short of full when-not/alternative 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 non-obvious (readOnlyHint=false on what is a pure read), and the description directly reconciles this: 'Reads or computes only; not marked read-only because each call is charged.' It also discloses pricing ($0.003/call via x402 USDC or card key), free tiers, and that failed calls are free — context no annotation field carries.

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

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

Front-loaded with the core purpose, then use case, alternative, error handling, and pricing — each sentence carries information an agent needs for routing or invocation. It is dense with billing detail but nothing is wasted; slightly heavier than strictly necessary.

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

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

There is no output schema, and the description compensates by naming the returned fields (bytecode size, proxy status, implementation). Combined with error behavior and cost model, an agent has everything needed to decide whether to call and to interpret the 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%, so the schema already documents 'address'. The description adds a concrete example address, which helps with format, but does not add chains/validation/normalization semantics beyond that. Baseline 3 is appropriate.

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

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

States a specific verb and resource (check whether a Base address is a contract vs wallet) and enumerates the returned facts: bytecode size, EIP-1167 minimal-proxy status, and the implementation address. This clearly separates it from the many sibling is_contract tools on other chains and from check_counterparty.

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

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

Gives an explicit trigger ('Use before sending funds or approving a spender') and names the escalation path ('for a fuller risk verdict use check_counterparty'). It even specifies malformed-input behavior (400, uncharged), so the agent knows the failure mode before calling.

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 destructiveHint=false, and the description proactively explains the unusual readOnlyHint=false ('not marked read-only because each call is charged') along with pricing and that failed calls are free. This resolves a genuine annotation ambiguity an agent would otherwise misread, though it doesn't cover rate limits or pagination beyond the 'up to 100 logs' cap.

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 action, then filters, return shape, routing guidance, and pricing in a tight sequence. Every sentence carries information, though the pricing/annotation-rationale tail makes it dense enough that a 4 is fairer than 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 compensates by describing the return shape ('up to 100 logs with block, transaction hash and topics') and the result cap. For a 3-param read tool with a clear sibling, 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 coverage is 100%, so both optional parameters are already documented with ranges and format. The description restates the 1-1,000/default-50 range and clarifies topic0 is a 0x 32-byte signature hash, adding only marginal detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('List recent event logs a contract emitted on Base') and scopes it by block range and optional topic0 filter. It explicitly names the sibling it is not (base_receipt) for single-transaction outcomes, so an agent can route without opening either schema.

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

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

Gives concrete use cases ('watch transfers or contract events') and an explicit alternative with its selecting condition ('for one transaction's outcome use base_receipt'). The when-to-use and when-not-to-use are both spelled out.

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, which is otherwise puzzling for a pure read; the description resolves this by explaining 'not marked read-only because each call is charged.' It also discloses the 400-on-malformed-address behavior, that such failures are uncharged, pricing ($0.003/call, first 25 free), and that failed calls are free — all beyond what annotations provide.

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

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

Purpose and scope are front-loaded in the first sentence, followed by usage, error/pricing behavior, and the annotation rationale. Every sentence carries distinct information; there is no filler or 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 single-parameter read with no output schema, the description covers what is returned (confirmed and pending counts), error semantics, cost model, and the sibling alternative. An agent has everything needed to call it correctly and interpret pricing.

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 baseline is 3. The description goes slightly beyond the terse schema text ('0x address') by supplying a full example address, clarifying the expected format and checksum convention.

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

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

States a specific verb and resource ('Read the transaction count (nonce) of a 0x address on Base') plus scope ('both confirmed and including pending transactions'), which is non-obvious detail. It explicitly differentiates from the nearest sibling by naming base_balance for balances.

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') and names the alternative tool for the adjacent need ('for its balance use base_balance'). When-to-use and when-not-to-use are both covered.

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 and idempotentHint=false, and the description proactively explains why a read-shaped tool is not read-only (each call is charged), which prevents an agent from misreading the flag as destructive. It adds billing behavior ($0.003/call via x402 or card key, first 25 free), the failed-calls-are-free rule, and the 404/uncharged path for unknown hashes — real behavioral context beyond the annotations.

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

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

Front-loaded with the operation and return fields, then routing, then input format, then billing. Every sentence carries information, though the pricing sentence is dense and slightly crowds the functional content; still efficient overall.

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

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

With no output schema, the description compensates by listing the receipt payload fields, and it covers the pricing/auth model an agent must know before calling a paid endpoint. For a one-parameter tool with rich annotations, 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 coverage is 100%, so the 0x-prefixed 64-hex hash format is already documented; the description restates it and adds semantic value with a concrete example hash and the behavior of an unknown/pending hash. It stops short of adding anything further, but for a single-param tool that is ample.

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 ('Get the receipt of a mined Base transaction') and enumerates the returned fields (status, gas used, effective gas price, fee in ETH, log count, contract created). It explicitly names the sibling it is not ('for sender, value and calldata use base_tx'), so an agent can separate it from base_tx 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 concrete use case ('confirm a payment or call went through'), names the alternative tool and what it covers instead, and specifies edge behavior for pending/unknown hashes (404, uncharged). Nothing about when to pick this over base_tx is left to inference.

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

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

Annotations are provided, yet the description goes well beyond them: it discloses the failure modes and their HTTP codes (404 for no contract, 422 for non-ERC-20), that both are uncharged, the pricing model ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), and directly explains the non-obvious readOnlyHint=false ('not marked read-only because each call is charged'). That is exactly the kind of context annotations cannot carry.

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

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

Dense but well front-loaded: purpose and return shape lead, then usage/routing, then input format, then error/pricing behavior. Every clause carries distinct information with no filler or 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?

No output schema exists, yet the description names the returned fields, so an agent knows what it gets back. Error codes, pricing, free tier, and the sibling alternative are all covered, leaving no material gap for invoking this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a real constraint not in the schema: both inputs must be 0x addresses of 40 hex characters. That clarifies format expectations for both required parameters beyond the schema's terse labels.

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 one wallet's balance of one ERC-20 token on Base') and enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It explicitly distinguishes itself from the sibling base_balance for the native coin, so an agent can route without opening either schema.

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

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

Gives a concrete use case ('check stablecoin or token holdings before a transfer or trade') and names the alternative for the native-coin case ('for the native coin use base_balance'), which is exactly the routing decision an agent needs.

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

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

Annotations carry safety hints, but the description goes well beyond them: it discloses error behavior (non-ERC-20 input returns 422 and is uncharged), billing semantics ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), and explicitly justifies the unusual readOnlyHint=false ('not marked read-only because each call is charged'). That explanation resolves what would otherwise be a confusing annotation for a read-only tool.

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

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

Front-loaded with purpose and the sibling routing, then example, then commercial terms. Every sentence is informative, though the pricing/trial details add length that is tangential to invocation mechanics.

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 the description enumerates the returned fields (name, symbol, decimals, total supply), documents the error case, and covers cost. An agent can call this correctly and interpret the result without additional resources.

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

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

Schema coverage is 100%, so the single 'token' parameter is already documented, giving a baseline of 3. The description adds a concrete worked example address and the failure mode for non-contract addresses, which is meaningful context the schema does not carry.

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 (look up) and resource (name, symbol, decimals, total supply of an ERC-20 contract on Base), including that values come live from the contract. It explicitly distinguishes itself from the closest sibling by routing holder-balance lookups to base_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?

Names two concrete use cases (identifying an unknown token address, formatting raw amounts) and the explicit alternative for balances (base_token_balance). The agent has everything needed to choose between base_token_info, base_token_balance, and base_is_contract without opening a schema.

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 goes well beyond them: it discloses 400 rejection with no charge for malformed addresses, pricing ($0.003/call, first 25 free, failed calls free), payment paths (x402 USDC or card key), and explicitly reconciles the readOnlyHint=false annotation ('not marked read-only because each call is charged').

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

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

Front-loaded with the core action and scope, then usage, then pricing/error caveats. Dense but every clause carries information (direction, counterparty, amount, count, charge policy) 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 still outlines the return shape (direction, counterparty, amount, transaction, newest first, max 50) and covers errors, pricing, and network scope. 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 coverage is 100%, so all three parameters (address, token, blocks) are already documented, including the USDC default and the 1-2000 block range. The description largely restates those defaults, adding only marginal framing rather than new syntactic or semantic detail, 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 specific verb and resource ('List a wallet's recent transfers of one ERC-20 token ... on Base') with scope details (in/out, block window, newest first, up to 50). It explicitly distinguishes itself from the sibling base_token_balance by naming the alternative for current-balance queries.

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 concrete use cases ('confirm a payment arrived or see what was sent') and names the alternative tool with the condition that selects it ('for the current balance use base_token_balance'). Nothing about when to pick this over siblings is left to inference.

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

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

With readOnlyHint=false and openWorldHint=true already declared, the description goes further and explains the apparent anomaly: 'Reads or computes only; not marked read-only because each call is charged.' It also discloses the exact cost model ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), which is pricing behavior no annotation conveys.

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 purpose before the usage note, example, and pricing, and every sentence carries information. The long field enumeration in the opening sentence is dense but earns its place given there is no output schema, though it could be tightened slightly.

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

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

No output schema exists, so the description correctly carries the return-value burden by enumerating the fields returned. It also reconciles the annotations and discloses billing, leaving nothing an agent needs before calling 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?

Only one parameter, and schema coverage is 100% — the schema already specifies '0x followed by 64 hex characters'. The description's sample hash illustrates the format but adds no semantics 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 and resource ('Look up any transaction on Base by hash') and then enumerates exactly what is returned: status, sender/receiver, ETH value, method id, block, confirmations, gas, fee, contract creation. This distinguishes it from siblings like base_receipt or base_logs, which an agent can rule out 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 confirm that a payment or contract call went through before acting on it' gives a clear decision context and a concrete trigger. It stops short of naming an alternative (e.g. base_receipt) or stating when this tool is the wrong choice, so it is clear but not fully 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?

Explains the non-obvious annotation choice directly: 'not marked read-only because each call is charged,' which resolves the apparent tension between readOnlyHint=false and a pure read tool. It also discloses auth paths (x402 USDC or card key), pricing ($0.003/call, first 25 free), and that failed calls are free — behavior an agent cannot infer from the schema or annotations.

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

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

Front-loads the resource and return contents, then use cases, then example, then billing/auth caveats — a sensible information hierarchy with no filler. It is dense, and the pricing/auth sentence is arguably metadata rather than call guidance, but it is materially useful for deciding whether to invoke the tool.

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

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

With no output schema, the description carries the return-value burden and does so by listing the exact fields returned. Combined with address format, use cases, cost, and auth, an agent has everything needed to call and interpret this correctly.

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

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

Schema coverage is 100% and the single parameter is already documented with the same address-type notation, so the schema does the heavy lifting (baseline 3). The description adds a concrete worked example address, which slightly clarifies expected format beyond the schema's shorthand.

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 in sats and BTC, unconfirmed pending, total received/sent, and transaction counts. It also names the accepted address types (legacy, P2SH, bech32), which cleanly separates it from the sibling btc_fees tool.

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

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

Gives concrete usage contexts — payment verification, confirming a deposit arrived, wallet monitoring — which tells an agent when this is the right call. It does not explicitly state when to use a sibling instead (e.g. btc_fees for fee estimation), 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?

Goes well beyond the annotations by disclosing that the tool reads or computes only and explicitly explaining why readOnlyHint is false (each call is charged), which pre-empts an apparent contradiction. It also states cost ($0.002/call), payment paths (x402 USDC or card key), the 25-free-call allowance, and that failed calls are free.

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 returned data, then usage, then pricing/behavior in a tight three-sentence block with no filler. The opening sentence is long due to its output enumeration, but every clause carries distinct information.

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

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

An output schema exists, so return-value structure need not be re-explained, and the description still summarizes the key fields. Combined with the usage triggers, pricing, and the rationale for the non-read-only flag, nothing an agent needs before calling 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 4 applies. The description instead characterizes the shape of the response fields, which is a reasonable substitute.

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 resource (Bitcoin network fee rates) and enumerates the exact outputs: next-block, half-hour, one-hour and economy rates in sat/vB, sats cost of a typical payment, mempool size/pending fees, and latest block height. This is unmistakably distinct from btc_address or any of the chain-specific *_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 explicit trigger conditions: 'Use before sending a Bitcoin transaction or to decide whether to wait for lower fees.' That is a clear when-to-use, though it never names an alternative tool or a when-not-to-use case (e.g., historical fee lookups or 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?

Discloses data provenance ('read live from Ethereum mainnet'), full pricing model ('$0.002/call via x402 USDC or a card key, first 25 free; failed calls free'), and explicitly reconciles the readOnlyHint=false annotation by explaining it is a read/compute-only tool charged per call. This is exactly the kind of context annotations cannot convey.

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

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

Front-loaded with purpose and an example, followed by actionable pricing and behavior notes. Every sentence earns its place, though the pricing/annotation sentence is somewhat dense and could be slightly tighter.

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

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

With only one parameter, no output schema, and existing annotations, the description still covers return content (address/avatar or primary ENS name), data source, and cost model. 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 coverage is 100% and the single parameter is fully documented in the schema itself ('An ENS name such as vitalik.eth, or an address (0x...) for reverse lookup'). The description's example and dual-usage note add marginal value over 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 (resolve/look up) and resource (ENS name / address) and covers both directions: forward resolution (vitalik.eth → address and avatar) and reverse resolution (address → primary ENS name). An agent can immediately tell what this does versus the network-specific sibling tools like eth_balance or wallet.

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 when-to-use context: 'turn a human-readable name into a payable address' or 'show a readable name for a counterparty address.' This is concrete intent guidance, though it does not name a specific sibling alternative or state 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 annotations are counterintuitive (readOnlyHint=false for what is otherwise a pure read), and the description proactively explains the reason: each call is charged. It additionally discloses billing tiers (first 25 free, $0.003/call via x402 USDC or card key, failed calls free), which annotations cannot express. No contradiction with annotations.

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

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

Front-loaded with purpose, then usage, error handling, example, and pricing—each sentence carries selection-relevant information. The pricing clause is dense boilerplate but is decision-useful since cost affects tool choice.

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

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

With no output schema, the description still covers the return form (wei and ETH), input validation behavior, cost, and sibling alternatives. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by giving a concrete example address, stating 'any 0x address', and specifying that malformed addresses are rejected with 400 uncharged—relevant semantics not in the schema description.

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+scope: read the native ETH balance of a 0x address at the latest block, returned in wei and ETH. It explicitly differentiates from siblings (eth_token_balance for ERC-20, wallet_portfolio for all holdings), so an agent can select it 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?

Names the concrete use case (checking whether a wallet can pay gas or a transfer) and routes to explicit alternatives for adjacent cases. It also states failure behavior (malformed address rejected with 400, uncharged), removing ambiguity about the invalid-input path.

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 useful behavioral context beyond the annotations: non-existent blocks return 404 and are uncharged, the billing model (price, free tier, failed calls free), and it explicitly reconciles the readOnlyHint=false annotation by explaining it is a billing artifact, not a data mutation. It also states the tool reads/computes only.

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

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

Front-loaded with purpose, then usage, edge cases, billing, and the annotation caveat. Sentences are information-dense with no filler; relative to the sibling set the sizing is well matched.

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 the description carries the burden and does so: it lists returned fields, covers the error/edge case, states cost, and heads off the readOnlyHint misinterpretation. Complete for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds format detail ('decimal number'), confirms 'latest' is used when omitted, and supplies the example number=latest, adding modest value beyond the schema entry.

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 ('Fetch a block on Ethereum by decimal number, or the latest one when omitted') and enumerates the returned fields, so the agent knows exactly what this returns and how it differs from eth_gas and other eth_* 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 explicit when-to-use ('for timestamps and confirmation counts') and names the alternative with its selecting condition ('for current fees use eth_gas'). Nothing is left to inference.

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

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

Goes beyond the annotations by explaining the counterintuitive readOnlyHint=false ('Reads or computes only; not marked read-only because each call is charged'), and adds pricing and failure semantics ($0.003/call via x402 USDC or card key, first 25 free, failed calls free) that no structured field carries. This resolves a potential annotation misread, though it does not describe freshness/latency of the gas quote.

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 returned values, then usage routing, then billing caveats — a sensible order with no filler sentences. It is a dense single paragraph packing several distinct concerns, so slightly less scannable than it could be, but nothing is wasted.

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

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

There is no output schema, so the description carries the return-value burden and does so fully (which fields, what units, plus a concrete derived figure). For a no-input, no-annotation-help tool, an agent has everything needed to call it and interpret the 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?

Zero-parameter tool, so the baseline is 4. The description's 'Takes no input' is accurate and consistent with the empty schema, but adds nothing the schema does not already show.

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

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

States a specific verb and resource ('Get current gas on Ethereum') and enumerates exactly what is returned: gas price, base fee, suggested priority fee in gwei, plus the cost of a 21,000-gas ETH transfer. It is clearly distinguishable from the sibling gas tools on other chains (arb_gas, base_gas, op_gas) and from eth_receipt, which it names.

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 guidance ('Use before sending a transaction or to decide whether to wait') and an explicit when-not/alternative ('for the fee a past transaction actually paid use eth_receipt'). An agent can route correctly without opening any schema.

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 set readOnlyHint=false and the description proactively reconciles that apparent contradiction ('reads or computes only; not marked read-only because each call is charged'), which is exactly the disclosure an agent needs. It also adds pricing, the 400-on-malformed behavior, and the free-failed-call policy beyond what annotations carry.

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

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

Purpose and scope are front-loaded, and most sentences earn their place. The pricing/credits clause is somewhat dense and runs long, but it is operationally relevant for an x402-charged tool.

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

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

With no output schema, the description compensates by naming the returned signals (bytecode size, minimal-proxy detection, implementation pointer). Combined with error semantics, cost, and the sibling alternative, 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?

Only one parameter with 100% schema coverage, so the schema carries the burden; the description still adds value with a concrete example address and the rejection behavior for malformed input. It stops short of documenting format variants (e.g. EIP-55 checksum requirements).

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 a 0x address is a contract vs wallet) and enumerates what it returns: bytecode size, EIP-1167 minimal-proxy status, and implementation target. This clearly differentiates it from the sibling is_contract tools on other chains and from check_counterparty.

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 ('before sending funds or approving a spender') and names the alternative for a deeper need ('for a fuller risk verdict use check_counterparty'). The malformed-address handling and free-on-failure condition are stated outright.

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 openWorldHint=true, destructiveHint=false, idempotentHint=false and, importantly, readOnlyHint=false; the description adds the reason for that non-obvious flag ('not marked read-only because each call is charged') plus pricing, free-failure behavior and the return shape. That is real value beyond the annotations, though it stops short of describing pagination, log ordering, or reorg/confirmation semantics.

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

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

Front-loads purpose and scope, then the alternative, then cost/auth and safety rationale. Every sentence carries distinct information with no redundancy.

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

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

Covers what an agent needs to call it correctly and interpret the result: filter semantics, return cap, per-call cost, payment methods, free-failure behavior, and why the read-only hint is false. No output schema exists, but the return contents are summarized.

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 every parameter already carries a description, so the schema does the heavy lifting. The description adds only marginal meaning (topic0 as a 32-byte signature hash, the 1-1,000 block bound and default 50), which largely restates 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 ('List recent event logs a contract emitted on Ethereum') plus the scoping mechanism (last N blocks, topic0 filter). An agent can distinguish this from eth_receipt and the per-chain *_logs siblings 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 positive usage ('watch transfers or contract events') and an explicit alternative with its selecting condition ('for one transaction's outcome use eth_receipt'). The filtering condition for topic0 is also implied in context.

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

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

Adds substantial context beyond annotations: charges ($0.003/call, first 25 free, failed calls free), the 400-without-charge behavior on malformed addresses, and it proactively resolves the odd readOnlyHint=false by explaining 'Reads or computes only; not marked read-only because each call is charged.' It doesn't cover rate limits or latency, but the disclosure is unusually rich.

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

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

Purpose and scope are front-loaded in the first sentence, followed by usage, error behavior, example, and pricing in a compact paragraph. Nearly every clause earns its place, though the pricing/card-key clause adds some density.

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

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

With no output schema, the description still conveys the return value (transaction count, confirmed and pending), the cost model, and failure behavior for a single-parameter read tool. 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?

Schema coverage is 100% so the parameter is already documented as a '0x address'; the description still adds value with a concrete valid example and the error behavior for malformed input. It stops short of format details beyond the example, so it improves on the baseline 3 without being exhaustive.

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

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

States a specific verb and resource ('Read the transaction count (nonce) of a 0x address on Ethereum') and immediately scopes it ('both confirmed and including pending transactions'). It explicitly distinguishes itself from the adjacent eth_balance tool, so an agent can tell the two apart without opening either schema.

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

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

Gives two concrete use cases ('build the next transaction', 'tell whether an address has ever sent anything') and names the alternative tool for a different need ('for its balance use eth_balance'). The routing condition is explicit rather than inferred.

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: discloses the 404-without-charge behavior for pending/unknown hashes, that failed calls are free, the pricing model (x402 USDC / card key, first 25 free), and why readOnlyHint is false (each call is charged). This is exactly the extra context annotations cannot express.

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

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

Front-loads the resource and return fields, then the when-to-use routing, then billing semantics. Dense but every sentence carries information; the pricing block is verbose but operationally necessary for a paid tool.

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

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

With no output schema, the description lists what the receipt contains, covers the error path and billing, and gives a callable example. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds a concrete example hash and reinforces the required 0x-prefixed 64-hex format plus the runtime behavior for a bad/unknown hash. It slightly exceeds what the schema alone conveys.

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

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

Names a specific verb and resource ('Get the receipt of a mined Ethereum transaction') and enumerates the returned fields (status, gas used, effective gas price, fee, log count, contract created). It explicitly distinguishes itself from the sibling eth_tx, so an agent can route correctly without opening either schema.

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

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

States the use case ('confirm a payment or call went through') and names the alternative with its selection condition ('for sender, value and calldata use eth_tx'). Pending/unknown hashes are covered as an explicit failure mode.

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: it explains the non-obvious readOnlyHint=false ('not marked read-only because each call is charged'), discloses failure semantics with HTTP codes (404 no contract, 422 non-ERC-20), confirms failed calls are uncharged, and states pricing ($0.003/call, first 25 free, x402 or card key). This directly resolves the one annotation an agent would otherwise misread.

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 purpose and return shape, then usage, then error/pricing detail in descending order of importance; every clause carries information. The pricing and free-tier sentences are somewhat dense, but they are decision-relevant for an agent weighing a paid call.

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

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

There is no output schema, and the description compensates by naming the returned fields (raw amount, decimals, symbol, human-readable amount). Combined with error codes, cost semantics, and the parameter format constraint, nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is already 100%, so the baseline is 3, but the description adds a real constraint not in the schema: both inputs must be 0x addresses of exactly 40 hex characters. It does not, however, clarify which argument is the token versus the wallet beyond what the schema's own property descriptions say.

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 ('Read one wallet's balance of one ERC-20 token on Ethereum') and enumerates the returned fields. It explicitly distinguishes itself from the closest sibling by naming eth_balance as the tool for the native coin, so an agent can route correctly without opening either schema.

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

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

Gives the operative use case ('check stablecoin or token holdings before a transfer or trade') and an explicit alternative for the adjacent case ('for the native coin use eth_balance'). The when-to-use and the sibling-deflection rule are both stated outright.

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 annotations: explains the non-obvious readOnlyHint=false (reads only, but charged per call), gives the 422-on-non-ERC-20 error with 'uncharged' semantics, and states pricing, free tier, and that failed calls are free. This is exactly the context annotations cannot carry.

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

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

Front-loaded with purpose and fields, then usage routing, then input/error behavior, then cost. Every sentence carries distinct, necessary information with no filler.

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

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

With no output schema, the description still names the returned fields (name, symbol, decimals, total supply), plus error and pricing behavior. 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 coverage is 100%, so the baseline is 3, but the description adds the concrete 0x example address and the failure semantics for a non-ERC-20 address, both of which meaningfully extend the schema's terse '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 specific verb (look up) and resource (ERC-20 name, symbol, decimals, total supply) read live from the contract. Immediately distinguishes itself from eth_token_balance by naming it, and identifies the input as the token contract address.

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 gives both when-to-use (identify an unknown token address, format raw amounts) and when-not (holder balance → eth_token_balance). The routing condition between the two siblings is unambiguous.

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

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

With readOnlyHint=false the description goes well beyond the annotations: it discloses that malformed addresses return 400 uncharged, that pricing is $0.003/call via x402 or card key with the first 25 free and failed calls free, and it explains the non-obvious reason read-only is false (each call is charged). This is exactly the extra context annotations cannot carry.

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

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

The scoping and usage information is front-loaded and every clause carries unique information (scope, window, use cases, errors, price). It is a dense single paragraph rather than a structured list, which makes it slightly harder to scan, but 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?

There is no output schema, yet the description names the returned fields (direction, counterparty, amount, transaction), the ordering and the result cap, and it covers the error and cost behavior. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema lacks: the default token (USDC on this network), the result cap (up to 50), ordering (newest first), and the direction/counterparty/amount/transaction fields returned. It stops short of full detail but clearly exceeds the schema.

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

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

The description opens with a specific verb and resource ('List a wallet's recent transfers of one ERC-20 token ... on Ethereum, in and out') and pins the scope (single token, default USDC, block window). It explicitly contrasts itself with the sibling eth_token_balance, so an agent can route without opening either schema.

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

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

It states concrete use cases ('confirm a payment arrived or see what was sent') and names the alternative plus the condition that selects it ('for the current balance use eth_token_balance'). This is explicit when-to-use and when-to-use-something-else 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?

Explains the otherwise-puzzling annotation readOnlyHint=false ('not marked read-only because each call is charged'), and adds pricing ($0.003/call via x402 USDC or card key), a free tier (first 25 free), that failed calls are free, and that an unknown hash returns 404 uncharged. These are behavioral facts no annotation conveys.

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

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

Dense but front-loaded: purpose and returned fields come first, followed by routing rules, input format, example, and pricing. Every sentence carries information an agent needs; nothing is redundant 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 itself enumerates the return fields, so the agent knows what comes back. Combined with the routing guidance, input format, and error/pricing behavior, nothing required to call the tool correctly is missing.

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

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

Only one parameter and schema description coverage is 100%, so the baseline is 3. The description restates the 0x-prefixed 64-hex format consistently with the schema and adds a concrete example hash, which adds marginal value beyond the structured field.

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

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

States a specific verb and resource ('Look up a Ethereum transaction by hash') and enumerates exactly what is returned: sender, recipient, value in ETH, nonce, gas limit, function selector, and block. It explicitly distinguishes itself from the sibling lookup tools eth_receipt and eth_logs, so an agent can route without opening either schema.

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

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

Gives explicit when-to-use and points to named alternatives with their selection criteria: 'for success or failure and fees paid use eth_receipt, for emitted events eth_logs'. This is a complete routing rule rather than implied usage.

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: it discloses pricing ($0.003/call via x402 USDC or card key, first 25 free, failed calls free) and, crucially, explains WHY readOnlyHint is false ("not marked read-only because each call is charged"), reconciling a potentially confusing annotation. It also confirms the operation is compute-only with no destructive 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?

Front-loaded with purpose, then usage, then a concrete example, then pricing and the annotation rationale. Dense but every sentence earns its place — nothing is redundant given the billing and read-only nuance it must convey.

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 covers purpose, input forms, usage, cost, and safety. The one minor gap is that it never states the return format (e.g., 0x-prefixed 32-byte digest), which an agent would need for downstream chaining.

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

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

Schema coverage is 100%, so the single parameter is already documented, but the description adds a concrete worked example (text=transfer(address,uint256)) that meaningfully clarifies the expected input format for a hashing tool beyond the schema's generic wording.

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) plus the accepted input forms (text or 0x hex bytes) and the domain use (function selectors, event topics, storage slots). This cleanly distinguishes it from every sibling, which are all chain-specific RPC read 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?

"Use when building or decoding EVM calls" gives clear context for when to reach for this tool. No alternatives or exclusions are named, but none are needed since no sibling performs hashing — the only omitted routing detail is trivially implied.

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

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

Annotations set readOnlyHint=false, which would otherwise puzzle an agent; the description resolves this directly ('Reads or computes only; not marked read-only because each call is charged'). It also adds pricing behavior ($0.002/call, first 25 free, failed calls free) not in the annotations, covering auth/cost concerns.

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 return fields, then usage, pricing, and the read-only caveat. Every sentence carries distinct information with no redundancy.

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

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

No output schema exists, so the description enumerates the returned fields itself. Combined with usage, pricing, and safety semantics, an agent has everything needed to decide and 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?

With schema coverage at 100% and only one parameter, the schema already documents the 'invoice' string and its lnbc format. The description reinforces that decoding does not trigger payment, but adds no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('Decode') and resource ('BOLT11 Lightning Network invoice'), then enumerates exactly what is extracted (network, amount in sats and BTC, payment hash, creation/expiry time, expired status). It is unambiguously the only Lightning tool among a sea of EVM/BTC siblings, so differentiation is clear.

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 purpose-driven trigger: 'Use to check what an invoice asks for before an agent pays it.' That is a clear when-to-use condition. It stops short of naming a sibling alternative, but no competing decode tool exists in the sibling list, so the guideline is adequate.

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 annotations by explaining the counterintuitive readOnlyHint=false: 'Reads or computes only; not marked read-only because each call is charged.' It also discloses billing mechanics ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), which the annotations cannot convey.

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

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

Front-loaded with the resource and its contents, then usage, then cost. Two tight sentences with no filler; even the pricing clause carries information an agent needs to decide whether to call.

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

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

Although there is no output schema, the description enumerates the returned facts (chain id, USDC contract, decimals, explorer, RPC, x402 identifier), so an agent knows exactly what it will get. 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?

The tool takes zero parameters and the schema is an empty object at 100% coverage, so the baseline is 4. There is nothing parameter-level for the description to add 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 resource (Base mainnet reference facts: chain id, USDC contract/decimals, explorer, RPC, x402 network id) and its use case. It is trivially distinguishable from the many chain-operation siblings (base_balance, base_tx, etc.) since it takes no parameters and returns static configuration 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?

Explicitly says 'Use to configure an x402 or Base client,' which is a clear context for invocation and implicitly excludes the transaction/query siblings. It does not name a specific alternative or state when NOT to call it, 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 already declare the safety profile, and the description adds substantial non-duplicated context: pricing ($0.003/call, first 25 free, failed calls free), error semantics (malformed address returns 400 and is uncharged), and an explanation of the counterintuitive readOnlyHint=false ('not marked read-only because each call is charged'). That rationale is exactly the kind of value structured fields cannot convey.

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

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

Front-loaded with purpose before alternatives, pricing, and error behavior. Dense but every sentence carries information an agent needs; only the example address is marginally expendable.

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 one parameter, no output schema, and a narrow scope, the description covers everything required: what it returns (wei and ETH), when to prefer it, cost model, failure behavior, and the annotation rationale. No material gap remains.

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 required address parameter, so the baseline is 3. The description adds a concrete example address and specifies what happens on malformed input, which goes beyond the schema's terse '0x wallet or 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 precise verb+resource+chain+scope: native ETH balance of any 0x address on Optimism at latest block, returned in wei and ETH. It explicitly distinguishes itself from op_token_balance and wallet_portfolio, so an agent can route correctly without opening schemas.

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

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

Gives concrete use cases ('check whether a wallet can pay gas or a transfer') and names the two alternatives with the condition that selects each (ERC-20 -> op_token_balance, all holdings -> wallet_portfolio). Nothing is left to inference.

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

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

Annotations already declare the safety profile (readOnlyHint=false, openWorld=true, idempotent=false, destructiveHint=false), and the description goes further: it explains the non-existent-block path (404, uncharged), states that failed calls are free, and explicitly reconciles the read-only anomaly (reads/computes only, but not marked read-only because each call is charged). This is exactly the 'why' that annotations cannot express.

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

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

Front-loaded with verb+resource+return fields, then usage, then the edge case, then an example, then pricing. Every sentence carries a distinct fact (return set, alternative tool, failure semantics, cost model, read-only rationale) 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?

There is no output schema, so the description compensates by enumerating the returned fields. Combined with 404 behavior, pricing/charging semantics, and the read-only justification, an agent has everything needed to decide, call, and interpret 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 parameter is fully documented, so the baseline is 3. The description adds a real semantic constraint the schema omits: the number is 'decimal' (not hex), and restates the default (latest when omitted), which is useful on an EVM block-number field where hex is a plausible alternative.

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 (Fetch) and resource (a block on Optimism), names the retrieval key (decimal number, or latest when omitted), and enumerates the returned fields (hash, timestamp, tx count, gas, base fee, producer). It also distinguishes itself from the adjacent fee tool by naming op_gas, so an agent can separate it from siblings like op_tx/op_receipt 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 an explicit use case (timestamps and confirmation counts) and an explicit alternative with its selecting condition (for current fees use op_gas). It also notes the omitted-argument default, so both the when-to-use and the how-to-call paths are covered.

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: discloses per-call pricing ($0.003 via x402 USDC or card key), the 25 free calls, that failed calls are free, and explains the seemingly odd readOnlyHint=false ('not marked read-only because each call is charged'). That preempts an annotation contradiction and adds real behavioral context; only caching/pagination-style traits are absent.

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

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

Front-loaded with what it returns, then usage, then pricing and safety notes. Dense but each sentence carries distinct information; the pricing clause is slightly long but material for a paid tool.

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

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

No output schema exists, so the description carries the return-value burden and does so explicitly (price, base fee, priority fee, transfer cost). Combined with the pricing and read-only rationale, 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?

Zero parameters, so the baseline is 4; the description reinforces this with 'Takes no input.' There is no additional parameter meaning to convey 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 ('Get current gas on Optimism') and enumerates the returned values (gas price, base fee, suggested priority fee in gwei, 21,000-gas transfer cost). It also distinguishes itself from the sibling op_receipt by scope (current vs. past).

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 ('before sending a transaction or to decide whether to wait') and names the alternative with the condition that selects it ('for the fee a past transaction actually paid use op_receipt'). Nothing is left to inference.

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

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

Goes well beyond annotations by disclosing that malformed addresses are rejected with 400 and uncharged, that failed calls are free, that pricing is $0.003/call via x402 or card key, and why readOnlyHint is false despite being a read/compute operation. This resolves the apparent annotation tension 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?

Front-loads the core check, then adds usage, error behavior, example, pricing, and read-only nuance in a compact block. Every sentence supplies information an agent needs for correct invocation or cost-aware selection.

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

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

With no output schema, the description still covers the return content (bytecode size, proxy status, implementation). It also covers error handling, pricing, and the behavioral rationale for the annotation, leaving no major invocation 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 coverage is 100%, so the 'address' parameter is already documented structurally. The description adds a concrete example address and states the malformed-input consequence, which gives useful validation context beyond 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, resource, and chain scope: checking whether a 0x address on Optimism is a smart contract or a plain wallet. It also enumerates the distinguishing details returned (bytecode size, EIP-1167 minimal proxy status, implementation address), so the agent can separate it from sibling chain checks like eth_is_contract or arb_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?

Explicitly tells the agent when to use it ('before sending funds or approving a spender') and names an alternative for a fuller verdict ('use check_counterparty'). It also states what happens on bad input, removing ambiguity about the call path.

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 leave readOnlyHint=false puzzling for a read-style tool; the description explains it ('Reads or computes only; not marked read-only because each call is charged'), which resolves the apparent anomaly. It also discloses pricing ($0.003/call, 25 free, failed calls free) and the result cap (up to 100 logs with block, tx hash, topics), going well beyond the annotations.

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

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

Core purpose and block range are front-loaded, then filtering, return shape, alternative, and pricing in a logical order. The pricing/annotation sentence is dense but each clause (price, free tier, failed-call policy, read-only rationale) carries real 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?

Despite no output schema, the description covers return cardinality and fields, the filter option, the when-to-use alternative, and the full cost model plus the annotation rationale. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so blocks (1-1000, default 50) and topic0 are already documented. The description restates them and adds only a small semantic gloss on topic0 as the '32-byte event signature hash', 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 (List), resource (recent event logs), and scope (a contract on Optimism over the last N blocks), then explicitly names the sibling it is not (op_receipt). An agent can distinguish it from the ~60 sibling log/receipt 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?

Gives a concrete use case ('watch transfers or contract events') and an explicit exclusion with the alternative ('for one transaction's outcome use op_receipt'). Nothing is left to inference about when to pick this over a receipt call.

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

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

Goes well beyond the annotations: it discloses pricing ($0.003/call via x402 USDC or card key), the 25-free allowance, failed-calls-free policy, and the 400-on-malformed-address behavior without charging. It even explains why readOnlyHint=false despite the operation being a pure read — each call is billed — which preempts a confusing annotation. It lacks only deeper detail on return formatting or rate limits.

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

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

Front-loads the core purpose and uses every subsequent clause for a distinct piece of value: usage, alternative, error semantics, example, pricing, and the annotation rationale. Dense but not padded; a slight trim of the billing sentence would make it perfect.

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

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

No output schema exists, yet the description fully specifies what is returned (nonce, both confirmed and including pending), how failures behave, and what it costs — everything an agent needs to invoke and interpret the call. Complete 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?

Schema coverage is 100% and there is only one parameter, so baseline is 3, but the description adds a concrete example address and the validation contract (malformed input rejected with 400). That extra meaning about accepted format and failure mode lifts it above baseline.

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

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

States a specific verb and resource — read the transaction count (nonce) — scoped to Optimism and to a 0x address, and adds the confirmed-plus-pending dimension. It distinguishes itself from the many sibling nonce tools (eth_nonce, base_nonce, arb_nonce, polygon_nonce) by naming the chain and from op_balance by explicitly routing balance lookups elsewhere.

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; determine whether an address has ever sent anything) and names the alternative tool (op_balance) for the adjacent need. Nothing about when to reach for this tool is left to inference.

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

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

With annotations present, the description still adds substantial context beyond them: pending/unknown hash returns 404 and is uncharged, failed calls are free, pricing model, and an explicit explanation for why readOnlyHint=false ('not marked read-only because each call is charged'). This reconciles the annotation rather than contradicting it, which is high-value disclosure.

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

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

Purpose and return fields are front-loaded, followed by usage routing, error behavior, and pricing. Content is dense and mostly earns its place, though the pricing/example tail adds length that is only marginally actionable for tool selection.

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 the description correctly carries the return-value burden by enumerating receipt fields. Combined with error behavior (404), pricing, and the annotation rationale, an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds format reinforcement ('0x-prefixed 64-hex hash') and a concrete example value, which meaningfully helps an agent construct a valid call beyond the schema's field description.

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

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

States a specific verb+resource ('Get the receipt of a mined Optimism transaction') and enumerates exactly what the receipt contains: status, gas used, effective gas price, fee in ETH, event log count, and any contract created. It explicitly distinguishes itself from the sibling 'op_tx' for sender/value/calldata.

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 ('Use to confirm a payment or call went through') and names the alternative plus its scope ('for sender, value and calldata use op_tx'). This is a clear routing rule with no reliance on 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?

Goes well beyond the annotations by disclosing failure semantics (404 for no contract, 422 for non-ERC-20, both uncharged), pricing/free-tier behavior, and a rationale for readOnlyHint=false. The only gap is it doesn't describe pagination or freshness guarantees, but for a point-read that is minor.

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 purpose, then use case, then error/pricing behavior. Though dense, every clause carries information an agent needs (routing, error codes, cost), 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 compensates by naming the returned fields and the error outcomes, and it covers the cost model and safety rationale. An agent has everything needed to call it correctly and interpret the 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?

Schema coverage is 100%, so the schema already documents both parameters; the description adds the 40-hex-character 0x address format constraint, which is a modest but real value-add. Baseline 3 plus a small format detail yields 4.

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

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

States a specific verb and resource ('Read one wallet's balance of one ERC-20 token on Optimism') and even enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It explicitly distinguishes itself from the sibling op_balance for the native coin, so an agent can route without opening either schema.

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

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

Gives an explicit use case ('check stablecoin or token holdings before a transfer or trade') and names the alternative for the native coin ('use op_balance'), which is the key routing decision between siblings. Nothing about when to prefer this over op_token_info or op_balance is left to inference.

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

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

The description resolves an otherwise confusing annotation set: it explains that the tool is 'not marked read-only because each call is charged' and that failed calls are free, plus the 422-uncharged behavior for non-ERC-20 addresses. That is genuine added context beyond the annotation flags. It is not a 5 only because idempotency/retry semantics after a timeout are not addressed.

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 capability, then usage, then input/error semantics, then pricing. Nearly every sentence earns its place, though the pricing and free-tier details bulge the description for a one-parameter lookup tool.

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

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

There is no output schema, so the description must convey the return contents, which it does by listing the four metadata fields. Combined with error behavior, pricing, and the sibling alternative, an agent has everything needed to call this correctly.

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

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

With 100% schema coverage the baseline is 3, but the description adds a real example address and, more importantly, the semantics of an invalid input (non-ERC-20 address returns 422 and is uncharged). It does not document accepted address formats beyond 0x, but the value added over the schema is meaningful.

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

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

The description names a specific verb (look up) and resource (ERC-20 contract metadata on Optimism) and enumerates the returned fields (name, symbol, decimals, total supply). It explicitly contrasts itself with op_token_balance, so an agent can route correctly without opening either schema.

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

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

It states two concrete use cases (identifying an unknown token address, formatting raw amounts) and names the sibling tool to use instead when the goal is a holder's balance. When-to-use and the alternative are both explicit.

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

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

Annotations already declare non-read-only, non-idempotent, open-world, non-destructive, but the description goes well beyond them: it explains WHY readOnlyHint is false (each call is charged), documents pricing and payment paths, and states failure semantics ('malformed addresses rejected with 400, uncharged', 'failed calls free'). That is exactly the extra behavioral context a charged, stateful-looking call needs.

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 operation, scope, and ordering, then payment/pricing and failure rules in terse clauses. Every sentence earns its place — the pricing and 400-rejection notes are not padding for a paid endpoint.

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 (direction, counterparty, amount, transaction), ordering (newest first) and cap (up to 50), plus cost and failure behavior. Given the tool's complexity and its absence of an output schema, an agent has everything needed to call it and interpret the 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?

Schema description coverage is 100%, so the schema already documents token (0x ERC-20, default USDC) and blocks (1-2000, default 1000). The description restates those same ranges and defaults rather than adding syntax or edge-case meaning, so per the high-coverage baseline this is a 3. The only genuinely new constraint, the 'up to 50' result cap, is an output property rather than a parameter.

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

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

States a specific verb and resource — 'List a wallet's recent transfers of one ERC-20 token (default USDC) on Optimism, in and out' — plus scope (last N blocks, newest first, up to 50). It explicitly names op_token_balance as the tool for a different question, so an agent can distinguish it from siblings 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 concrete when-to-use triggers ('confirm a payment arrived or see what was sent') and names the alternative with the condition that selects it ('for the current balance use op_token_balance'). Nothing is left to inference.

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

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

Goes well beyond annotations by disclosing pricing ($0.003/call, x402 USDC or card key), the free tier (first 25 free, failed calls free), and error behavior (unknown hash returns 404, uncharged). It even reconciles a potentially confusing annotation, explaining that readOnlyHint=false exists because each call is charged, not because it mutates state.

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 purpose, then alternatives, then input contract, then pricing, so the most important information appears first. It is information-dense and slightly run-on with several semicolon-joined clauses, but every clause earns its place.

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

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

With no output schema, the description takes on the burden of describing the return payload and does so field by field. Combined with the input contract, error behavior, and cost model, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the 0x-prefixed 64-hex format is already documented and the baseline is 3. The description adds real value on top: a concrete example hash and the behavior for an unknown/invalid hash (404, uncharged), which the schema does not convey.

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 (look up) and resource (an Optimism transaction by hash), then enumerates the returned fields (sender, recipient, value, nonce, gas limit, selector, block). It explicitly distinguishes itself from op_receipt (success/failure, fees) and op_logs (events), so an agent can route without opening sibling schemas.

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

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

Gives explicit when-to-use ('see what was sent or whether it exists') and names both alternatives with the condition that selects them: op_receipt for success/failure and fees, op_logs for emitted events. No inference required.

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 pricing ($0.003/call, x402 or card key, first 25 free), failure semantics (malformed address -> 400 uncharged, failed calls free), and return format (wei and POL). Crucially it explains the seemingly odd readOnlyHint=false annotation ('not marked read-only because each call is charged'), converting a potential contradiction into clear behavioral context.

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

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

Front-loads purpose, then usage/alternatives, then example, then pricing/auth, then the readOnly rationale. Dense but every sentence carries distinct, non-redundant 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?

For a single-param read tool with no output schema, it covers everything an agent needs: what is returned (wei and POL), cost/auth model, error behavior, and correct routing against siblings.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by reinforcing the expected 0x format with a concrete example address and by documenting the validation outcome (400, uncharged) that the schema cannot express.

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), resource (native POL balance), and scope (any 0x address on Polygon PoS at the latest block, in wei and POL). It explicitly names the siblings it is not (polygon_token_balance, wallet_portfolio), so an agent can route 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 ('check whether a wallet can pay gas or a transfer') and two named alternatives with the selecting condition (ERC-20 -> polygon_token_balance, all holdings -> wallet_portfolio). Nothing is left to inference.

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

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

Annotations mark readOnlyHint=false and openWorldHint=true, and the description explains the non-read-only flag ('each call is charged') while adding pricing, free failures, and 404-uncharged behavior. This goes well beyond the annotations and does not contradict them.

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

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

The purpose and outputs are front-loaded, then usage, error semantics, example, pricing, and the read-only rationale follow in compact sentences. The length is justified by the paid-call and annotation-explanation 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 lists the returned fields (hash, timestamp, tx count, gas, base fee, producer) and covers default, error, charging, and free-call behavior. This is complete for calling the tool correctly.

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

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

Schema coverage is 100% and the schema already documents number/latest. The description adds format detail ('decimal number') and an example, but not enough to require a full 5.

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 verb ('Fetch') and resource ('a block on Polygon PoS'), including the default 'latest' and the returned fields. It also names polygon_gas as the alternative for current fees, so it is distinguishable from 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?

It explicitly states the use cases ('timestamps and confirmation counts') and redirects fee lookups to polygon_gas. The omission/default behavior for number and the 404 case are also described, leaving little 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, idempotentHint=false and openWorldHint=true; the description goes beyond them by reconciling the surprising non-read-only flag ('reads or computes only; not marked read-only because each call is charged'), and adds cost behavior ($0.003/call, x402 USDC or card key, first 25 free, failed calls free). That is exactly the kind of context annotations cannot express.

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

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

Front-loads the returned values, then usage, then the alternative tool, then pricing. Every sentence carries decision-relevant information (outputs, when to call, sibling routing, cost), 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?

There is no output schema, so the description must convey returns and does so precisely (gas price, base fee, priority fee in gwei, transfer cost). Combined with the explicit usage, sibling routing, and pricing disclosures, nothing needed to call this 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; the description confirms 'Takes no input,' matching the empty schema. There is no parameter syntax to add meaning to.

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 (current gas on Polygon PoS) and enumerates exactly what is returned: gas price, base fee, suggested priority fee in gwei, and a 21,000-gas POL transfer cost. It explicitly routes the sibling case ('for the fee a past transaction actually paid use polygon_receipt'), so an agent can distinguish it from polygon_receipt 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 ('before sending a transaction or to decide whether to wait') and names the alternative plus the condition that selects it (polygon_receipt for historical paid fees). Nothing is left to inference.

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

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

Goes well beyond annotations: explains the malformed-address path (400, uncharged), pricing model ($0.003/call via x402 USDC or card key, first 25 free, failed calls free), and explicitly reconciles the surprising readOnlyHint=false with the reason (per-call charging). This is exactly the context annotations cannot convey.

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

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

Front-loaded with the outcome, then usage, then error/pricing detail. Four clauses pack a lot without filler, though the billing sentence is dense and could be trimmed for an agent that only needs the call semantics.

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

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

With no output schema, the description still enumerates what comes back (bytecode size, EIP-1167 status, implementation address), and covers errors, cost, and the annotation rationale. Nothing material for calling it correctly is missing.

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

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

Schema coverage is 100% so the baseline is 3, and the description adds a concrete example address plus the malformed-input behavior (400, uncharged), which the schema does not state. Slightly above baseline, though the address format itself is left to the schema.

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

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

Specific verb (check) plus resource (0x address on Polygon PoS) and the exact output dimensions: bytecode size, EIP-1167 minimal-proxy detection, and implementation target. It is clearly distinguishable from sibling polygon_* tools and from check_counterparty, which it names.

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

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

States the triggering context ('before sending funds or approving a spender') and routes to the alternative ('for a fuller risk verdict use check_counterparty'). Both when-to-use and which-sibling are 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?

Adds substantial context beyond annotations: return cap of 100 logs, fields returned, the pricing model ($0.003/call, first 25 free, failed calls free), and directly explains the unusual readOnlyHint=false ('not marked read-only because each call is charged'). That reconciliation of annotation and behavior is exactly what a good description should do. It does not, however, describe rate limits or pagination for the 100-log cap.

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 purpose, scope and filter before the routing hint, which is the right ordering. Slightly heavy at the tail with a semicolon-chained payment/annotation rationale, though each clause carries real information.

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

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

With no output schema, the description covers the return shape (up to 100 logs with block, tx hash and topics), the query constraints, the alternative tool, and the billing semantics. An agent has everything needed to call it correctly and interpret the 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?

Schema coverage is 100%, so the baseline is 3, but the description upgrades the topic0 semantics by specifying it is a 0x 32-byte event signature hash rather than merely an 'event signature hash'. It also restates the blocks range and default, which is redundant with the schema rather than additive.

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 (List), resource (recent event logs), chain scope (Polygon PoS), and block window. It explicitly distinguishes itself from the sibling polygon_receipt, so an agent can select it without opening either schema.

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

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

Gives both the positive case ('use to watch transfers or contract events') and the exclusion with a named alternative ('for one transaction's outcome use polygon_receipt'). Nothing is left to inference.

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

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

Adds behavior beyond annotations: nonce includes confirmed and pending transactions, malformed addresses return 400 uncharged, and pricing/free-call details are stated. It also explicitly explains why readOnlyHint=false despite being read/compute only, resolving the annotation's apparent tension.

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

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

The description is front-loaded and every sentence carries operational information. It is slightly dense with pricing and example details for a one-parameter tool, but not wasteful.

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

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

Covers purpose, usage, error handling, payment model, and annotation rationale for a simple read/compute tool. With no output schema, it could be more explicit about the returned nonce format or whether confirmed and pending counts are separate, but the gap is minor.

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 schema already defines the single address parameter. The description adds an example 0x address and validation behavior (malformed address rejected with 400), which gives extra value but no additional format syntax.

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 transaction count (nonce) of a 0x address on Polygon PoS. It distinguishes its scope by naming polygon_balance as the tool for balance, so an agent can route correctly among chain-specific 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 concrete use cases: build the next transaction or determine whether an address has ever sent anything. It also names the alternative for balance (polygon_balance), leaving no inference needed about that sibling.

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: discloses that a pending/unknown hash returns 404 and is uncharged, that failed calls are free, and explains why readOnlyHint is false (each call is charged). This pricing/error/billing context is exactly the kind of behavior annotations cannot convey.

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

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

Front-loaded with the purpose, then usage/alternative, then input format, then billing and error semantics. Dense but every clause (404 uncharged, free failed calls, read-only rationale) carries actionable information for an agent.

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 burden of describing return fields (status, gas, fees, logs, contract created), input format, error behavior, and cost model. Nothing needed to invoke or interpret a call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description reinforces the input contract ('0x-prefixed 64-hex hash') and supplies a full concrete example hash. The worked example is real added value over the schema's generic format note.

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

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

States a specific verb and resource ('Get the receipt of a mined Polygon PoS transaction') and enumerates exactly what the receipt contains: status, gas used, effective gas price, fee in POL, log count, contract created. It explicitly distinguishes itself from the sibling polygon_tx by naming what that tool covers instead.

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 the triggering scenario ('Use to confirm a payment or call went through') and routes the agent to the alternative with its selection condition ('for sender, value and calldata use polygon_tx'). When-to-use and when-to-use-something-else are both 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?

Richly discloses behavior beyond the annotations: error semantics (404 no contract, 422 non-ERC-20, both uncharged), pricing ($0.003/call, first 25 free, failed calls free), and it explicitly reconciles the readOnlyHint=false annotation with the read-only nature ('not marked read-only because each call is charged'). This is exactly the kind of context annotations cannot carry.

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

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

Front-loads purpose, then usage/alternative, then input constraints, then pricing, then annotation rationale. Dense but every clause earns its place; no filler or restatement 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 still enumerates return fields; it covers inputs, error cases, cost model, and usage routing. 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 coverage is 100%, so the schema already documents both parameters (baseline 3). The description adds the format constraint ('Both inputs are 0x addresses (40 hex characters)') and ties the token parameter to error behavior (no contract 404, non-ERC-20 422), which is meaningful semantic value 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?

Specific verb plus resource: 'Read one wallet's balance of one ERC-20 token on Polygon PoS', and it enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It also distinguishes itself from the native-coin sibling (polygon_balance) and implies distinction from polygon_token_info, so an agent can route correctly without opening schemas.

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

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

Explicit when-to-use ('check stablecoin or token holdings before a transfer or trade') and names the alternative for the different case ('for the native coin use polygon_balance'). Conditions are stated, not left to inference.

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

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

Goes well beyond the annotations by disclosing the error behavior (422, uncharged), the fact that failed calls are free, the pricing model ($0.003/call via x402 USDC or card key, first 25 free), and explicitly explains the counterintuitive readOnlyHint=false ('not marked read-only because each call is charged'). This resolves what would otherwise look like an annotation 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?

Front-loaded with purpose, then usage, then mechanics, then pricing; the ordering is sensible and no sentence is redundant. It is dense and slightly long, with the pricing/credit sentence being the least essential part, but it still earns its place by answering cost questions.

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

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

No output schema exists, yet the description enumerates the returned fields (name, symbol, decimals, total supply), covers the single input, the failure mode, and the billing model. An agent has everything needed to call this correctly.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds the constraint type ('the token's 0x contract address') and a concrete valid example value, which is more than the schema's terse '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 specific verb and resource ('look up the name, symbol, decimals and total supply of an ERC-20 token contract on Polygon PoS') and explicitly names the sibling it is not for ('for a holder's balance use polygon_token_balance'). An agent can distinguish it from the rest of the polygon_* family 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 two concrete use cases ('identify an unknown token address', 'format raw amounts') and an explicit exclusion routing balance queries to polygon_token_balance. Also states the failure precondition: a non-ERC-20 address returns 422, uncharged.

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, which is unusual for a read tool; the description proactively explains why ('not marked read-only because each call is charged'), resolving the apparent anomaly. It further discloses error behavior (malformed addresses rejected with 400, uncharged), pricing and payment paths, free-tier terms, and result ordering/caps — well beyond what the annotations provide.

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

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

Purpose is front-loaded in the first clause, followed by usage, error, and cost information in a compact flow. It is dense — purpose, parameters, error handling, and pricing are packed into three sentences — but nearly every clause carries decision-relevant information for an agent deciding whether to call.

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

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

With no output schema, the description covers the returned fields (direction, counterparty, amount, transaction), ordering (newest first), the cap (up to 50), error semantics, and pricing. Nothing material for correct invocation 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 schema already documents the token default, block range, and address format, so the description's re-statement of defaults is largely duplicative. The only genuinely new detail is the result cap ('up to 50'), which is output-centric rather than parameter 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?

The description gives a specific verb and resource ('List a wallet's recent transfers of one ERC-20 token'), names the chain (Polygon PoS), the scope (in and out, last N blocks), and the default token (USDC). It explicitly distinguishes itself from the sibling polygon_token_balance, so an agent can route correctly 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 states the concrete use case ('confirm a payment arrived or see what was sent') and names the alternative tool plus the condition that selects it ('for the current balance use polygon_token_balance'). When-to-use and when-not-to-use are both covered.

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

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

Adds substantial context beyond annotations: pricing ($0.003/call via x402 USDC or card key), the free tier, that failed calls are free, and that unknown hashes return 404 uncharged. Critically, it reconciles the unusual readOnlyHint=false by explaining 'Reads or computes only; not marked read-only because each call is charged.'

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

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

Front-loaded with purpose and returned fields, then routing, then input, then pricing. Dense and every sentence carries information, though the pricing/credit sentence is slightly packed and could be separated.

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 the description enumerates the returned fields (sender, recipient, value in POL, nonce, gas limit, function selector, block), so an agent knows what it gets back. For a single-param lookup 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 coverage is 100%, so the description is not required to document the parameter. It nonetheless restates the 0x-prefixed 64-hex format and adds a concrete example hash plus the 404-on-unknown behavior, which adds modest value 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 (look up a Polygon PoS transaction by hash) and enumerates the returned fields. Explicitly distinguishes itself from polygon_receipt and polygon_logs, so an agent can route correctly without reading schemas.

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

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

Gives explicit when-to-use ('see what was sent or whether it exists') and names the two alternatives with the exact condition that selects each ('for success or failure and fees paid use polygon_receipt, for emitted events polygon_logs'). Also covers the unknown-hash case (404, uncharged).

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 explaining why readOnlyHint is false (each call is charged), disclosing pricing ($0.005/call, first 25 free, failed calls free), auth paths (x402 USDC or card key), and the nonce caveat for EOAs (outgoing txs only). This is genuinely useful behavioral context not present in 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 resource and return fields, then pricing and caveats. Dense but mostly earned; the middle section is a long run-on sentence stacking many clauses, which slightly hurts scanability.

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

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

With no output schema and no annotation coverage of pricing/account-type semantics, the description carries that burden and does so: it enumerates the returned fields, the account-type classifications, nonce semantics, and cost model. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so both params are already documented. The description nonetheless adds value by enumerating the default tokens checked (USDC, WETH, cbBTC, DAI, USDbC, cbETH, AERO, EURC) and reinforcing the 20-token cap for the `tokens` param.

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 live snapshot of an address on Base covering ETH balance, major token balances, up to 20 extra tokens, account nonce, and account type (EOA/contract/EIP-7702). The scope is concrete, but it never names the sibling primitives (base_balance, base_nonce, base_is_contract, base_token_balance) it aggregates, so an agent must infer the differentiation itself.

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

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

Gives an explicit use case ('Use to check a counterparty's holdings') and a negative scope ('not full transaction, token-transfer or trading history'). It does not, however, name an alternative tool or state when a granular sibling would be preferable to this aggregate.

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 the description proactively explains why ('not marked read-only because each call is charged') rather than contradicting them. It also discloses partial-failure semantics (a dead network yields an error entry, not a failed call), live reads per network, and pricing/free-failed-call behavior — rich context well beyond the annotation set.

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

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

Front-loaded with the core purpose, then alternatives, then failure behavior, pricing. Dense but every clause carries actionable information; the example address is the only mildly expendable element.

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 description covers purpose, alternatives, failure handling, and cost. The return shape is only sketched ('plus the USDC total'), but with no output schema this is a minor gap rather than a blocking one.

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 carries the semantics. The description adds only an example address value, which demonstrates format but adds little meaning beyond the schema's '0x wallet 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 specific verb+resource+scope: read native coin and USDC balances across five named networks in one call, plus a USDC total. It explicitly distinguishes itself from siblings (<chain>_token_balance for one token on one network, wallet_portfolio for all tokens on Base), so an agent can route 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 explicit usage context ('before a payment or bridge') and names two alternatives with the exact conditions that select them. Nothing is left to inference about when to pick this over the sibling tools.

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