Agent Data Tools: Chain data

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

Annotations cover safety (readOnly, non-destructive) but the description adds the pricing model ($0.01/call, first 25 free, failures free), the error contract (404 for missing contract, 422 for non-ERC-20, both uncharged), and explains why idempotentHint=false matters: 'each call is charged, so repeats are not free.' That is real value 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?

One dense paragraph, front-loaded with what/why, then input resolution, then pricing. Every sentence carries information, though the pricing sentence is long and could be split for 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?

No output schema exists, and the description compensates by naming the return fields (raw allowance, token-denominated allowance, unlimited flag). Combined with the error and pricing contract, an agent has everything needed to call this correctly and interpret results.

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

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

Schema coverage is 100%, so baseline is 3. The description still adds resolution semantics the schema lacks: token accepts a ticker or a 0x contract, with 404/422 behavior on bad input. It doesn't extend owner/spender meaning, but those are already well documented.

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

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

States a specific verb+resource+chain - ERC-20 allowance on Arbitrum One - and spells out the three returned facts (raw allowance, token units, unlimited flag). Explicitly distinguishes itself from arb_token_balance, which the sibling list confirms exists.

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 positive triggers ('check an approval before a swap', 'audit risky open approvals') and an explicit alternative with its condition ('for the owner's balance use arb_token_balance'). An agent can route without opening either 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 already declare readOnlyHint=true and destructiveHint=false, and the description adds substantive context beyond them: the read is at the latest block, results come in both wei and ETH, malformed addresses are rejected with 400 and not charged, pricing is $0.002/call with the first 25 free and failed calls free, and repeats are not free because each call is billed. The pricing/charging detail also operationalizes the otherwise puzzling idempotentHint=false.

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

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

The description is front-loaded with the core capability, then alternatives, error behavior, example, and pricing in a logical order with no filler. The clause 'reads or computes only and changes nothing' partially restates readOnlyHint, but the remaining sentences all earn their place given the pay-per-call model.

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 everything an agent needs: what is read, on which chain, at which block, in which units, what the address must look like, what happens on bad input, what it costs, and which siblings handle adjacent needs.

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 one parameter at 100% schema coverage, the schema already documents the address field. The description still adds value by constraining the format to 0x addresses, stating that malformed input is rejected with 400 rather than silently failing, and supplying a concrete example address. It stops short of noting contract-address behavior or checksum requirements, keeping it off 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?

The description names a specific verb and resource (native ETH balance of a 0x address), pins the chain (Arbitrum One), the underlying call (eth_getBalance), the block (latest), and the units returned (wei and ETH). It explicitly distinguishes itself from arb_token_balance and wallet_portfolio, so an agent can route correctly without opening the schema.

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

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

It gives a concrete use case (check whether a wallet can pay gas or a transfer) and names both alternatives with the condition that selects each: arb_token_balance for ERC-20, wallet_portfolio for all holdings at once. That is explicit when-to-use plus when-to-use-something-else.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description reinforces 'reads or computes only and changes nothing' rather than adding to it. However, it does add genuinely new behavioral facts the annotations cannot carry: a nonexistent block returns 404 uncharged, and failed calls are free, which matters for retry strategy. The pricing detail ('$0.002/call', 'first 25 free') explains why idempotentHint=false ('repeats are not free'), making the non-idempotent hint concrete. With annotations covering the safety profile, this lands at a solid mid-range: useful additions but no return-shape or pagination detail.

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 usage routing, then error/pricing edge cases in decreasing priority – a good ordering. It is slightly long: 'each call is charged, so repeats are not free' restates 'Price $0.002/call' and the pricing block sits inside the same sentence cluster as the functional description.

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 listing the returned fields (hash, timestamp, tx count, gas used/limit, base fee, producer) and covers the error path (404, uncharged) and cost model. What is missing is minor: no detail on units beyond gwei, and no note on how base fee behaves on a nonexistent future block beyond the 404.

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 as 'Block number, or latest (default)'. The description does add one thing the schema omits: the number must be decimal, and 'number=latest' confirms the accepted sentinel. That is a real but small increment over a fully documented 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 ('Latest block number and block details on Arbitrum One, or any block by decimal number') and enumerates the returned fields, so the agent knows exactly what it gets. It also names the chain and the sibling it is not (arb_gas), distinguishing it from both same-chain and cross-chain (eth_block, base_block) lookalikes.

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 routes the agent: 'Use for timestamps and confirmation counts; for current fees use arb_gas.' That is a named alternative plus the condition that selects it, so no inference is 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?

Annotations already declare readOnly/openWorld/non-destructive/non-idempotent, so the bar is lower, but the description still adds real context: 8 KB calldata cap, reverts return 422 with the reason and are uncharged, execution pinned to the latest block, and the pricing model ($0.01/call, first 25 free). The 'repeats are not free' note is consistent with idempotentHint=false 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-loaded with what the tool is and when to use it, and every sentence contributes (limits, pricing, revert behavior). It is a single dense paragraph and the pricing/credits detail is slightly over-weighted relative to its selection value, keeping it just under 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?

No output schema exists, and the description discharges that burden by explaining the return is raw undecoded return data that must be decoded with the function's ABI. Together with block semantics, revert behavior, and cost, an agent has everything needed to invoke and interpret the result 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 baseline would be 3, but the description adds meaning beyond the schema: the calldata format is spelled out (4-byte selector plus arguments) and demonstrated with a real selector, and the 8 KB size limit is only stated here. The optional 'from' parameter is left to the schema, which is acceptable given full coverage.

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-only contract call on Arbitrum One (eth_call)') plus the exact scope: ABI-encoded calldata to a contract at the latest block, raw return data, no transaction or gas. It also distinguishes itself from the family of dedicated readers like arb_token_balance/arb_token_info by saying it covers 'any view function that has no dedicated 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?

Explicitly routes the agent: use this for view functions lacking a dedicated tool, and the concrete example (USDC totalSupply, selector 0x18160ddd) shows the intended call shape. Cost and retry conditions (charged per call, repeats not free, failed calls free) are stated, which is the practical guidance an agent needs 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 already cover read-only, non-destructive, non-idempotent, open-world, but the description adds genuinely new behavior: reverting transactions return 422 with the reason and are uncharged, and each successful call is billed so repeats are not free. The pricing/payment path (x402 USDC, card key, first 25 free) further clarifies cost consequences. Only the precise response shape for success is left implicit, which is minor for a no-output-schema 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 the verb and resource, then inputs, then alternatives, then behavior and pricing — a sensible ordering with no filler sentences. It is slightly long, and the payment/billing block is dense, but every clause carries actionable information.

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

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

For a four-parameter, read-only estimator with no output schema, the description covers what is returned (gas units, gwei, ETH), the failure mode (422 with revert reason, uncharged), the cost model, and which sibling to use instead. Nothing an agent needs in order 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 the baseline is 3, but the description adds real nuance: value is expressed in ETH and the sender is required only when the call depends on it. The inclusion of a concrete example address (to=0x...dEaD) also anchors the expected address format beyond the schema's generic '0x recipient 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 specific verb and resource — estimate gas for a transaction on Arbitrum One — and names the underlying method (eth_estimateGas) plus exactly what is returned (gas units, gwei, ETH cost). It explicitly distinguishes itself from the sibling arb_gas, which only reports gas price, 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 concrete when-to-use triggers ('before sending a transaction or to price a batch') and an explicit when-not/alternative ('for the gas price alone use arb_gas'). It also states the preconditions for inputs ('sender when the call depends on it'), 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?

Adds real context beyond the annotations: cost per call ($0.002 via x402 USDC or card key), a 25-call free tier, failed calls free, and that repeats are charged — which usefully explains the idempotentHint=false in billing terms. It also restates that the tool reads/computes only and changes nothing, which the readOnlyHint already 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 resource and returned values, then usage, then billing. Dense but every clause carries information; the pricing/free-tier sentence is the longest and is only marginally over-explained for a single call decision.

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

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

With no output schema, the description correctly enumerates the returned fields and adds the practical 21,000-gas cost framing. The one gap is that the optional `only` projection is never mentioned and is actively denied, leaving the answer slightly incomplete relative to the actual response shape.

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 `only` filter is fully documented in the schema, but the description asserts 'Takes no input,' which is inaccurate for a tool that accepts an optional `only` projection parameter. That statement could cause an agent to skip a useful result-slimming option, so it falls below the baseline-3 case where the description is merely silent.

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 price on Arbitrum One') and enumerates exactly what is returned: gas price, base fee, suggested priority fee in gwei, plus the 21,000-gas transfer cost. That detail distinguishes it cleanly from arb_gas_history (historical) and arb_estimate_gas (per-transaction estimation).

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 ('before sending a transaction or to decide whether to wait') and names the alternative for the adjacent need ('for the fee a past transaction actually paid use arb_receipt'). Nothing is left to inference about which sibling to pick.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, but the description adds substantive context beyond them: the pricing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and the clarification that each call is charged so repeats are not free — which explains the otherwise puzzling idempotentHint=false. It could have gone further on latency or response size, but the cost and repeat-charging disclosure is genuinely useful.

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?

It is front-loaded with what the tool returns, then usage, then cost — a sensible order with no filler sentences. It is dense and slightly long, and the blocks example is largely redundant with the stated default, which keeps it from 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?

There is no output schema, but the description compensates by enumerating the returned metrics (per-block base fee, fill ratio, percentile priority fees, window low/average/high), so an agent knows what comes back. Combined with cost, safety, and the arb_gas alternative, it is nearly complete; only things like pagination or per-block metadata limits are unaddressed.

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

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

Schema description coverage is 100% and the single parameter already documents 'How many recent blocks, 5-100 (default 20)'; the description restates that range and default verbatim rather than adding new meaning. The 'Example: blocks=20' adds little since 20 is already the default. Baseline 3 applies when the schema carries the parameter documentation.

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 chain (Arbitrum One), a specific RPC method (eth_feeHistory), and enumerates exactly what is returned: base fee in gwei per block, block fullness, 10th/50th/90th percentile priority fees, and low/average/high base fee over the window. It explicitly distinguishes itself from the sibling arb_gas, noting that tool is for the current price alone.

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 three concrete use cases (judge whether fees are rising, pick a priority fee, time a transaction) and names the alternative for the current-price case: 'for the current price alone use arb_gas'. This is an explicit when-to-use plus when-to-use-something-else routing statement.

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

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

Beyond the readOnly/openWorld annotations, the description discloses pricing ($0.01/call, first 25 free, failed calls free), that malformed input returns 400 uncharged, and that repeat calls are billed, which usefully explains the otherwise surprising idempotentHint=false. It omits return-format details such as the field names the agent will receive.

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 facts are front-loaded, followed by usage guidance and then commercial/error details in a logical order. The pricing and free-tier clauses are dense but each supports a real agent decision, so there is little true waste.

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

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

There is no output schema, and the description largely compensates by naming the results (contract vs wallet, bytecode size, proxy type, implementation). It stops short of describing the actual response shape and does not mention whether unverified or precompile addresses are handled, which is a modest gap for a one-parameter read tool.

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

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

With only one parameter and 100% schema coverage, the schema carries the baseline; the description still adds value by providing a concrete example address and stating the validation outcome for a malformed address. Chain scoping (Arbitrum One only) is another useful constraint not present in the schema.

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

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

The description states a specific verb (check whether), a specific resource (a 0x address on Arbitrum One), and the returned facts (bytecode size, EIP-1167 minimal-proxy status, implementation address). It does not explain how it differs from the sibling arb_proxy, which also inspects proxy/implementation relationships, so sibling differentiation is incomplete.

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

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

It gives a concrete decision context (before sending funds or approving a spender) and points to an alternative for a fuller risk verdict. The weakness is that the named alternative, check_counterparty, is not among the sibling tools listed, so the routing pointer may not resolve for an agent.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses result limits (up to 100 logs, block lookback 1–1,000 default 50), the shape of returned fields (block, tx hash, topics), and pricing/billing behavior (per-call charge, first 25 free, failed calls free, repeats not free). The note that repeats are not free is precisely the kind of behavior an agent needs to avoid redundant calls, which the annotations alone could not 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?

Purpose and method are front-loaded in the opening clause, with limits, returns, alternatives, pricing, and safety trailing in a logical order. It runs long, and folding the pricing and example into the same paragraph makes it denser than necessary, but no sentence is truly wasted 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 three-parameter read-only tool with no output schema, the description covers inputs, return shape, caps, and cost, which is enough to call it correctly. The one minor gap is not saying what happens when a block window matches more than 100 logs (silent truncation vs. error), but the stated cap gives the agent enough to plan around 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 all three parameters already carry descriptions, making the baseline 3. The description adds only marginal value — clarifying topic0 as a 32-byte event signature hash and providing a concrete address example — while the blocks range/default merely 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?

The description names a specific verb and resource ('Recent contract event logs on Arbitrum One'), ties it to the underlying RPC method (eth_getLogs), and states the scope (last N blocks, topic0 filter, up to 100 logs). It also distinguishes itself from the nearest sibling by pointing to arb_receipt for single-transaction outcomes, so an agent can separate it from arb_tx/arb_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?

It gives explicit usage context ('Use to watch transfers or contract events') plus an exclusion with a named alternative ('for one transaction's outcome use arb_receipt'). The only weakness is that 'watch transfers' could also route to arb_token_transfers, which is not acknowledged, leaving a small ambiguity in the guidance.

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

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

Annotations already cover read-only/no-destroy/open-world status, but the description adds real value beyond them: error contracts (404 missing contract, 422 non-ERC-721, both uncharged), pricing ($0.01/call via x402 or card key, first 25 free, failed calls free), and that repeats are billed — consistent with idempotentHint=false. It never states the response shape beyond name/symbol, and doesn't mention rate limits, which keeps it shy of a 5.

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

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

Front-loaded with the core operation and the sibling disambiguation, then error and billing facts. Dense but mostly earned; the pricing/charging sentences are the longest portion relative to the operation's simplicity, so not perfectly tight.

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 discloses what comes back (balance plus collection name and symbol), the two failure modes and their billing treatment, and the prerequisite that both arguments are 0x addresses. 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; the description still adds meaning by saying both inputs are 0x addresses and that the contract must be a valid ERC-721 collection (else 422), which ties the parameter to a failure mode. It adds no format examples or distinctions beyond that.

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: counts how many NFTs of one ERC-721 collection a wallet holds on Arbitrum One (balanceOf), plus returns collection name and symbol. Explicitly distinguishes itself from arb_nft_owner ('for who holds one token id use arb_nft_owner'), so an agent can pick between the two 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 two concrete use cases (gate check before a token-gated action; verifying a wallet still holds a collection) and routes the alternative case (who holds a specific token id) to arb_nft_owner. Both when-to-use and when-not-to-use are 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?

Goes well beyond the annotations: it discloses output truncation for strings over 1,000 chars (e.g. on-chain SVG), 422-uncharged for nonexistent tokens, metadataError for unreachable metadata, the ipfs.io gateway path, and the $0.01/call price with a 25-call free tier. The note that repeats are charged is consistent with idempotentHint=false and explains the cost model annotations cannot express.

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

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

The capability and its distinguishing scope are front-loaded, then behavior, error cases, example, and pricing in a sensible order. It is dense and the pricing/cost sentence is long, but no sentence is filler.

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

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

There is no output schema, so the description carries the return contract — it names the returned fields, the truncation rule, and the metadataError signal. Combined with the error and pricing notes, an agent has everything needed to 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%, so the baseline is 3; the description adds a concrete worked example (contract=0xC364...FE88, tokenId=1) that fixes the expected address and token-id format for call construction. It does not add further constraints beyond that, so it lands just 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 — reads the tokenURI and the resolved JSON metadata (name, description, image, attributes) for one ERC-721 token id on Arbitrum One. It also names the sibling it is not (arb_nft_owner) and its chain-specific scope, so an agent can distinguish it from eth_/base_/op_/polygon_nft_metadata 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?

"Use to show or check what an NFT is; for its owner use arb_nft_owner" gives an explicit when-to-use plus the routing alternative. It also names the supported metadata sources (data:, https, ipfs://) so an agent knows which tokens it can resolve.

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

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

Annotations already declare read-only, non-destructive, open-world. The description adds genuinely new behavior: 404 for a missing contract, 422 for a nonexistent token, both uncharged; $0.01 per call via x402 or a card key with the first 25 free and failed calls free; and repeats are re-charged, which explains the non-idempotent hint. It stops short of describing return shape ordering or chain-reorg caveats, so a 4 rather than 5.

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

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

Front-loaded with the definition, then alternatives, then error/pricing facts — a logical order with no filler. It is dense and slightly overpacked (example and pricing detail in the same breath as semantics), keeping it just under 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 still names the returned data (owner wallet, collection name and symbol), covers failure modes, and states the 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%, so the baseline is 3; the description still adds value with a worked example (a real Uniswap V3 position-manager contract plus tokenId=1) that shows the expected address format and that tokenId is a bare integer. It doesn't explain edge cases such as burned tokens or non-ERC-721 contracts, so it stays at 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+resource: returns the owner (ownerOf) of one ERC-721 token id on Arbitrum One, plus the collection name and symbol. It explicitly contrasts with arb_nft_balance and arb_nft_metadata, so an agent can pick 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 concrete occasions to use it (verifying a holder before a trade, mint gate, or airdrop) and names the two sibling alternatives with the condition that selects each. 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 the supplied annotations: malformed addresses are rejected with 400 and not charged, pricing is $0.01/call via x402 USDC or a card key with the first 25 free, and failed calls are free. It also explains the practical consequence of idempotentHint=false — each call is billed, so repeating it is not free — which 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 the definition, then uses, then the sibling pointer, then failure/pricing notes, then the example — a sensible ordering with little filler. It is dense but each sentence carries operational information; the example and pricing sentence could be trimmed for a tighter read but they earn their place for an agent that must budget calls.

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 should clarify what comes back; 'both confirmed and including pending transactions' strongly implies two counts but leaves the exact shape slightly ambiguous. Everything else an agent needs — chain, input format, cost, error behavior, safety profile — is present.

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

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

Schema coverage is 100% and there is only one parameter, so the baseline is 3; the description still adds value by demonstrating the exact address format with a worked example and by specifying the failure mode for a malformed address. It does not add syntax details beyond that, so it sits just 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) of a 0x address') and pins the chain ('on Arbitrum One'), which is what distinguishes it from the many sibling *_nonce tools for other networks. It also scopes the result ('both confirmed and including pending transactions'), so an agent knows exactly what it retrieves.

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; detect whether an address has ever sent anything) and routes the balance question to the sibling arb_balance. It stops short of explicit exclusions, such as when to prefer arb_tx or arb_receipt for historical transaction detail, so it falls under 'clear context, no exclusions' rather than a full 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so safety framing is partially redundant rather than additive. What the description genuinely adds is cost behavior (per-call charge, repeats not free, failures uncharged) and the failure taxonomy (400 malformed vs 404 no code) — useful, but the pricing paragraphs are commercial boilerplate that wouldn't change a tool-selection decision. It stops short of saying what the response contains beyond 'names the kind found'.

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 capability and the alternative routing are front-loaded in the first two sentences, which is the right ordering. Efficiency is slightly hurt by three clauses of payment/credits detail at the end that most callers won't act on, but nothing is genuinely redundant.

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

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

With no output schema, the description still indicates the return content ('names the kind found') and lists the proxy standards checked, which is enough to set expectations. Failure modes and cost are covered; only the exact shape of the response is left to discovery, a minor gap for a single-parameter read tool.

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

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

Only one parameter and schema description coverage is 100%, so the schema already carries the meaning and the baseline is 3. The description does add a concrete address example and implicitly ties the parameter to the Arbitrum chain, which is modest added value, but no format constraints beyond the schema's '0x 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 ('Find the implementation behind a proxy contract on Arbitrum One') and enumerates exactly which storage slots / bytecode patterns it inspects, so an agent knows the precise capability. The chain is named, which separates it from the eth_proxy/base_proxy/op_proxy/polygon_proxy siblings despite the parallel naming scheme.

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-to-use condition ('before trusting or decoding a contract whose code can be swapped by its admin') and an explicit alternative with a selection rule ('for a fuller risk verdict use contract_risk'). The 400/404 semantics also tell the agent what failure looks like without trial and error.

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

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

Beyond the readOnly/openWorld/non-idempotent annotations, the description adds important operational context: pending hashes return 404 uncharged, failed calls are free, pricing is $0.01/call via x402 or card key, and repeats are charged again. These are material behavioral and billing details an agent should know before calling.

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 return content are front-loaded, and the description is dense but readable. Some clauses repeat annotation-level facts, such as read-only behavior and non-free repeats, but the extra pricing and error details generally earn their place.

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

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

For a one-parameter tool with no output schema, the description supplies enough detail: it enumerates the receipt fields, explains the 404 case, and discloses billing behavior. An agent has what it needs to call and interpret 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 single hash parameter is already well documented. The description still adds a concrete example and clarifies that a pending or unknown hash produces a 404 rather than a normal receipt, which is useful handling semantics beyond the schema.

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

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

The description states a specific resource and chain (transaction receipt on Arbitrum One / eth_getTransactionReceipt) and enumerates the returned fields: status, gas used, effective gas price, fee, logs, and contract creation. It explicitly distinguishes itself from arb_tx by saying sender, value, and calldata belong there.

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

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

It gives an explicit use case — confirming that a payment or call went through — and names arb_tx as the alternative for sender/value/calldata. It also explains the pending/unknown-hash case as a 404 response.

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

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

Beyond the annotations (readOnly/openWorld/non-destructive/non-idempotent), the description adds material operational facts: malformed address or slot returns 400 and is uncharged, failed calls are free, and each successful call is charged so repeats are not free. It also discloses the dual return representation. This is real context rather than restatement.

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 shape, then usage, errors, pricing in a sensible order. Slightly redundant at the tail: 'each call is charged, so repeats are not free' restates the earlier 'Price $0.01/call' clause and could be trimmed.

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

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

No output schema exists, and the description compensates by describing the returned 32-byte word in both numeric and address form. Combined with 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%, so the baseline is 3; the description earns an increment by explaining that a slot may be a decimal index or a 0x 32-byte key and that keyed form is used for mapping and proxy slots — meaning the schema does not convey. It also supplies a concrete address example.

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

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

States a specific verb and resource: 'Read one raw storage slot of a contract on Arbitrum One (eth_getStorageAt)'. It also pins the return shape (32-byte word as number, and as address when applicable), which lets an agent distinguish it from arb_call, arb_balance, and the other arb_* readers 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?

Explicitly names the use case ('contract state that has no getter, owners or implementation pointers') and routes the proxy case to the sibling: 'for proxies use arb_proxy'. Both when-to-use and when-to-use-something-else are 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?

Goes well past the annotations: discloses pricing ($0.01/call via x402 or credits, first 25 free, failed calls free), error semantics (404 for no contract, 422 for a non-ERC-20 contract, both uncharged), and confirms nothing is mutated. 'Each call is charged, so repeats are not free' also explains the otherwise puzzling idempotentHint=false.

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 result shape and the sibling distinction, which is the right ordering, and every clause carries information. It is a dense single paragraph with mild redundancy — pricing is stated and then restated as 'each call is charged, so repeats are not free'.

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

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

With no output schema, the description correctly compensates by describing the return fields, and it covers errors, cost, and the sibling alternative. The only substantive gap is the mischaracterization of the token parameter's accepted forms, which is the one thing an agent could get wrong when calling.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add the 40-hex-character address format, but its claim that 'Both inputs are 0x addresses' conflicts with the schema's token parameter, which accepts tickers like USDC or WETH — an agent reading only the prose could wrongly reject a ticker input.

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

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

States a specific verb and resource (fetch an ERC-20 balanceOf result for a wallet on Arbitrum One) and enumerates exactly what comes back: raw amount, decimals, symbol, human-readable amount. It explicitly separates itself from arb_balance for the native coin, so an agent can pick it over the dozens of sibling *balance tools without opening any schema.

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

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

Gives a concrete use case ('check stablecoin or token holdings before a transfer or trade') and names the alternative with the condition that selects it ('for the native coin use arb_balance'). None of the other 90+ siblings are confused with it.

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

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

Annotations already declare readOnly, non-destructive, open-world, non-idempotent; the description adds pricing ($0.01/call, 25 free), that failed calls are free, and that repeats are not free — which explains the otherwise puzzling idempotentHint=false on a read. It does not mention caching or latency, a minor gap.

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

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

Front-loads what is returned and how to use it, then pricing and error semantics. Dense but every sentence carries information; the final sentence bundles read-only, charge, and repeat-nonfree facts a bit tightly.

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) and covers the single input's two forms, error behavior, and cost — 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 baseline is 3; the description adds that a bare ticker is accepted as well as a 0x address and supplies a worked example address, clarifying input flexibility beyond the schema's one-liner.

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 Arbitrum One') and scopes it to a chain, so it is clearly distinguishable from the dozens of sibling *_token_info 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?

Gives both positive use cases (identify an unknown token address, format raw amounts) and an explicit alternative with its condition ('for a holder's balance use arb_token_balance'), plus the failure case (non-ERC-20 address returns 422).

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 the annotations: result cap of 50, newest-first ordering, default token, and the crucial clarification that repeats are not free because billing — not state — drives idempotentHint=false. The only gap is that it doesn't say what an empty result or a token with no transfers looks like, but the read-only/non-destructive profile is fully consistent.

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 and every clause carries information (scope, ordering, cap, alternative, error path, pricing). It is dense to the point of being a single run-on block, and the pricing/credits tail is longer than most agents need.

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 enumerating the returned fields (direction, counterparty, amount, transaction) and their ordering and cap. Inputs, caveats and cost model are all covered, so 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 baseline is 3; the description earns extra by restating the blocks range (1-2,000, default 1,000), the USDC token default, and giving a concrete checksummed address example. It doesn't clarify ticker-vs-contract resolution edge cases, which stays in 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 a wallet's recent transfers of one ERC-20 token'), plus chain, direction (in and out), window and result cap. It also names the sibling it is not (arb_token_balance for current balance), 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?

Explicit when-to-use cases ('confirm a payment arrived or see what was sent') and an explicit alternative ('for the current balance use arb_token_balance'). It even covers the failure path: malformed addresses are rejected with 400 and 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 already declare readOnly, non-destructive, open-world, non-idempotent, so safety is covered. The description still adds real behavioral context: unknown hash returns 404 uncharged, failed calls are free, each successful call costs $0.01 via x402 USDC or card key, and the first 25 are free. It does not describe the response envelope or field types, which is the main remaining gap. A 3 reflects solid but incomplete disclosure beyond 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 and alternatives, then input format, then pricing. Dense but every clause carries information. The pricing and example sentences make it longer than average, though they earn their place for a paid endpoint; minor run-on quality keeps it from 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?

There is no output schema, so the description compensates by listing exactly which fields come back. Combined with the input format, error behavior, and cost model, an agent has everything needed to call it and interpret the result without further context.

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 as a 0x-prefixed 64-hex hash, so the baseline is 3. The description reinforces the format and supplies a concrete example hash plus the 404-on-unknown consequence, which helps validation, but adds no new syntactic or semantic dimensions 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 ("Look up an Arbitrum One transaction by hash") and enumerates the returned fields: sender, recipient, value in ETH, nonce, gas limit, 4-byte selector, block. It explicitly names the sibling tools arb_receipt and arb_logs as the places to go for complementary data, so the agent can discriminate 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 a positive use case ("see what was sent or whether it exists") plus explicit routing rules: use arb_receipt for success/failure and fees, arb_logs for emitted events. No alternative is left implicit among the many *_tx/*_receipt/*_logs siblings.

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

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

Annotations already cover readOnly/destructive/openWorld, but the description adds real context beyond them: the $0.01/call x402 USDC or card-key billing, the first 25 calls free, failed calls free, and that repeats are charged — which explains the non-obvious idempotentHint=false in economic rather than state terms. Only gap is that it does not detail casing/rounding of the returned units, which 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 the definition and use cases, then error codes, then pricing — a sensible information order where every sentence carries actionable content. Slightly dense with several clauses in one paragraph, and 'reads or computes only and changes nothing' partly restates readOnlyHint=true.

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?

Only 3 required params, no nested objects, no output schema — yet the description still tells the agent what comes back (raw and human-unit allowance, unlimited flag) and what errors to expect. 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?

Schema coverage is 100%, so baseline is 3; the description earns an extra point by adding meaning beyond the schema — the ticker-or-0x-contract duality of 'token' is tied to concrete error outcomes (404 for missing contract, 422 for non-ERC-20), which the schema does not state. It doesn't add anything for 'owner' or 'spender' beyond the schema's own descriptions.

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

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

States a specific verb+resource: reads ERC-20 allowance on Avalanche (owner → spender), and even enumerates the return values (raw amount, token units, unlimited flag). It explicitly names the sibling it is not ('for the owner's balance use avax_token_balance'), so an agent can route between avax_allowance and avax_token_balance 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 when-to-use cases ('check an approval before a swap', 'audit risky open approvals') plus an explicit exclusion pointing to avax_token_balance. It also documents the failure branches (missing contract = 404, non-ERC-20 = 422) so the agent knows what invalid input looks like.

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

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

Annotations already cover readOnly/destructive, but the description goes well beyond them: it discloses pricing ($0.01/call, first 25 free, failed calls free), that a malformed address returns 400 uncharged, and that repeated calls are re-charged — which explains the non-obvious idempotentHint=false. That billing and error behavior is exactly the 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-loaded with the resource and chain, then siblings, then error/billing notes, then the read-only reassurance. Dense but every sentence carries information; the billing tail is slightly repetitive ('each call is charged, so repeats are not free' after already stating price per 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?

For a one-parameter read tool with no output schema, the description supplies the return shape (wei and AVAX, latest block), the error path, the cost model, and the sibling routing. Nothing an agent needs to call it correctly or 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% and the single parameter is self-explanatory, so the baseline is 3. The description adds real meaning on top: a concrete example address and the behavior for a malformed value (rejected with 400, uncharged), which tells the agent what valid input looks like and what a bad input costs.

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

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

States a specific verb and resource: native AVAX balance of a 0x address on Avalanche at the latest block, returned in wei and AVAX. It also names the underlying call (eth_getBalance) and explicitly distinguishes itself from avax_token_balance (ERC-20) and wallet_portfolio (all holdings), so an agent can route without opening another schema.

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

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

Gives an explicit use case (checking whether a wallet can pay gas or a transfer) and names both alternatives with the condition that selects each: ERC-20 tokens go to avax_token_balance, all holdings go to wallet_portfolio. When-not guidance is implicit but 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces that with 'reads or computes only and changes nothing.' What it adds beyond annotations is cost behavior: $0.01/call, first 25 free, failed calls free, and the explicit note that repeats are not free — which explains the otherwise puzzling idempotentHint=false. It stops short of describing pagination or response shape, but for a single-block lookup 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?

The first sentence front-loads purpose and return fields, following sentences handle alternatives, edge cases, and pricing. It is dense but nearly every clause earns its place; the only slight redundancy is restating the per-call charge twice ('$0.01/call' and 'each call is charged, so repeats are not free'), though the second instance does clarify non-idempotency.

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 block fields returned. Combined with the 404 behavior, example call, and cost model, an agent has everything needed to invoke this 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% and the single parameter is already documented, so the baseline is 3. The description still adds value by specifying 'decimal number' format and giving a concrete example (number=latest), which removes ambiguity about hex vs decimal input and confirms 'latest' as the 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?

The description states a specific verb+resource (fetch block number or block details) scoped to Avalanche, and enumerates exactly what comes back (hash, timestamp, tx count, gas used/limit, base fee, producer). It is clearly separable from siblings like avax_gas and avax_tx 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?

It names the use cases (timestamps and confirmation counts) and explicitly routes the agent to avax_gas for current fees, which is the main adjacent-sibling ambiguity. It also states the edge case that a future block returns 404 and is uncharged, so the agent knows the failure mode in advance.

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: 8 KB calldata cap, revert behavior (422 with reason, uncharged), and full pricing model ($0.01/call, first 25 free, failed calls free, repeats not free). That last point reconciles the billing implications of idempotentHint=false, which annotations alone would not 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, then limits, then pricing; every line is informative. The pricing sentence is dense and could be split, but nothing is truly wasted for a paid API.

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

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

No output schema exists, and the description compensates by stating the return is raw hex return data that must be decoded with the function ABI. Error behavior, size limit, and cost model are all covered, so an agent has what it needs to call and interpret results.

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 describes all three params, so the schema carries the load; the description still reinforces that data is selector+args and shows a real to/data pair. The optional 'from' parameter (msg.sender checks) is not mentioned in the description, leaving a small gap.

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-only contract call ... eth_call', 'send ABI-encoded calldata ... get raw return data') on a named chain. The line 'use to read any view function that has no dedicated tool' lets an agent distinguish it from the dozens of specific avax_* readers without inspecting 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: any view function lacking a dedicated tool, with a concrete worked example (USDC totalSupply). It implies the alternative class (dedicated tools) but never names one, and doesn't address when to use avax_call vs the equivalent eth_call/arb_call on another chain.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered; the description adds genuinely new context beyond that: $0.01/call via x402 or credits, first 25 free, failed calls free, and revert outcomes as 422 with reason and uncharged. It stops short of describing pagination or latency, but the pricing and failure behavior are exactly the kind of extra detail that helps an agent decide whether to call.

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

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

Front-loaded with purpose and return units, then usage, then pricing and failure behavior; every clause is informative. It is dense rather than bloated, though the pricing sentence and the 'reads or computes only' restatement of readOnlyHint could be trimmed 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?

There is no output schema, and the description compensates by naming the return units (gas units, gwei, AVAX) and the revert error shape (422 with reason, uncharged). Combined with the example address and billing terms, an agent has everything needed to call 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 each field; the description nonetheless adds semantic guidance by clarifying that value is in AVAX, that data is calldata for a contract call, and that from is needed 'when the call depends on it'. That conditional framing is useful routing information not present in 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 ('Estimate the gas a transaction would use on Avalanche') and explicitly names the underlying RPC method (eth_estimateGas) plus what it returns (gas units, gwei, AVAX). It distinguishes itself from the gas-price sibling by scoping that tool out in the next sentence.

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 price a batch') and a named alternative for the adjacent case ('for the gas price alone use avax_gas'). It also specifies the condition for supplying the from parameter, leaving no routing ambiguity.

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.01/call via x402 USDC or card key, first 25 free, failed calls free), which explains why idempotentHint is false — "each call is charged, so repeats are not free" turns a bare annotation flag into actionable cost behavior. It also restates the read-only nature and the fact that it accepts no required input, so the agent knows there are no side effects or prerequisites.

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 answer (current gas price and the three components), then usage routing, then cost/safety. Dense but every clause carries information an agent needs, though the pricing sentence is long enough to blunt the one-screen readability.

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

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

There is no output schema, yet the description specifies the returned fields and their units (gwei), plus a derived figure (21k-gas transfer cost), so the agent knows what it will get. Cost, free tier, and read-only semantics cover the remaining risk for a pay-per-call 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%, so the single optional `only` projection parameter is fully documented in the schema, which sets the baseline at 3. The description adds nothing about `only` and in fact says "Takes no input," which slightly understates the tool's optional projection capability rather than enriching it.

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

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

States a specific verb and resource — current gas price on Avalanche — and enumerates exactly what is returned (gas price, base fee, suggested priority fee in gwei, plus the cost of a 21,000-gas AVAX transfer). It also cites the underlying RPC method and names the sibling it is not (avax_receipt), so an agent can distinguish it from avax_gas_history/avax_estimate_gas 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 before sending a transaction or to decide whether to wait" gives an explicit use context, and "for the fee a past transaction actually paid use avax_receipt" names an alternative with the condition that selects it. It stops short of routing against avax_gas_history (historical trend) and avax_estimate_gas (per-transaction estimate), which are the closest siblings here.

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

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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), and the description adds genuinely new operational facts: it 'reads or computes only and changes nothing', each call is charged, repeats are not free, failed calls are free, and payment works via x402 USDC or a card key at /credits with 25 free calls. This also explains the otherwise puzzling idempotentHint=false. Slight gap: no mention of latency, caching, or what happens if the node returns fewer than N blocks.

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 contents before the routing hint and the commercial boilerplate. It is one dense paragraph, and the pricing/credits tail is longer than an agent needs, but every sentence carries information and none is a restatement of the title.

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

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

There is no output schema, so the description carries the full burden of describing the return payload, and it does so precisely (per-block base fee, fullness, three priority-fee percentiles, window summary). With a single optional parameter and complete usage/cost guidance, 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% and the schema already documents 'How many recent blocks, 5-100 (default 20)', which the description largely repeats along with an example (blocks=20). The one added value is that the prose range is trustworthy where the raw minimum/maximum in the schema are sentinel numbers, but that is a thin increment over structured data.

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 ('Gas price history on Avalanche') and enumerates exactly what comes back: base fee in gwei per block, block fullness, 10th/50th/90th percentile priority fees, and low/average/high base fee over the window. It also names the sibling it is not ('for the current price alone use avax_gas'), so it is separable from avax_gas, arb_gas_history, base_gas_history and the dozens of other per-chain gas 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?

Gives three concrete use cases ('judge whether fees are rising, pick a priority fee or time a transaction') and an explicit exclusion routing to avax_gas for a single current price. The when-not condition is stated, not 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that — pricing, free failures, and the 'each call is charged, so repeats are not free' caveat that explains the idempotentHint=false. It stops short of describing the response shape (e.g. whether an is_contract boolean is returned alongside bytecode size and proxy info), which is left implicit.

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 the key caveat (proxy detection) are front-loaded, and most sentences carry information an agent needs. The pricing/payment sentence is dense (x402, card key, first 25 free, failed calls free) and slightly crowds out the return-value detail, costing one point.

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 one parameter, the description carries most of the burden and mostly does: it explains what is computed, the error case, and the cost model. It never spells out the returned field names or the is-contract boolean explicitly, so an agent still infers the response shape.

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

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

Schema coverage is 100% with a single 'address' field, so the baseline would be 3. The description goes a step further by supplying a concrete example address and specifying the accepted form (0x-prefixed) and the rejection behaviour for malformed input, which is real meaning beyond the schema.

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

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

The description opens with a specific verb and resource ('Check whether a 0x address on Avalanche is a smart contract or a plain wallet') and then names the actual payload: bytecode size, EIP-1167 minimal-proxy detection, and implementation address. That detail separates it from the many sibling *_proxy and *_balance tools.

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

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

It states the concrete trigger ('Use before sending funds or approving a spender') and routes heavier needs elsewhere ('for a fuller risk verdict use check_counterparty'). It also covers the failure path ('malformed address is rejected with 400, uncharged'), so an agent knows what a bad call costs.

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 cost ($0.01/call via x402 USDC or card key), that the first 25 calls are free and failed calls are free, and that repeats are charged — consistent with idempotentHint=false. It also bounds the output ('up to 100 logs with block, transaction hash and topics'), which 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?

Core semantics, the alternative pointer and an example are front-loaded in the first two sentences; the pricing/cost sentence is long but earns its place for an agent budgeting calls. Slight density, but 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?

Covers return shape, filterable fields, cost model and the read-only guarantee, which is sufficient for a 3-parameter read tool with no output schema. It stops short of stating what happens when a query matches more than 100 logs (truncation vs error), the main residual ambiguity.

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 blocks, topic0 and address with ranges and defaults. The description adds only a small gloss on topic0 (32-byte signature hash) and a concrete example address; it does not explain truncation behavior when more than 100 logs match. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

States a specific verb and resource (eth_getLogs event logs for a contract on Avalanche), fixes the scan window (1-1,000 blocks, default 50) and the topic0 filter, and explicitly names the sibling it is not (avax_receipt) for single-transaction outcomes. An agent can distinguish it from avax_logs-style siblings on other chains and from avax_receipt without opening the schema.

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

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

Gives a positive use case ('watch transfers or contract events') and an explicit exclusion pointing to avax_receipt for one transaction's outcome. One gap: for pure transfer watching, the sibling avax_token_transfers is arguably the better fit and is not mentioned, so routing is slightly incomplete.

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

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

Beyond readOnlyHint/destructiveHint annotations, it discloses that failures are uncharged and that repeat calls cost money — directly explaining the idempotentHint=false flag in cost terms — plus the pricing model ($0.01/call, x402 USDC or card key via /credits, first 25 free). That is meaningful behavioral context an agent cannot get from the structured fields.

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

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

Front-loaded with the core semantics and alternatives before pricing and error codes, so it is scannable despite being a single dense paragraph. Minor waste: 'Reads or computes only and changes nothing' largely duplicates the readOnlyHint/destructiveHint annotations.

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

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

With no output schema, the description still tells the agent what comes back (count plus collection name and symbol); with only two required params, the schema covers inputs. Error codes, cost model, and the sibling routing together make it complete enough to invoke 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 coverage is 100% and both properties already document themselves as '0x ... address'. The description's 'Both inputs are 0x addresses' restates that without adding format, checksum, or validation nuance, so it neither compensates for nor detracts from the schema. Baseline 3 applies.

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

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

States a specific verb and resource — count of NFTs held in one ERC-721 collection by one wallet on Avalanche — and names the underlying call (balanceOf) plus the returned extras (name, symbol). It explicitly distinguishes itself from the closest sibling, avax_nft_owner, so an agent can pick between them 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 (gate a holder before a token-gated action, check whether a wallet still holds a collection) and an explicit alternative with its selection condition ('for who holds one token id use avax_nft_owner'). It goes further and states the failure surface: missing contract is 404, non-ERC-721 contract is 422.

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

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

Annotations already cover readOnly/destructive/openWorld, but the description adds substantive behavior beyond them: 1,000-char truncation of on-chain SVG strings, 422 for nonexistent tokens (uncharged), metadataError for unreachable metadata, and cost/charge semantics that explain why idempotentHint is false. This is unusually rich disclosure for a read 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?

Purpose and scope are front-loaded, followed by supported URI schemes, edge cases, alternatives, an example, and pricing. It is dense but nearly every sentence carries information; the pricing sentence is long but relevant to cost-sensitive agents.

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 explains the return shape (name, description, image, attributes), truncation behavior, and both error channels (422 and metadataError). 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 baseline is 3. The description goes slightly further with a concrete example (contract=0x655C..., tokenId=1) that shows the expected value shapes, plus notes on how the returned URI may be data:/https/ipfs – helpful context for interpreting the parameters.

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: reads the tokenURI of one ERC-721 token id and the JSON it resolves to, on Avalanche. It distinguishes itself from the nearest sibling by naming avax_nft_owner for owner lookups, 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?

Explicit 'Use to show or check what an NFT is; for its owner use avax_nft_owner' names the alternative and the condition that selects it. The failed-call and pricing notes further clarify when the call is worth making.

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

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

Annotations already declare readOnly=true, destructive=false, idempotent=false, so the safety profile is known; the description nonetheless adds real behavior: 404 on missing contract, 422 on nonexistent token, both uncharged, plus the charging model and that repeat calls are not free. The only minor gap is it does not state the response shape beyond the fields named, which is largely implied.

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 definition and alternatives, then errors, example, and pricing — a sensible ordering with no filler. The pricing information is stated twice in effect ('Price $0.01/call… first 25 free' and 'each call is charged, so repeats are not free'), a small redundancy in an otherwise dense paragraph.

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 still tells the agent what comes back (owner address, collection name, symbol), how failures behave, what it costs, and that it mutates nothing. For a two-parameter read tool that is 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 worked example (contract=0x655C..., tokenId=1) that shows the expected address/id formats, and ties the two parameters to distinct failure modes (missing contract vs nonexistent token). That is meaningful meaning beyond the schema's one-line field notes.

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 — 'the wallet that holds one ERC-721 token id right now (ownerOf)' — and explicitly delimits scope to a single token on Avalanche, plus names the collection name/symbol as extra return data. It is unmistakably distinct from avax_nft_balance (counts) and avax_nft_metadata (token metadata).

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

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

Gives a concrete use case ('verify who holds an NFT before a trade, a mint gate or an airdrop') and routes to two named alternatives with their selecting conditions ('for how many a wallet holds use avax_nft_balance, for the token's metadata avax_nft_metadata'). Both when-to-use and when-to-use-something-else 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?

Annotations already declare readOnlyHint and destructiveHint=false, and the description redundantly restates that nothing changes. However, it adds material context beyond the structured fields: pricing ($0.01/call, 25 free), that failed calls are free, the 400 rejection for malformed addresses without charge, and that 'each call is charged, so repeats are not free' — which meaningfully explains the idempotentHint=false annotation.

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 error/cost behavior — good ordering with no filler. It is slightly dense and run-on in the pricing/immutability sentence, but every clause carries information an agent would otherwise have to discover by calling.

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

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

For a one-parameter read tool with no output schema, the description covers purpose, scope, error handling, cost, and the confirmed-vs-pending distinction. It could be marginally more complete by describing the shape of the returned nonce(s), but nothing critical to 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 the single 'address' parameter is documented structurally; the description adds format validation behavior (malformed → 400, uncharged) and a concrete example address. It does not explain what the return value looks like (confirmed vs pending count fields), leaving a small gap.

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?

Starts with a specific verb and resource: 'Read the transaction count (nonce) of a 0x address on Avalanche,' and adds scope ('both confirmed and including pending transactions'). It also explicitly distinguishes itself from the sibling avax_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?

Gives two concrete use cases ('build the next transaction', 'tell whether an address has ever sent anything') and names the alternative tool plus the condition that selects it ('for its balance use avax_balance'). 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?

Beyond the readOnly/non-destructive annotations, the description discloses concrete behavioral traits: malformed address returns 400, no-code address returns 404, failed calls are free, calls are charged and not idempotent in cost terms, and pricing details. It also explicitly says the tool reads/computes only and changes nothing.

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

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

The description is front-loaded with the core purpose, then usage guidance, error behavior, an example, and pricing. Sentences are dense but each carries useful operational information for a paid read-only proxy 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?

For a one-parameter tool with annotations and no output schema, it is nearly complete: it explains what is inspected, what kind of result is named, error behavior, and cost. It could more explicitly describe the return structure, such as whether implementation, admin, and beacon values are always included, but the essential contract is clear.

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

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

The single address parameter is fully documented by the schema, so baseline is 3. The description adds a concrete example address and ties malformed input to a 400 response, improving meaningfulness beyond the schema text.

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: find the implementation behind a proxy contract on Avalanche. It lists the exact mechanisms read (EIP-1967, beacon/admin slots, UUPS, OpenZeppelin layout, EIP-1167) and says it names the kind found, which clearly distinguishes it from generic storage or call tools.

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

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

It gives explicit usage context: use before trusting or decoding upgradeable contracts, and directs agents to contract_risk for a fuller risk verdict. This names both when to use it and the main alternative.

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

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

Goes well beyond the annotations: it discloses the 404-without-charge behavior for pending/unknown hashes, per-call pricing ($0.01 via x402 USDC or card key), a 25-call free tier, free failed calls, and that repeats are billed again. That last point is consistent with idempotentHint=false and explains it rather than merely restating 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-loaded with what the tool returns and who it competes with, then the input format and example, then billing. It is dense and slightly overloaded with pricing terms, but nearly every clause carries information an agent needs before spending money on a call.

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

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

There is no output schema, so the description correctly enumerates the fields returned, plus error behavior and cost. Minor gap: it says 'number of event logs' but doesn't indicate whether the logs themselves are included, which matters for an agent deciding between avax_receipt and avax_logs.

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 the 0x-prefixed 64-hex format, so the description's baseline is 3. It adds a concrete worked example hash plus the semantics of a bad/unresolved hash (404), which is genuine value beyond the schema, though the format detail is partly duplicated.

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

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

States a specific verb+resource ('Transaction receipt on Avalanche'), names the underlying RPC (eth_getTransactionReceipt), and enumerates the returned facts (status, gas used, gas price, fee in AVAX, log count, created contract). It also explicitly differentiates itself from the sibling avax_tx, so an agent can pick between them 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 use case ('confirm a payment or call went through') and names the exact alternative for the complementary job ('for sender, value and calldata use avax_tx'). The failure condition (pending/unknown hash → 404, uncharged) is also stated, which is the kind of routing detail agents need.

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 pricing ($0.01/call, 25 free, failed calls free), rejection behavior (400, uncharged), and explicitly explains why repeated calls are not free — which is the reason the annotations mark idempotentHint=false. It only lightly repeats readOnlyHint with 'changes nothing', so the added context is real. It could be stronger on whether the returned word is always present or null for an empty slot.

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 the return shape, then the routing rule, then pricing. Dense but every element (pricing, 400 behavior, example, sibling pointer) earns its place. Slightly overpacked into a single block, which costs it a point.

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 explains what comes back (32-byte word as a number, and as an address when it holds one). With annotations covering safety and the description covering return shape, routing, failure mode, 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% and already documents both parameters, so the description only needs to add value — it does by explaining that slots are decimal indices or 0x 32-byte keys used for mapping and proxy slots, and by giving a concrete address example. This exceeds the baseline-3 case where schema carries all meaning.

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 raw storage slot of a contract on Avalanche), maps it to the underlying RPC (eth_getStorageAt), and describes the return shape. It also names the sibling it is not (avax_proxy), so an agent can distinguish 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?

Explicit when-to-use ('contract state that has no getter, owners or implementation pointers') with an explicit alternative and routing rule ('for proxies use avax_proxy'). The when-not case and failure condition (malformed address/slot -> 400, uncharged) are both stated.

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

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

Goes well beyond the annotations by disclosing error semantics (no contract returns 404, non-ERC-20 contract 422, both uncharged), pricing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free), and that it reads/computes only with each call charged. This clarifies exactly why idempotentHint=false is 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 what it returns, then usage, then input constraints, then error/pricing behavior. The pricing and free-tier sentences are dense but relevant to cost-aware agents; the sentence count is near the upper bound for a two-parameter tool.

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

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

With no output schema, the description nonetheless enumerates the returned fields (raw amount, decimals, symbol, human-readable amount) and covers error cases and billing. 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 coverage is 100%, so both parameters are already documented; the description adds a useful format constraint that both inputs must be 0x addresses of 40 hex characters and reinforces that 'token' accepts a ticker or contract address. That is a modest but real addition over the schema text.

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: ERC-20 token balance of a wallet on Avalanche via balanceOf, with enumerated return fields. It explicitly distinguishes itself from the native-coin sibling ('for the native coin use avax_balance'), so an agent can route between the two 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 a concrete usage context ('check stablecoin or token holdings before a transfer or trade') and names the alternative for the native coin case. It does not address the reverse case (when NOT to use this, e.g. use avax_allowance for approvals or avax_token_info for metadata), which keeps it short of a 5.

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

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

Goes well past the annotations: data is read live from the contract, non-ERC-20 addresses return 422 and are uncharged, pricing is $0.01/call with 25 free calls, and repeated identical calls are still billed (consistent with idempotentHint=false). This is exactly the payment and failure-mode context the 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 the core action and output fields, then usage, then input, then cost. Dense with semicolon chains and pricing detail in the final sentence, but no sentence is pure filler.

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

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

There is no output schema, and the description compensates by enumerating the returned fields. Input format, failure semantics, and billing are all covered, so an agent can call 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 coverage is already 100%, so the description only needs to add value and it does: it clarifies that the same field accepts either a ticker or a 0x address, supplies a worked example, and documents the error behavior for an address form input. It stops short of tie-breaking guidance such as ticker ambiguity across tokens.

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 name, symbol, decimals, total supply of an ERC-20 contract on Avalanche) and explicitly names the sibling it is not (avax_token_balance for holder balances). An agent can distinguish it from the dozens of avax_* siblings and the cross-chain token_info 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 (identify an unknown token address, format raw amounts) and an explicit exclusion routing balance queries to avax_token_balance. The 422-on-non-ERC20 note further tells the agent when this tool is the wrong 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?

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context on top: errors are rejected with 400 and uncharged, the first 25 calls are free, failed calls are free, each successful call costs $0.01 via x402 or a card key, and repeats are not free despite being safe. That pricing and error-charging behavior is exactly the kind of trait 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?

A single dense paragraph that front-loads the scope (wallet, token, window, result shape) before usage, errors and pricing. It is long but almost every clause carries a distinct fact; the only waste is mild redundancy between 'first 25 free / failed calls free' and the closing 'each call is charged, so repeats are not free.'

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

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

For a 3-parameter read tool with no output schema, the description covers everything an agent needs: what is returned and in what order, the result cap, the address format with an example, the failure mode and its cost, and the billing model. 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%, so the schema already documents token, blocks range/default and address, and the description largely repeats it (default USDC, 1-2,000 blocks, default 1,000). The one genuine addition is a worked address example (0xd8dA...6045) showing the expected 0x format, which is useful but marginal against a fully documented 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 ERC-20 transfers for one wallet on Avalanche) plus the exact shape of the result: in/out, direction, counterparty, amount, transaction, newest first, capped at 50. It also pins the default token (USDC) and the block window, so an agent can distinguish it from avax_token_balance and from the other per-chain transfer tools 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 an explicit use case (confirm a payment arrived or see what was sent) and names the alternative with the condition that selects it: 'for the current balance use avax_token_balance.' Nothing about when-to-use 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 past the annotations by disclosing the pricing model ($0.01/call, first 25 free, failed calls free), the 404-on-unknown-hash behavior being uncharged, and that repeated identical calls are charged again — which explains and reinforces the idempotentHint=false annotation 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?

Purpose, returned fields, sibling routing, parameter format, error behavior and cost all appear in a compact block with the core purpose front-loaded. It runs long as a single paragraph and the pricing sentence is dense, but no sentence is truly 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, yet the description names the returned fields, the error case (404, uncharged), the input format, and the billing implications — everything an agent needs to decide to call it and to interpret a failure.

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 the single hash parameter. The description still adds value by restating the 0x-prefixed 64-hex format and supplying a concrete example hash, which makes correct invocation easier without contradicting 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 an Avalanche transaction by hash') and enumerates the fields returned (sender, recipient, value in AVAX, nonce, gas limit, selector, block). It explicitly distinguishes itself from the two nearest siblings, avax_receipt and avax_logs.

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

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

Gives the selection rule directly: use this to see what was sent or whether it exists, use avax_receipt for success/failure and fees, use avax_logs for emitted events. Both alternatives are named with the condition that selects them, 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?

Annotations already cover read-only and non-destructive, but the description adds information annotations cannot convey: pricing ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and the explicit warning that repeat calls are charged, which materially explains the idempotentHint=false billing behavior. It also reaffirms 'reads or computes only and changes nothing' and enumerates the return payload.

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

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

Front-loads what is checked and why, then behavior and pricing; three sentences with no filler. The pricing/free-tier clause is dense but justified for a paid tool, though it slightly crowds the middle of 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?

With no output schema, the description compensates by listing the exact return fields, and it covers cost, safety profile, and intended workflow for a simple 3-parameter read tool. An agent has everything needed to decide 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% and all three parameters (owner, token, spender) are documented in the schema with role and address format. The description restates the owner/spender relationship but adds no format, constraint, or edge-case detail beyond the schema, so the baseline 3 applies.

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

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

States a precise verb and resource ('check how much of a wallet's ERC-20 token a spender contract is approved to move on Base') and even enumerates what comes back (raw/formatted allowance, symbol, decimals, unlimited flag). The 'approved to move' phrasing cleanly separates it from the sibling balance tools (base_token_balance) and the chain prefix separates it from eth_allowance/arb_allowance 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 two concrete usage contexts: pre-swap/pre-deposit approve checks and auditing risky unlimited approvals. It does not name an alternative tool or state when-not to use it, so it stops short of the explicit routing a 5 requires.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real context: latest block only, dual unit output, 400 rejection of malformed addresses with no charge, and per-call pricing with 25 free calls. The note that repeats are not free usefully explains the idempotentHint=false flag rather than contradicting it. It stops short of describing the exact response envelope, which is the only minor gap.

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

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

Front-loaded with the core operation and units, then routing guidance, then validation and pricing. The pricing/billing sentence is the longest and only marginally relevant to invocation, but every other clause carries information an agent needs.

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

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

For a single-parameter read tool with no output schema, the description covers return units (wei and ETH), block scope (latest), error behavior, and costs. 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 baseline is 3, but the description adds that the address may be a wallet or contract, that any 0x address works, and supplies a concrete example value. It also specifies 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 and resource: native ETH balance (eth_getBalance) of any 0x address on Base at the latest block, reported in wei and ETH. It explicitly separates itself from base_token_balance (ERC-20) and wallet_portfolio (all holdings), so an agent can pick 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?

Gives an explicit use case (check whether a wallet can pay gas or make a transfer) and names both alternatives with the condition that selects each. No inference is needed to route between this and its siblings.

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

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

Annotations already cover read-only, open-world, non-idempotent and non-destructive, but the description adds real behavioral detail beyond them: 404 and uncharged for not-yet-existing blocks, failed calls free, and per-call billing that makes repeats non-free. Pricing and failure semantics are 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?

Dense but front-loaded: the resource, returned fields, alternative tool, and error behavior come before the pricing tail. The billing sentence is somewhat repetitive ('each call is charged, so repeats are not free' restates the price) but remains operationally relevant.

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

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

With no output schema, the description compensates by listing exactly what a block response contains (hash, timestamp, tx count, gas used/limit, base fee in gwei, producer) and covers the missing-block case and default parameter, which is 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% and the single 'number' parameter is already documented with its 'latest' default, so the description only reinforces the default via the example 'number=latest'. Useful but largely duplicative of 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 ('Latest block number and block details on Base, or any block by decimal number') and enumerates the returned fields, so it is clearly distinguishable from siblings like base_tx or base_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 intended uses ('timestamps and confirmation counts') and names the alternative tool for the adjacent need ('for current fees use base_gas'), giving both when-to-use and when-not-to-use guidance.

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

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

Goes well beyond the annotations: latest block semantics, an 8 KB calldata cap, revert behavior (422 with reason, uncharged), pricing model ($0.01/call via x402 or card key, first 25 free), and the crucial warning that each call is charged so repeats are not free — which explains the idempotentHint=false. The 'changes nothing' clause reinforces readOnlyHint/destructiveHint without merely repeating 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?

Front-loads what the tool is and when to use it, then constraints, then economics — good ordering with no filler. The pricing/free-tier sentence is dense and slightly overloaded into one line, but every clause carries information an agent needs (cost per call, free retries on failure).

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 stating the return is raw return data requiring ABI decoding, plus the revert path. Combined with the size limit, pricing, and block semantics, an agent has everything needed to invoke and interpret results without guessing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value: a worked example pairing a live Base USDC address with selector 0x18160ddd, the note that calldata is '4-byte selector plus arguments' in context, and the 8 KB size constraint. The optional `from` parameter is not mentioned in the description, leaving that entirely to the schema.

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

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

States a specific verb+resource (read-only eth_call on Base) plus the exact scope: ABI-encoded calldata in, raw return data out, at latest block. It also distinguishes itself from the many sibling wrappers (eth_call, arb_call, op_call, polygon_call) by naming its chain, and from dedicated tools via 'any view function that has no dedicated 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?

Clearly says when to use it: view functions that lack a dedicated tool, with a concrete USDC totalSupply example. It implies the alternatives (base_token_balance, base_storage, etc.) exist by saying 'no dedicated tool' but never names a single sibling, so the routing decision still requires the agent to scan the tool list.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false), and the description adds value beyond them: reverting transactions return 422 with the reason and are uncharged, each successful call is billed at $0.002 via x402 USDC or card key with the first 25 free, and retries are not free. That is exactly the operational 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-loaded with what the tool does and when to use it, then examples, error semantics, and billing. The billing sentence is longer than strictly needed for tool selection but carries decision-relevant cost information, so only minor trimming would be warranted.

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 four-parameter read-only estimation tool with no output schema, the description covers return units, error behavior, cost, and the one non-obvious parameter interaction (from). 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 baseline is 3. The description still adds meaning beyond the schema: it clarifies that value is denominated in ETH, that calldata is for a contract call, and notably that the sender matters only when the call depends on it, which guides correct use of the optional from 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 concrete verb and resource with the underlying RPC method (eth_estimateGas on Base) and the exact output dimensions (gas units, gwei, ETH). It is immediately distinguishable from base_gas and base_call by naming what it computes versus what those return.

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, pricing a batch) and an explicit alternative with its selecting condition ('for the gas price alone use base_gas'). The revert case and the billing conditions are also 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?

Goes well past the annotations: discloses pricing ($0.002/call via x402 USDC or card key, first 25 free, failed calls free) and that each call is charged so repeats are not free -- which explains the otherwise puzzling idempotentHint=false. It also confirms 'reads or computes only and changes nothing', consistent with readOnlyHint=true. Cost and billing behavior is exactly the kind of operational detail 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-loads the resource and chain, then the returned fields, then usage, then cost -- a sensible priority order with no filler sentences. It is on the long side because the return-field enumeration and the billing caveats are both spelled out, but each 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?

There is no output schema, so the description usefully enumerates units (gwei vs wei) and the concrete computed values returned. Combined with the stated safety profile (read-only, no side effects) and the billing model, an agent has everything needed to call this correctly and predict the cost.

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

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

Only one optional parameter (`only`), and the schema description already covers it at 100% with an example and fallback behavior. The description says nothing about `only` or the result-key projection it enables, so it adds no meaning beyond the schema. Baseline 3 applies when the schema does the full job.

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

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

States a concrete verb and resource -- live gas prices read from the latest Base block (chain 8453) -- and enumerates exactly what is returned (base fee, priority fee in gwei, maxFeePerGas/maxPriorityFeePerGas in wei, block fullness, ETH/ERC-20 transfer fee estimates). This lets an agent separate it from base_estimate_gas (per-transaction estimation) and base_gas_history (historical series) 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?

Explicit timing guidance: 'Use before sending a transaction on Base or to decide whether to wait for lower fees.' That is a clear use context with no exclusions. It stops short of naming the sibling alternatives (base_estimate_gas, base_gas_history, pack_gas_tracker) or stating when not to use it, so it lands at 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered; the description goes further by disclosing the billing model ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and explaining why repeats are not free — which reconciles the non-obvious idempotentHint=false. It also describes the returned fields, which matters since there is no output schema. It stops short of documenting rate limits or error behavior beyond 'failed calls 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?

Purpose, returned fields, use cases, the sibling alternative and the cost model all appear in one front-loaded paragraph with little waste. It is dense and slightly crammed (pricing detail runs long relative to the core purpose), but no sentence is purely filler.

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

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

For a single-optional-parameter read tool with no output schema, the description covers what is returned, when to use it, which sibling to prefer for the simpler case, and the pricing consequences of repeat calls. Nothing an agent needs in order to select and call this correctly is absent.

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

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

Schema coverage is 100% and the single 'blocks' parameter is fully documented in the schema with the same '5-100 (default 20)' range and default that the description repeats. The description adds only an illustrative 'blocks=20', so the baseline 3 applies — the schema does the real work here.

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

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

The description names a specific verb and resource — gas price history on Base via eth_feeHistory — and spells out exactly which fields come back (base fee in gwei, block fullness, 10th/50th/90th percentile priority fees, low/avg/high over the window). It also names the sibling it is not ('for the current price alone use base_gas'), so an agent can route between the two 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 explicit use cases ('judge whether fees are rising, pick a priority fee or time a transaction') and an explicit exclusion with the alternative to use instead ('for the current price alone use base_gas'). The only missing piece is what to do on a non-Base chain, but the tool name scopes that already.

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

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

Annotations already declare readOnly/openWorld/non-idempotent/non-destructive, and the description goes further by noting each call is charged and repeats are not free, which explains the idempotentHint=false in practical terms. It also documents the 400-and-uncharged behavior for malformed addresses and the x402 pricing model. The remaining gap is what the success payload looks like beyond 'bytecode size' and proxy info.

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

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

Front-loaded with the operation, then usage, then error behavior, example and pricing, so an agent can stop reading early. The pricing sentences are dense and slightly over-detailed for tool selection, but they carry real behavioral 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-parameter read-only tool with no output schema, the description covers purpose, returns (bytecode size, proxy status, implementation), error behavior, cost and safety. Nothing material 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 only one parameter, so the baseline is 3; the description adds a concrete example address and states the malformed-address failure mode, which gives the agent a validation signal the schema does not. It does not say whether non-0x inputs like ENS names are accepted.

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 if a 0x address on Base is a contract or plain wallet, returning bytecode size plus EIP-1167 minimal-proxy status and implementation address. That is enough to separate it from balance/token siblings and from the risk-oriented 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?

Explicitly names the trigger ('before sending funds or approving a spender') and routes the agent to check_counterparty when a full risk verdict is wanted. The only small gap is that it does not contrast itself with the sibling base_proxy tool, which also deals with proxies.

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 annotations by disclosing cost and billing mechanics ('$0.01/call via x402 USDC or a card key', 'first 25 free', 'failed calls free') which gives real meaning to idempotentHint=false — retries are not free. It also caps the return at 100 logs and names the return fields, though it doesn't discuss pagination or how to reach logs beyond that 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 eth_getLogs equivalent and the block window, then usage, then return shape, then pricing — a sensible order. It is somewhat dense and repeats the 1-1,000/default-50 detail already in the schema, but almost every sentence carries actionable information.

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

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

With no output schema, the description steps in by naming the returned fields ('block, transaction hash and topics') and the 100-log ceiling, and it covers cost and safety. What's left implicit is behavior at the 100-log cap and whether results are ordered, which matter slightly for a log-scanning tool.

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

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

Schema coverage is 100%, so the schema already documents all three parameters and the baseline applies. The description restates the block range and default and clarifies topic0 as a '0x 32-byte event signature hash', which is only marginally more than the schema's own wording; the example address shows form but not what the address must be.

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

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

States a specific verb and resource ('Recent contract event logs on Base (eth_getLogs)') plus the exact scope: events a contract emitted over the last N blocks. It also distinguishes itself from base_receipt by name, so an agent can separate the two without opening a schema.

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

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

Explicitly says what to use it for ('watch transfers or contract events') and redirects to the correct sibling for a different need ('for one transaction's outcome use base_receipt'). The when-not is stated, not 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?

Goes well beyond the annotations by disclosing error semantics (404 for missing contract, 422 for non-ERC-721, both uncharged), the pricing model ($0.01/call, 25 free, failed calls free), and that repeat calls are charged — which explains why idempotentHint is false. It also confirms read-only/no-mutation, consistent with readOnlyHint=true and destructiveHint=false.

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 the sibling routing are front-loaded in the first two sentences, and the error/pricing details are genuinely decision-relevant. It is dense but slightly sprawling, with payment mechanics taking up roughly half the text.

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

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

With no output schema, the description still says what comes back (balance plus collection name and symbol). Combined with error codes, cost model, and read-only confirmation, an agent has everything needed to call this correctly and interpret failures.

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

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

Schema coverage is 100%, with both parameters already documented as '0x wallet address' and '0x ERC-721 collection contract address'. The description only restates that both inputs are 0x addresses, adding no format, validation, or edge-case detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource — NFT balance of one ERC-721 collection for a wallet on Base — and even names the underlying call (balanceOf). It explicitly separates itself from base_nft_owner ('for who holds one token id use base_nft_owner'), so an agent can pick between the two siblings 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 (check a holder before a token-gated action, verify a wallet still holds a collection) and an explicit exclusion routing to base_nft_owner. When-to-use, when-not-to-use, and the alternative are all 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?

Annotations cover the safety profile, but the description adds substantial behavioral context beyond them: supported URI schemes, IPFS resolution through ipfs.io, truncation of strings over 1,000 characters, 422 handling for nonexistent tokens, metadataError reporting for unreachable metadata, pricing, and that repeat calls are charged. No contradiction with readOnlyHint/destructiveHint.

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

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

The description is front-loaded with the core purpose and return shape, then adds only operationally relevant details: URI support, truncation, failure behavior, sibling routing, pricing, and mutation safety. Every sentence contributes to correct invocation or interpretation.

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 explains the return values (token URI plus JSON fields), truncation behavior, metadataError, and the 422 case. Combined with full parameter coverage and rich annotations, an agent has enough to call and interpret 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 description coverage is 100%, so both parameters are already documented as contract address and token id. The description adds a concrete example and confirms tokenURI behavior, but it does not add syntax or validation rules beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb and resource: read the token URI and pointed-to JSON metadata for one ERC-721 token id on Base. It also explicitly distinguishes itself from the sibling base_nft_owner, making the scope unambiguous.

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

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

It gives an explicit use case ('Use to show or check what an NFT is') and names the alternative for a different need ('for its owner use base_nft_owner'). This is clear when/when-not guidance, not mere 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?

Beyond the readOnlyHint/destructiveHint=false annotations, it discloses billing behavior ($0.01/call via x402 USDC or card key, first 25 free, failed calls free) and explains why repeated calls are not free, which gives meaning to idempotentHint=false. Error semantics (missing contract 404, nonexistent token 422, both uncharged) and the 'reads only, changes nothing' guarantee remove the usual ambiguity for a paid read 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 distinguishing alternatives, and the pricing/error clauses each carry real decision value. It is dense in a single paragraph, though the billing sentence plus the 'repeats are not free' restatement overlap 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?

With no output schema, the description partially covers return content (owner wallet, collection name, symbol) and fully covers failure modes and cost, which is what an agent needs before calling. The exact response shape (field names, address casing) is left implicit.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description adds a concrete worked example (contract=0x03a5..., tokenId=1) that demonstrates the expected address format and id type. It stops short of adding constraints beyond the schema, so it sits just above the 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: returns the wallet holding a given ERC-721 token id on Base via ownerOf, plus the collection name and symbol. It explicitly distinguishes itself from base_nft_balance (count held) and base_nft_metadata (token metadata), so an agent can pick 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 concrete use cases (verify holder before a trade, mint gate, airdrop) and names both alternatives with the condition that selects them (how many a wallet holds -> base_nft_balance; metadata -> base_nft_metadata). The 404/422 error conditions are also 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?

Beyond the annotations it discloses the cost model ($0.01/call via x402 or card key, first 25 free, failed calls free), the error contract (malformed address -> 400, uncharged), and that repeats are not free because each call is billed. That is meaningful context the readOnly/openWorld/idempotent hints do not convey, though it stops short of describing the response shape (field names for confirmed vs pending counts).

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 sentence, then usage, then error/cost details. Every sentence carries information an agent needs (scope, alternative, validation, billing), though the pricing sentence is dense and could be trimmed slightly without loss.

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 partially compensates by saying both confirmed and pending-inclusive counts are returned. Combined with the validation and billing notes, an agent has enough to call it correctly; only the exact return field structure remains implicit.

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

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

With a single parameter at 100% schema coverage the baseline is 3; the description goes beyond it by supplying a concrete example address and by specifying the validation behavior for a malformed value (400, uncharged). That adds real meaning about what the parameter accepts and what happens when it is wrong.

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 the scope detail that matters most for a nonce: confirmed versus pending-inclusive. It also explicitly routes the balance case to base_balance, so an agent can separate it from the many sibling chain_nonce/chain_balance 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" and "tell whether an address has ever sent anything") and names the alternative tool for a related need ("for its balance use base_balance"). The distinction between this and its siblings is stated 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?

With annotations already covering readOnly/destructive, the description adds real context: 400 for malformed address and 404 for codeless address are uncharged, costing is $0.01/call with 25 free and failed calls free, and it explains why idempotentHint=false ('each call is charged, so repeats are not free'). Only the shape of the returned data is left unspoken.

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 failure modes, then pricing — good ordering. It is dense but every sentence (errors, price, 'failed calls free') carries decision-relevant information for an agent; the pricing tail runs a bit long.

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

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

For a one-param read-only tool with no output schema, this covers purpose, detection methods, error semantics, and cost. The only gap is that the returned structure (e.g., how the detected kind and addresses are presented) is not hinted at beyond 'names the kind found.'

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

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

Single parameter at 100% schema coverage sets baseline 3, but the description adds a concrete example address showing the expected 0x hex form, which is slightly more than the schema's '0x 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?

Specific verb+resource: 'Find the implementation behind a proxy contract on Base', and it enumerates the exact slots/standards checked (EIP-1967, beacon, admin, EIP-1822/UUPS, legacy OZ, EIP-1167). This is trivially distinguishable from sibling base_is_contract or base_storage.

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 ('before trusting or decoding a contract whose code can be swapped by its admin') and names the alternative ('for a fuller risk verdict use contract_risk'). The when-not and routing to a sibling 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?

Goes well past the annotations: pricing model ($0.01/call, first 25 free, failed calls free), 404 responses being uncharged, and an explicit note that repeats are not free — which reconciles the seemingly odd idempotentHint=false with a purely read-only operation. The "reads or computes only and changes nothing" line confirms destructiveHint=false without 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?

Dense but front-loaded: purpose and return fields first, then routing to base_tx, then input format, then cost. The closing sentences repeat the read-only/charging points already implied earlier, which is mild redundancy but the length is defensible for a paid, error-prone 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 every returned field, including reverted-vs-success and contract creation. Error behavior, cost, and the read-only guarantee are all covered, leaving nothing an agent needs before calling.

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

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

Schema coverage is 100%, so the hash format is already documented; the description restates the 0x-prefixed 64-hex constraint and adds a concrete example value, plus the behavior of a pending/unknown hash. That is useful but largely duplicative of the schema, so it sits just 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 ("Transaction receipt on Base (eth_getTransactionReceipt)") and enumerates the returned fields: status, gas used, effective gas price, fee in ETH, log count, contract created. It explicitly distinguishes itself from base_tx ("for sender, value and calldata use base_tx"), so the agent can separate the two 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 trigger ("Use to confirm a payment or call went through") and names the alternative for the other need (base_tx). It also covers the edge case of a pending or unknown hash returning 404, which is exactly the failure mode an agent would otherwise misread as an error.

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/destructiveHint=false, but the description adds real value beyond them: malformed input returns 400 uncharged, failed calls are free, and it explains the idempotentHint=false by noting each successful call is charged so repeats are not free. Pricing and auth (x402 USDC or card key /credits, first 25 free) are also disclosed. The only gap is that it doesn't describe error behavior beyond 400 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?

Purpose and return shape are front-loaded, then usage, then errors and pricing – a sensible order. It is dense with useful facts, though the pricing sentence is long and partially repeats the charge/free idea already implied earlier.

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

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

With no output schema, the description carries the return-value burden itself ('the 32-byte word, as a number and, when it holds one, as an address'), and it also covers error handling, cost, and the proxy alternative. 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 baseline is 3, but the description goes beyond the schema by explaining why a 0x 32-byte key matters ('mapping and proxy slots') and gives a concrete example address. It doesn't add format detail for the decimal slot beyond what the schema states.

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 raw storage slot of a contract on Base (eth_getStorageAt)') and immediately pins down the scope of the returned word. It also names the sibling it is not (base_proxy), so an agent can distinguish it from base_call/base_proxy 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?

'Use to inspect contract state that has no getter, owners or implementation pointers' gives concrete when-to-use conditions, and 'for proxies use base_proxy' names the alternative that supersedes it. Both the positive case and the exclusion 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?

Annotations already declare readOnly/openWorld/non-destructive and non-idempotent, but the description adds materially more: cost ($0.01/call via x402 or card key), first 25 free, failed calls free, and that repeat calls are billed. It also confirms the call reads or computes only and mutates nothing, plus how invalid targets surface as errors.

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

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

One front-loaded paragraph: purpose and return shape first, then the sibling routing hint, then input/error/pricing constraints. Every clause carries operational value, though the pricing and error tail-ends make it denser than strictly necessary for a two-parameter read.

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 return-shape duty and does so (raw amount, decimals, symbol, human-readable). Cost model, error codes, and sibling routing are all covered, leaving nothing an agent needs 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 schema already documents both parameters (token accepting a ticker or 0x contract address, address as a 0x wallet), making 3 the baseline. The description adds length detail (40 hex characters) but its phrasing "Both inputs are 0x addresses" partially contradicts the schema's ticker option for `token`, adding muddle rather than clarity on that parameter.

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

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

States a precise verb+resource: ERC-20 balance of a wallet on Base, resolved via balanceOf, and enumerates the returned fields (raw amount, decimals, symbol, human-readable amount). It explicitly distinguishes itself from base_balance 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 concrete use case ("check stablecoin or token holdings before a transfer or trade") and names the alternative for native coin (base_balance). It also specifies error semantics for the address argument (404 for no contract, 422 for non-ERC-20), which is guidance an agent needs to interpret outcomes.

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?

It adds real context beyond the annotations: failed/422 calls are uncharged, first 25 free, $0.01/call via x402 USDC or card key. It also reconciles idempotentHint=false by explaining the repeat charge is billing, not state change. The score is held at 3 because the pricing/billing detail crowds out other operational behavior (e.g., multi-token formatting example or caching), and the annotation set already carries the read-only safety profile.

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 well, but the second half strings together pricing, free tier, auth method, and error policy in a single dense paragraph with some redundancy ('an address that is not an ERC-20 contract returns 422, uncharged' vs 'failed calls free'). It is information-dense but not tight; splitting billing into its own sentence would improve 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, the description compensates by enumerating all four returned fields and showing an example address. Cost, error behavior, and the balance alternative are all covered, leaving 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% and the schema already documents token as 'a ticker such as USDC or WETH, or the 0x ERC-20 contract address,' so the description mostly repeats it. The only added semantic value is that a non-ERC-20 address returns 422 uncharged and the worked example address, which is marginal beyond the schema.

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

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

The description uses a specific verb ('Look up') with an explicit resource and field list ('name, symbol, decimals and total supply of an ERC-20 token contract on Base'), and it distinguishes itself from base_token_balance by naming that sibling. The agent can tell exactly what this returns versus the ~200 sibling tools.

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

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

It states two concrete use cases ('identify an unknown token address' and 'format raw amounts') and explicitly redirects to base_token_balance for holder balances. That is an explicit when-to-use and when-to-use-something-else, not an 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 readOnlyHint=true, destructiveHint=false, openWorldHint=true and idempotentHint=false. The description goes further on the points annotations can't carry: $0.01/call pricing, 25 free calls, failed calls free, and a 400 on malformed addresses being uncharged. However, it never states whether results are paginated, truncated at 50 with a cursor, or what happens when a wallet has more than 50 transfers in the window.

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?

Scope and the sibling alternative are front-loaded, and the example is useful. The final sentence packs pricing, free tier and charging caveats into a dense run-on, which is informative but less scannable than the opening.

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 tells the agent what comes back (direction, counterparty, amount, transaction, newest first, up to 50). Combined with error behavior (400 uncharged), pricing and read-only nature, an agent has enough 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 schema already documents token, blocks and address, including the 1-2000 range and default 1000. The description adds the practical framing (default USDC, "over the last N blocks") and a concrete address example, but no new syntax or format semantics. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource ("List a wallet's recent transfers of one ERC-20 token") plus chain, direction ("in and out"), window, and returned fields. It explicitly distinguishes itself from base_token_balance, so an agent can separate the two 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 the use cases ("confirm a payment arrived or see what was sent") and names the alternative tool for the other need ("for the current balance use base_token_balance"). The default token and block window are stated up front, leaving nothing to infer.

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

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

Annotations already cover readOnlyHint/destructiveHint/openWorldHint, and the description adds genuinely new context: $0.003/call via x402 USDC or card key, first 25 free, failed calls free, and that repeats are charged. The billing detail also explains the non-obvious idempotentHint=false. The claim "reads or computes only and changes nothing" is largely redundant with readOnlyHint, which keeps it off a 5.

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

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

Front-loaded with the action and the returned-field inventory, then the usage rule, then cost. Dense and free of filler. It runs long in a single sentence and the "reads or computes only and changes nothing" clause is padding against readOnlyHint, but nothing is structurally misplaced.

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 full burden of describing the return payload, and it does so comprehensively (status, parties, value, method, block, confirmations, gas, fee, contract-creation flag). Pricing, auth path, and free-tier rules are all included, so 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 description coverage is 100% on the single `hash` parameter, so the schema already states the 0x + 64 hex format. The description adds only a sample hash value, which is a small convenience but no semantics beyond what the schema documents. Baseline 3 is appropriate when the schema does the work.

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+resource ("Look up any transaction on Base by hash") and then enumerates exactly what comes back — status, sender/receiver, ETH value, method id, block, confirmations, gas, fee, contract creation. That is far beyond a restatement of the name. It stops short of a 5 because it never distinguishes itself from the sibling base_receipt, whose field set overlaps heavily with what is listed here.

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

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

It gives a concrete decision context: "Use to confirm that a payment or contract call went through before acting on it," which is a real when-to-use rule an agent can act on. It also states cost and free-tier conditions that affect whether to call. There are no exclusions, though — an agent choosing between base_tx and base_receipt gets no routing guidance.

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

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

Goes well beyond the annotations: it discloses billing ($0.01/call, x402 USDC or card key, first 25 free, failures free), error semantics (404 for a missing contract, 422 for non-ERC-20, both uncharged), and explains why repeats aren't free, which makes the given idempotentHint=false meaningful. It stops short of describing pagination or latency, but for a single fixed-arity read this is substantial added context.

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

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

One dense paragraph with the definition front-loaded, followed by use cases, the sibling pointer, input caveats, and billing. Every sentence is load-bearing, though the pricing clause is long enough to compete with the purpose statement for the agent's attention.

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 (raw and token-unit allowance, unlimited flag). Inputs, error paths, cost, and the read-only guarantee are all covered, so 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 baseline is 3, but the description adds value by tying the token parameter to concrete failure outcomes (missing contract → 404, non-ERC-20 → 422, uncharged). It restates the ticker-or-0x contract duality rather than adding new syntax detail, which caps it below 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?

Opens with a specific verb+resource: 'ERC-20 token allowance on Berachain', and enumerates the returned values (raw amount, token units, unlimited flag). It explicitly distinguishes itself from bera_token_balance, so an agent can route between approval lookup and balance lookup 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 ('check an approval before a swap' and 'audit risky open approvals') plus an explicit alternative and the condition that selects it ('for the owner's balance use bera_token_balance'). The when-to-use and when-not-to-use are both stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, but the description adds material context they don't carry: $0.01 per call via x402 USDC or card key, 25 free calls, failed calls free, malformed addresses rejected with 400 and uncharged, and repeats are billable. That pricing and error-handling profile is exactly what an agent needs before calling a paid endpoint.

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