ARYSPHERE x402 chain reads and token verdicts

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

Annotations only declare readOnlyHint=true, and the description adds substantial context: the grade is 'a stated rule over the contract's own state', the disclaimer is entertainment-only, and it explicitly does not make a safety or legitimacy call. This is meaningful behavioral disclosure beyond the annotation, though the payment/auth mechanics could be spelled out slightly more precisely.

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 well front-loaded, but the definition is long and embeds a full 'Measured output' JSON blob that inflates length considerably. The example is useful given the absence of an output schema, yet the verbosity costs it conciseness points.

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

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

With no output schema, the description fully compensates by enumerating return fields (grade, one_liner, roast, facts) and providing a concrete sample payload, plus the complete payment flow. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 100% and the single 'token' parameter is fully documented in the schema ('0x + 40 hex'). The description adds only that the target chain is Base, so it neither needs to nor does compensate for any gap. 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 ('Base ERC-20 verdict of a token contract address') and immediately delineates what it returns (grade, one-liner, roast, facts read). This clearly separates it from the sibling raw-read tools, which never produce a synthesized verdict.

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

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

Provides concrete operational guidance on the x402 payment handshake ('call once with no payment... retry with the signed payment at _meta["x402/payment"]') and draws boundaries ('does not read holders, liquidity or price'). It stops short of explicitly naming when to prefer a sibling raw-read over this verdict tool.

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

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

Annotations only cover read-only safety, so the description carries the behavior burden and does add real context: the two-step payment requirement and the _meta['x402/payment'] retry key. It also surfaces side effects like proxy detection, implementation address, and verification status. It stops short of stating the actual price terms or rate limits, so not a 5.

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

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

Purpose and payment flow are front-loaded, which is good, but the trailing 'Measured output' JSON blob is large and visibly truncated, making the description bloated rather than tight. Some return-shape evidence is useful since no output schema exists, but the dump is unnecessarily verbose.

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 showing the return shape (abi, address, implementation, isProxy, proxy, verified) and by documenting the payment handshake. Parameter semantics are fully carried by the schema, so the remaining gaps are minor.

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

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

Schema description coverage is 100% and the single 'address' param is fully documented in the schema ('contract, 0x + 40 hex'). The description adds no format or syntax detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Returns the ABI of a contract on Base from its address') and names the token standards covered (ERC-20 / ERC-721 and others). It is clearly distinguishable from siblings like base_erc20_balanceof, base_erc721_ownerof, and the Ethereum-mainnet eth_mainnet_contract_abi variant.

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

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

The description gives procedural invocation guidance for the x402 payment handshake ('Call once with no payment... Retry the same call with the signed payment'), which is valuable. However, it offers no guidance on when to prefer this tool over alternatives (bundles, network_info_summary, or the Ethereum ABI sibling) — usage is only implied.

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

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

Annotations only declare readOnlyHint=true, so the description adds real value beyond them: the two-step unpaid-then-paid handshake and where the signed payment must be placed. It does not cover failure modes (invalid token, reverts), but for a read tool the payment protocol disclosure is substantive.

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?

Reasonably front-loaded with the core purpose first, but it redundantly re-specifies token and address details already fully covered by the schema, and the endpoint URL line adds little for an agent that already has the tool bound.

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 supplies a measured output example showing the result shape ('result': '70000'), plus the payment protocol. An agent has everything needed to call and interpret this simple two-param read.

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

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

Schema description coverage is 100%, so the schema already documents token and address. The description restates them with the same '0x + 40 hex' detail, adding no meaning beyond the schema; baseline 3 applies.

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

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

Names a specific verb (read balanceOf), resource (Base ERC-20 token balance), and scope (holder address on Base). It is clearly distinguishable from siblings like base_erc721_ownerof, base_eth_getbalance, and the eth_mainnet erc20_balanceof variant.

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

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

Provides concrete invocation context for the x402 payment flow: call once without payment to receive terms, then retry with the signed payment at _meta['x402/payment']. However, it gives no guidance on when to prefer this over alternatives such as network_info_balance_bundle or eth_mainnet_erc20_balanceof.

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

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

Annotations only supply readOnlyHint=true, so the description must carry the rest — and it does, disclosing the non-obvious payment handshake (first call returns terms, second call needs the signed payment at _meta['x402/payment']) plus a concrete result payload. It does not describe failure/error behavior, keeping it short of a 5.

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

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

Purpose is front-loaded, followed by invocation mechanics and a sample payload. Every sentence is relevant, though the long embedded 'Measured output' JSON and the repeated GET URL are slightly bulky for what they convey.

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

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

With no output schema, the description supplies a measured output payload so the agent knows the return shape, and it covers the payment flow. What remains thin is error/edge behavior (e.g., non-existent token id or non-ERC-721 contract), which the agent would have to discover at runtime.

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 in the schema. The description restates the same formats ('0x + 40 hex' for token, decimal for id) without adding syntax or validation meaning beyond the schema, which is the baseline expectation.

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 ('owner of a token id', 'returns the address that ownerOf(id) reports') with named inputs and the Base chain scope, which cleanly separates it from the eth_mainnet_erc721_ownerof sibling. An agent can identify the operation 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?

The description explains the two-step x402 invocation flow (call once unpaid to get terms, retry with signed payment), which is valuable. It does not, however, state when to prefer this tool over alternatives such as the ETH-mainnet erc721_ownerof sibling or a generic eth_call; chain selection is only implied by the name.

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 annotation, the description discloses a real behavioral trait: the two-step payment handshake where the first call returns only payment terms and must be retried with a signed payment. It also supplies the measured output shape, so the agent knows what a successful response looks like. This is substantive context the annotations do not carry.

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

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

Front-loaded with the purpose and the chain before any operational detail, which is the right ordering. The HTTP URL and payment paragraphs read as templated boilerplate and could be trimmed, but the measured-output line earns its place given there is no output schema.

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

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

With no output schema, the description carries the return-value burden and discharges it via the 'Measured output' example. It also covers the payment requirement and the exact parameter. Only error/failure responses and rate-limit behavior are unaddressed.

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

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

Schema description coverage is 100% and the single 'address' parameter is already documented as '0x + 40 hex'. The description merely repeats that same constraint verbatim, adding no syntax, validation, or example beyond the schema. Baseline 3 is the correct ceiling here.

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

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

States a specific verb+resource ('Returns the native ETH balance of a Base address via eth_getBalance') and the exact network, which cleanly separates it from the gnosis_eth_getbalance and eth_mainnet_eth_getbalance siblings. An agent can identify both the operation and the chain 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?

The description gives operational guidance for the x402 flow ('Call once with no payment... Retry the same call with the signed payment at _meta["x402/payment"]'), which is useful invocation context. However it never states when to prefer this tool over chain alternatives (Gnosis, Ethereum mainnet), leaving selection entirely to the name. Adequate but with a clear gap in alternative routing.

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

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

Annotations already declare readOnlyHint=true, but the description adds genuine behavioral context beyond that: the two-step payment negotiation flow and the exact location to attach the signed payment. It does not, however, disclose rate limits, error/retry behavior, or what constitutes a settled payment failure.

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 opening sentence is well front-loaded, but it is followed by an enormous raw 'Measured output' JSON blob that dominates the definition and is not structured as a readable example. The prose is reasonable; the unstructured dump is wasteful.

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

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

For a single-parameter read tool with readOnlyHint and no output schema, the description covers the payment flow and shows a concrete sample of the returned block shape, which compensates for the missing output schema. Enough 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 'block' parameter is already documented as 'a block number, or latest'. The description only restates this ('block number or latest') without adding format details such as hex encoding expectations, so the baseline 3 applies.

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

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

States a specific verb and resource ('Base on-chain read: a block by number or latest') and names the method eth_getBlockByNumber. The chain is explicit, which distinguishes it from the eth_mainnet and gnosis siblings, though no sibling is named directly.

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

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

The x402 payment handshake is clearly described (call once unpaid to get terms, retry with the signed payment at _meta['x402/payment']). However, there is no guidance on when to choose this Base block-read over the many alternative chain/block-read siblings - usage is only implied from the chain name.

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 only readOnlyHint=true in the annotations, the description carries most of the burden and delivers: the two-step x402 payment handshake, the default window (last 10 blocks, capped at 100), and the fact that results can come back with truncated=true. It goes well beyond what the annotation declares, though it doesn't discuss rate limits or auth beyond payment.

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 parameter formats are front-loaded before the payment protocol, which is the right ordering. The trailing 'Measured output' block is a long raw JSON dump, but since no output schema exists it does earn some of its space by showing the return shape; it is still heavier than necessary.

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

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

With no output schema, the description justifiably explains the return structure (count, from_block/to_block, logs array, truncated) and the payment flow, and all three params are covered. Nothing critical for a correct call is missing, aside from guidance on selecting this tool over its siblings.

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

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

Schema description coverage is 100%, so the schema already documents address (0x + 40 hex), topic0 (0x + 64 hex), and blocks (1-100, default 10). The description largely restates those same constraints rather than adding new semantics, so it sits at the baseline for a fully-covered 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 opening sentence gives a specific verb and resource ('on-chain read: a contract's event logs') plus the two filter axes (topic and block range). The chain qualifier 'Base' and the method name 'eth_getLogs' cleanly separate it from siblings like eth_mainnet_eth_getlogs and gnosis_eth_getlogs without needing to open a schema.

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

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

It documents an important calling protocol (call once with no payment to get terms, then retry with the signed payment at _meta['x402/payment']), which tells the agent how to invoke the paid route. However, it never states when to choose this over the sibling read tools (e.g., the mainnet or gnosis getLogs variants, or the bundle tools) or what conditions make it the wrong 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?

Beyond the readOnlyHint annotation, it discloses the null-return case when the node does not know the hash, the exact return field set, and the two-step x402 payment handshake. That is substantial behavioral context an agent needs to invoke it correctly.

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 payment flow are front-loaded, but the measured-output block dumps a full raw transaction including a long hex input blob, which is heavier than needed when a field list would suffice. Useful content, but not 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 compensates by enumerating return fields and showing a concrete result, and it explains the payment flow. Minor gaps remain around error/rate-limit behavior, so it is strong but not fully complete.

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

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

Only one parameter with 100% schema coverage, so the schema already documents 'transaction hash, 0x + 64 hex'. The description repeats the same format note without adding syntax or validation 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?

States a specific verb and resource ('Base on-chain read: a transaction by its hash') and names the underlying RPC method. The 'Base' qualifier plus the method name distinguishes it from the sibling eth_gettransactionbyhash on mainnet and from getblockbynumber/getlogs variants.

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

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

The description gives invocation mechanics (call once without payment, then retry with the signed payment at _meta['x402/payment']), which is useful procedural guidance. However it never says when to prefer this tool over siblings such as the tx_receipt or bundle tools, leaving selection inference to the hash parameter.

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

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

Annotations only declare readOnlyHint=true; the description adds meaningful behavior beyond that, notably atomicity ('the call succeeds only when every part answers') and the two-step payment handshake. These are non-obvious traits an agent must know before calling. It stops short of describing latency, cost, or partial-failure semantics beyond all-or-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 payment instructions are tight and front-loadable, but the opening is padded: 'in one paid call' appears three times and the part-keying behavior is stated twice in near-identical sentences. One of those sentences should be cut.

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-shape burden and does so by explaining results are keyed by part name, matching each part's standalone output. It also covers the payment flow end to end. Only the missing when-to-bundle guidance leaves a gap.

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

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

Schema description coverage is 100% with a single required 'address' parameter, so the schema already documents the input. The description contributes only the meta-rule that the bundle takes the union of the parts' query parameters, which is useful but thin. 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?

It states a specific verb+resource: a paid bundle that returns base_eth_getbalance and network_info_summary results in one call, keyed by part name. It names the constituent sibling services, so an agent can distinguish it from calling base_eth_getbalance alone. The repetitive phrasing ('in one paid call' three times) muddies rather than clarifies, but the intent is legible.

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 invocation mechanics: call once with no payment to retrieve payment terms, then retry with the signed payment at _meta['x402/payment']. However, it never states when to use the bundle versus buying the individual parts alone, which is the key selection decision for this tool.

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

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

Beyond the readOnlyHint annotation, it discloses non-obvious behavior: call once unpaid to receive payment terms, then retry with a signed payment at _meta["x402/payment"]. This is genuinely useful auth/payment context an agent would otherwise not know, though it omits cost amounts, rate limits, and error/rejection behavior.

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

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

Purpose is front-loaded, which is good, but the raw 'Measured output' JSON blob (including verbose hex fields) is bulky and largely restates a single example. Sentences mostly earn their place, but the template scaffolding (GET URL, payment restatement) adds redundancy.

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

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

With no output schema and no parameters, the description compensates by supplying a sample output and payment flow, which is helpful. However, the chain mismatch (Gnosis vs. Ethereum) and the sample's service field 'network_info_summary' (a sibling's name) leave the agent confused about what this tool actually returns.

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

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

There are zero input parameters at 100% schema coverage, so the baseline is 4. The description's mention of _meta["x402/payment"] is a protocol detail rather than a declared parameter, and no further parameter meaning is required.

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 stated purpose, 'Gnosis Chain network data in one call,' is vague and, worse, contradicts the description's own measured output, which reports "chain": "ethereum" and chain_id 1. An agent cannot reliably tell whether this tool targets Gnosis or Ethereum, and the generic phrase 'network data' does not distinguish it from siblings like network_info_summary or eth_mainnet_gasprice.

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

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

The description explains the two-step payment handshake but offers no guidance on when to choose this tool over the many sibling chain-read tools, nor any condition/exclusion. Payment mechanics are usage-relevant, but the when-vs-alternatives dimension is entirely absent.

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

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

Annotations only carry readOnlyHint=true, so the description adds real behavioral context: the two-step unpaid-then-paid x402 flow and the fact that the first call returns payment terms rather than the chain id. It even supplies the measured output shape. It stops short of 5 by not covering error cases or whether the payment step is metered.

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 payment-flow and measured-output sentences are dense and front-loaded, but the opening is redundant: 'the chain id the node reports' and 'Ethereum mainnet' each appear twice in the first two sentences, restating the same fact.

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 parameterless read with no output schema, it covers everything an agent needs: the resource, the absence of inputs, the x402 payment handshake, and a concrete example of the return payload. Nothing material is missing.

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

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

Zero parameters and 100% schema coverage, so the baseline is 4. The description reinforces this with 'takes no query parameters', which correctly tells the agent nothing needs to be supplied.

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: an Ethereum mainnet on-chain read returning the chain id the node reports. This is unambiguous and distinguishable from the many base_/gnosis_/eth_mainnet_ siblings, which expose different resources on different chains.

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

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

It explains the invocation protocol explicitly: call once with no payment to receive the payment terms, then retry the same call with the signed payment at _meta["x402/payment"]. That is concrete when-and-how guidance. It does not name alternative siblings or state when to prefer this over e.g. network_info_summary, so it stops short of 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, so the safety profile is covered. Beyond that, the description discloses a non-obvious behavior the schema and annotations do not: the two-step x402 payment handshake (unpaid call returns terms, signed retry executes) and that the block is returned 'exactly as the node gives it'. That is meaningful operational 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?

Purpose is front-loaded and the payment steps are compact, but the trailing 'Measured output' block dumps a full raw block object with dozens of hash fields. While it illustrates the return shape in the absence of an output schema, it is far larger than needed and hurts overall conciseness.

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

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

For a one-parameter read with no output schema, the description covers purpose, chain scope, the x402 payment protocol, and an example return payload, which is close to complete. It only lacks explicit sibling-selection guidance, which is minor given the clearly namespaced method name.

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 `block` parameter is already documented as 'a block number, or latest'. The description merely restates that same semantics, adding no format detail (e.g., hex vs decimal) beyond the schema, so the baseline 3 applies.

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

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

States a specific verb, resource, and chain scope: 'Ethereum mainnet on-chain read: a block by number or latest', reinforced by the underlying method name eth_getBlockByNumber. Naming the chain (Ethereum mainnet) plus the method lets an agent separate it from the Base/Gnosis and eth_reads_v1 sibling variants without opening any schema.

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

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

It gives clear invocation guidance for the x402 flow: 'Call once with no payment. The result is the payment terms. Retry the same call with the signed payment at _meta["x402/payment"].' That is useful procedural context, but there is no guidance on when to choose this tool over sibling reads (e.g., Base getBlockByNumber, or eth_blockNumber), so selection guidance is only implied.

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

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

Annotations only declare readOnlyHint=true; the description adds meaningful behavior beyond that: the two-step payment handshake, the fact that a null return means the node does not know the hash, and that the raw node shape is passed through. That is real unannotated context, though it omits retry/expiry semantics for the payment.

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 is front-loaded and the payment protocol is clearly sequenced, but the full pretty-printed measured output blob is large and largely redundant with the plain statement that the raw transaction is returned. It earns some value as a return-shape sample but is heavier than needed.

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 embedded measured-output sample usefully conveys the return shape, and the payment flow is spelled out. It is close to complete for a single-parameter read, missing only failure/expiry behavior for the signed payment retry.

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

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

Schema coverage is 100% for the single `hash` parameter, and the description's '0x + 64 hex' restatement duplicates the schema. Baseline 3 is appropriate since the schema already carries the semantics.

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

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

States a specific verb and resource ('on-chain read: a transaction by its hash') and pins the network to Ethereum mainnet, which is exactly the distinction that separates it from base_eth_gettransactionbyhash and eth_mainnet_eth_gettransactionbyhash in the sibling list.

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

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

The description gives strong invocation guidance (call once unpaid to get terms, retry with a signed payment at _meta["x402/payment"]), but never states when to choose this tool over sibling reads or the base/eth_reads variants. Usage context is implied rather than stated as selection criteria.

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 readOnlyHint=true by disclosing the block height used (latest), the return encoding (raw hex wei), and the two-step paid-call handshake. However, the 'Measured output' example is an unedited template showing "chain": "base" and service "x402_chain_reads_v1.base_eth_getbalance" for a Gnosis tool, which is mildly misleading context.

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

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

Front-loads the verb, resource, and chain, then adds payment protocol and output shape in short paragraphs. Slight redundancy between 'the native balance of an address' and 'Native xDAI balance of one address', and the stale output example 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?

There is no output schema, so the description supplies the return shape itself (chain/hex/method/ok/result/service), states the payment flow required to actually retrieve data, and covers the only parameter. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single address parameter is already fully documented in the schema. The description restates the '0x + 40 hex' format without adding format, validation, or error semantics beyond it, so baseline 3 applies.

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

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

States a specific verb+resource (read the native balance of an address) and pins the chain (Gnosis) plus the precise semantics: xDAI native balance at the latest block, raw eth_getBalance in wei. This cleanly separates it from the sibling base_eth_getbalance and eth_mainnet_eth_getbalance.

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

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

The description explains the x402 invocation protocol in detail (call once unpaid to get payment terms, then retry with the signed payment at _meta["x402/payment"]), which is real usage guidance. It does not explicitly name sibling alternatives or when to prefer them, but the chain/method are unambiguous from the name and description.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden and does disclose meaningful traits: the two-step x402 payment handshake, the 'truncated' flag, and a concrete logged output shape. It loses a point because the sample output is labeled "chain": "base" / "base_eth_getlogs" while the tool is Gnosis, which muddies rather than clarifies the behavior.

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

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

The purpose is front-loaded in the first sentence, but the entry is bloated by the raw measured-output JSON (roughly two full log objects copied verbatim) and repetitive payment phrasing ('Same payment terms as that HTTP route'). The payload is large relative to the useful signal it carries.

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, inlining a return-value example is appropriate and the payment flow, filter dimensions, and block-range cap are all covered for a single-contract read. The main gap is that the example is copied from a Base call rather than a Gnosis one, so the agent cannot fully trust the illustrated 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 description coverage is 100%, so all three parameters ('address', 'topic0', 'blocks') are already documented in the schema. The description repeats the same hex formats and default-10 detail without adding syntax or edge-case meaning, so the baseline 3 applies.

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

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

States a specific verb and resource ('a contract's event logs') plus the exact method (eth_getLogs) and scopes it to one chain ('Gnosis Chain', 'one Gnosis contract'). This lets an agent distinguish it from the many sibling variants (base_eth_getlogs, eth_mainnet_eth_getlogs, etc.) 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?

The description clearly explains the invocation protocol (call once with no payment to retrieve terms, then retry the same call with the signed payment at _meta['x402/payment']), which is genuinely actionable context. However it gives no explicit guidance on when to prefer this over the base/eth_mainnet log tools or when a topic filter is required versus optional.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral load, and it does so well: it discloses the paid, two-step payment handshake, the all-or-nothing success condition, and that results are keyed by part name. This is context well beyond the 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?

The opening sentence is strongly front-loaded, but the body is padded: 'in one paid call' recurs three times and the return-shape sentence is wordy. The content mostly earns its place, yet it could be trimmed by a third without losing meaning.

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 explaining the return shape (each part's own result keyed by name) and the payment flow, and it notes the atomic success condition. An agent has enough to call it correctly; only the explicit preference over individual reads 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?

With only one parameter and 100% schema description coverage, the schema already documents 'address' as 0x + 40 hex. The description adds only that it takes the union of the parts' query parameters, which explains how the bundle's inputs are assembled but gives no extra format or validation detail for the address itself. 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+resource (a bundle performing several reads) and names the exact constituent services, network_info_summary and base_eth_getbalance, so an agent can distinguish it from the standalone siblings. It is mildly muddled by repeating 'in one paid call' three times, but the intent is unambiguous.

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

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

It gives an explicit invocation protocol: call once with no payment to obtain the payment terms, then retry with the signed payment at _meta["x402/payment"]. It also states the call succeeds only when every part answers, which is decision-relevant. It never explicitly says to prefer this bundle over calling the individual reads separately, which is the one routing gap.

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?

readOnlyHint=true already covers the safety profile, and the description adds genuinely non-obvious context: this is a paid x402 route where the first call returns payment terms and the second call with a signed payment at _meta['x402/payment'] returns data. That two-step flow is real behavioral value beyond annotations, though nothing is said about rate limits or error behavior.

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

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

It is front-loaded with purpose and the payment mechanics are stated compactly. The URL and payment sentence are somewhat repetitive, but the 'Measured output' block earns its space because there is no output schema, so it is the only signal of the return shape.

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 embedded sample response usefully documents the return payload (block number, base fee, gas price, chain id). Combined with the payment flow explanation, an agent has enough to invoke it correctly, though sibling differentiation is still missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description's mention of _meta['x402/payment'] is a framework-level injection, not a documented schema 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?

The lead line 'Base network data in one call' restates the tool name (network_info_summary) without a precise verb+resource, and 'Base' is ambiguous between the Base chain and 'basic'. It does not distinguish this from close siblings such as network_info_balance_bundle or chain_fees_digest. An agent can infer this returns chain-level stats, but only from the sample output, not from the prose.

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

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

The description explains the calling protocol thoroughly (call once unpaid to receive terms, then retry with the signed payment), which is valuable operational guidance. However, it gives no when-to-use/when-not guidance relative to the many sibling read tools, so selection still requires 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 only declare readOnlyHint, so the description carries most of the burden and does add value: it discloses the two-step payment handshake, the payment-terms-first behavior, and the conditional return ('when one is available for that address'). It does not, however, say what happens when no ABI exists (error vs empty).

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 is front-loaded and the payment instructions are useful, but the description is bloated: it repeats 'Ethereum mainnet contract ABI' twice and appends a large raw 'Measured output' JSON blob. Given no output schema exists the return example has some value, but it is verbose and uncurated rather than a crisp summary.

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

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

With no output schema, the description usefully includes a sample return payload and the payment flow, so an agent knows the response shape and the two-call pattern. It is nearly complete; only the no-ABI/not-found behavior is left unstated.

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

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

Schema coverage is 100%, so the schema already documents the single 'address' parameter. The description merely restates it ('contract, 0x + 40 hex') with no added meaning, format detail, or validation nuance beyond the schema. Baseline 3 applies.

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

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

States a specific verb+resource: it fetches the ABI for an Ethereum mainnet contract address, with a note on which standards apply (ERC-20/ERC-721 and others). This distinguishes it from the sibling base_contract_abi by chain, though the description never explicitly names that sibling or the chain-routing decision, so an agent must infer from the name.

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 real procedural guidance for the x402 flow ('call once with no payment... retry with the signed payment at _meta["x402/payment"]'), which tells the agent how to invoke it. However, it offers no when-to-use/when-not guidance versus alternatives, and no exclusions.

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

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

Annotations already declare readOnlyHint=true (a safe read), and the description adds meaningful context beyond that: the return is the raw allowance read from the contract, and the two-step x402 payment flow (unpaid call yields payment terms, retry carries the signed payment at _meta["x402/payment"]). That payment protocol disclosure is valuable behavioral information not present in 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?

The purpose is front-loaded, but the opening two sentences say the same thing twice ("Ethereum mainnet ERC-20 allowance a holder granted a spender. Ethereum mainnet ERC-20 allowance."), which is clear waste. The trailing payment-flow sentences do 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?

With no output schema, the description steps in to say it returns the raw contract allowance, and it explains the payment flow and all three required parameters. For a single-value read with a non-obvious auth/payment protocol, this is nearly complete.

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

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

Schema description coverage is 100%, so the schema already documents owner, spender, and token with their 0x+40 hex formats. The description merely restates the same parameter list and formats, adding no semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific resource and operation: read an ERC-20 allowance that a holder granted a spender on Ethereum mainnet. The resource (allowance) is inherently distinct from sibling reads like erc20_balanceof, erc20_totalsupply, and erc721_ownerof, so an agent can route to it. It falls short of a 5 only because it never explicitly names or contrasts those siblings.

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

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

It gives explicit invocation guidance for the x402 payment handshake (call once without payment to get terms, retry with the signed payment). However, it gives no guidance on when to choose this tool over alternatives such as erc20_balanceof, leaving selection to inference from the resource name.

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

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

With readOnlyHint already declaring a safe read, the description still adds substantial context: the underlying HTTP route, the two-step x402 flow (call once to get payment terms, retry with signed payment at _meta["x402/payment"]), and a measured output example. That is real behavioral value beyond annotations, though it omits error/failure behavior.

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

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

Front-loaded with the core purpose before the payment boilerplate and output sample. Slightly repetitive ('Ethereum mainnet ERC-20 balanceOf' restates the first clause) but every block carries information.

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

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

No output schema exists, so the description correctly supplies the return shape and a measured example. Combined with the payment flow, an agent has enough to invoke it, though response-field semantics (e.g. raw units/decimals) are 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% and both params are documented there with the same 0x + 40 hex format the description restates. The description adds no syntax or semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource+scope: reading an ERC-20 balanceOf for a holder on Ethereum mainnet. This clearly separates it from siblings like eth_getbalance (native), erc20_allowance, and erc20_totalsupply. 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?

The description implies usage (mainnet ERC-20 read) and documents the x402 payment handshake, but never states when to choose this over siblings such as eth_getbalance or the base-chain counterpart, nor any conditions/exclusions. Guidance is implied rather than explicit.

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

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

Annotations only declare readOnlyHint=true. The description adds meaningful behavior beyond that: the two-step x402 payment handshake, where the first call returns payment terms rather than the data, and the exact location for the signed payment. This is non-obvious and would trip up an agent that didn't know 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?

The first two sentences are near-duplicates, restating that this returns the total supply of an ERC-20 contract. That redundancy costs space without adding information, though the endpoint and payment-flow sentences are load-bearing and reasonably front-loaded.

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

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

For a read-only, single-parameter tool, the safety and payment mechanics are covered, but there is no output schema, so the description leaves the return shape (e.g., a decimal string vs. raw uint256, and how to interpret it) unspecified. Adequate but not fully complete.

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

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

There is a single parameter with 100% schema description coverage ('ERC-20 contract, 0x + 40 hex'), so the schema already documents it fully. The description repeats 'given token address' without adding format, validation, or example detail beyond the schema.

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

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

States a specific verb (read totalSupply), resource (ERC-20 token contract), and scope (Ethereum mainnet), which cleanly distinguishes it from sibling reads such as erc20_balanceof, erc20_allowance, or eth_getcode. An agent can identify the tool's purpose 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?

The description details the protocol-level usage pattern (call once unpaid to obtain payment terms, then retry with a signed payment in _meta['x402/payment']), which is genuinely useful procedural guidance. However, it gives no guidance on when to choose this tool over sibling reads like balanceof or contract_abi — that selection is left to inference from the name.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and does well: it discloses the x402 payment requirement, the two-step pay-then-retry flow, the payment metadata location, and a sample output shape. It does not cover failure modes or what happens if payment is missing, keeping it short of a 5.

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

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

The payload details and payment workflow are front-loaded and useful, but the description mixes purpose, payment mechanics, and a raw sample output in one block. The sample output also shows chain 'base' and a base_erc721_ownerof service string for an Ethereum mainnet tool, which is potentially confusing clutter.

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 supplying a measured output example and the full payment protocol, which is what an agent needs to invoke and interpret the call. The main gap is the absence of any error or payment-failure behavior.

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

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

Schema description coverage is 100%, so the schema already documents both params. The description restates 'token (contract address, 0x plus 40 hex)' and 'id (decimal token id)' without adding format, validation, or edge-case detail beyond the schema, matching the baseline 3.

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

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

The description states a specific verb and resource: 'Returns the owner address of an ERC-721 token on Ethereum mainnet.' The chain qualifier ('Ethereum mainnet') distinguishes it from the sibling x402_chain_reads_v1__base_erc721_ownerof, so an agent can pick the right chain 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 concrete procedural guidance for invocation ('Call once with no payment... Retry the same call with the signed payment at _meta["x402/payment"]'), which is useful. However, it never explicitly frames when to choose this over the Base mainnet sibling, leaving tool-selection to inference from the chain name.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the behavioral burden — and it does disclose the non-obvious two-step x402 payment handshake (first call returns terms, second returns data) and the HTTP route it mirrors. It does not state response shape for the paid retry, which keeps it short of a 5.

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

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

Front-loaded with the purpose and the no-param fact before the payment protocol, and every line is actionable. Slight redundancy in restating that it returns the latest block number twice ('the latest block number' / 'Returns the latest Ethereum mainnet block number via eth_blockNumber').

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

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

There is no output schema, so the description must carry return-value meaning, and it does specify what the first (payment-terms) call returns and the mechanics of the paid retry. For a zero-parameter read with a novel payment flow this is nearly complete, though the exact success payload is only implied.

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

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

Zero parameters, so the baseline is 4. The description explicitly confirms 'Takes no parameters', which removes any ambiguity about how to invoke 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+resource (read the latest Ethereum mainnet block number) and names the underlying RPC method (eth_blockNumber). Combined with 'Takes no parameters', an agent can distinguish it from the sibling eth_mainnet_getblockbynumber / eth_getblockbynumber, which require a block argument.

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

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

Gives explicit operational instructions: call once without payment to receive the payment terms, then retry with the signed payment at _meta["x402/payment"]. That is clear context for use, but it offers no guidance on when to prefer this tool over the sibling block/chain-read tools.

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

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

Annotations only carry readOnlyHint, and the description adds substantial context: the x402 payment negotiation protocol, the fact that the first call returns payment terms rather than data, and the hex/wei return format. The chain/service mismatch in the 'Measured output' block introduces ambiguity about what is actually returned, but no annotation is contradicted.

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 is correctly front-loaded, and the payment workflow is worth its space. But the raw HTTP URL and the oddly specific 'Measured output' JSON (internally inconsistent with the Ethereum mainnet claim) read as vendor noise that dilutes the signal.

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 a readOnlyHint annotation and no output schema, the description covers the operation, the return format (hex wei), and the payment handshake. The remaining gap is the confusing chain/base discrepancy that could mislead an agent about the data source.

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 'address' parameter is already documented as '0x + 40 hex' in the schema; the description merely restates this. The additional sentence about the wei return value concerns output, not parameter semantics, so this is the baseline 3.

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

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

The description gives a specific verb+resource: 'the native balance of an address' on Ethereum mainnet via eth_getBalance, which distinguishes it from ERC-20 balanceOf siblings and from base_/gnosis_ variants. It is slightly muddied by the embedded 'Measured output' block showing chain 'base' and a base_eth_getbalance service name, which conflicts with the claimed Ethereum mainnet scope.

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

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

The description explains the invocation flow (call once without payment to obtain terms, then retry with the signed payment at _meta['x402/payment']), which is genuinely useful operational guidance. However it never states when to choose this tool over the many sibling read tools (e.g., erc20_balanceof for tokens), leaving selection 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 only declare readOnlyHint, so the description carries the rest of the burden and does so well by disclosing the non-obvious x402 payment handshake and the HTTP route it wraps. It stops short of mentioning rate limits, failure modes, or what happens before payment is settled.

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 payment instructions are front-loaded and tight, but the trailing "Measured output" block is a large raw JSON dump including a multi-hundred-character logsBloom value that adds bulk without proportionate value. It could have been summarized as a field list instead.

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 showing a concrete measured result, so an agent can anticipate the return shape, and it explains the payment protocol end-to-end. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents the single `block` parameter fully. The description restates "a block number, or 'latest'" without adding format, hex/decimal, 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+resource and chain scope: "Ethereum mainnet on-chain read: a block by number or 'latest'" mapped to eth_getBlockByNumber. It does not, however, distinguish itself from the near-identical siblings x402_chain_reads_v1__eth_getblockbynumber and x402_eth_reads_v1__eth_mainnet_getblockbynumber, which an agent could easily pick by mistake.

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 clearly explains the two-phase invocation (call with no payment to fetch terms, then retry with the signed payment at _meta["x402/payment"]), which is genuinely useful. But it gives no guidance on when to choose this tool over the other block/fetch siblings, which is the harder selection problem 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 only declare readOnlyHint=true, and the description adds genuinely important behavior: the call has a two-step payment flow where the first unauthenticated call returns payment terms rather than data. That is non-obvious and would otherwise cause an agent to misread an empty/failed first response. It stops short of describing output shape or failure modes.

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, followed by the payment mechanics, with no filler. The GET URL and 'same payment terms as that HTTP route' line is mildly redundant for a function-call interface but does anchor the tool to the underlying route.

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 does compensate by stating the return value ('the contract bytecode') as well as the payment handshake. The only real gap is the absence of error/empty-account semantics (e.g., bytecode '0x' for EOAs), which would matter for a getCode tool.

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

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

Schema description coverage is 100% and the single 'address' parameter is described there as '0x + 40 hex'. The description only restates that same format, adding no new meaning beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb ('read'), resource ('the deployed bytecode at an address'), and scope ('Ethereum mainnet'), plus the underlying RPC method (eth_getCode). This cleanly separates it from siblings like eth_mainnet_contract_abi (ABI JSON) or erc20_balanceof, so an agent can pick it without opening a schema.

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

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

Gives concrete invocation procedure for the x402 payment handshake: call once for the payment terms, then retry with the signed payment at _meta["x402/payment"]. That is clear operational context. It does not, however, state when to prefer this over an alternative read tool (e.g., contract_abi) or any exclusion, so it falls short of the top mark.

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

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

Annotations only supply readOnlyHint=true; the description adds the non-obvious behavioral trait that this endpoint requires a two-step x402 payment handshake, which an agent could not learn from the schema or annotations. It does not explain rate limits or the truncation behavior visible in the sample output ('truncated': true), which would be 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?

The purpose and payment instructions are front-loaded and useful, but the description then pastes a massive, truncated raw log dump that consumes most of its length and carries little transferable information. That bulk is not earned and dilutes the actionable content.

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

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

With no output schema, the description does carry the return-value burden, and the sample output does convey the response shape (count, from_block/to_block, truncated, log fields). Combined with the payment-flow detail, an agent has enough to invoke and parse the call, though the sample's 'chain: base' / 'base_eth_getlogs' service field contradicts the mainnet framing and is left unexplained.

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

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

Schema description coverage is 100%, so the schema already documents address, topic0, and blocks including the 1-100 range and default. The description restates those same facts without adding format examples or guidance on combining filters, so it sits at 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 ('a contract's event logs, filtered by topic and block range') and pins the chain to Ethereum mainnet, which separates it from the base_ and gnosis_ getlogs siblings. It does not, however, distinguish itself from the same-chain sibling eth_mainnet_logs_and_tx, so an agent still has to infer which log-shaped tool to pick.

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

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

The x402 payment protocol is explained concretely ('Call once with no payment. The result is the payment terms. Retry the same call with the signed payment at _meta["x402/payment"]'), which is real usage guidance. But there is no when-to-use versus the alternative log/transaction tools (eth_mainnet_logs_and_tx, tx_receipt), so selection guidance is only implied.

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

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

Annotations only declare readOnlyHint=true; the description goes well beyond that by disclosing the two-step payment flow, the exact metadata key for the signed payment, and a concrete sample response. This is meaningful behavioral context an agent needs before calling. It stops short of 5 because it does not mention rate limits, error behavior, or what happens if the hash is unknown.

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 payment protocol are front-loaded and tight, but the 'Measured output' block pastes a very long raw JSON dump full of opaque hex fields that consumes most of the text. It is informative yet far more verbose than needed to convey the return shape.

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 showing a measured response, and it fully covers the payment requirement and endpoint. An agent has everything needed to call 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 description coverage is 100% and the single hash parameter is fully documented in the schema ('transaction hash, 0x + 64 hex'). The description only restates 'by its hash' and adds no format, casing, 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?

The description names a specific verb (read), resource (a transaction), identifier (by hash), chain (Ethereum mainnet) and the underlying RPC method (eth_getTransactionByHash). This is enough to separate it from the sibling base/gnosis variants of the same method and from adjacent reads like tx_receipt or logs_and_tx.

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

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

It gives a clear usage protocol for the x402 payment handshake (call once unpaid to get terms, retry with the signed payment at _meta["x402/payment"]), which is genuine usage guidance. However, it never states when to prefer this tool over alternatives such as eth_mainnet_tx_receipt or eth_mainnet_logs_and_tx, so the selection guidance is only implied.

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

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

Annotations already mark this readOnlyHint=true, but the description adds genuinely non-obvious behavior: the two-phase payment flow where the first unpaid call returns payment terms and only the retry with a signed payment yields data. That is meaningful behavioral context beyond the annotations, though return format/pagination is not covered.

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

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

Front-loaded with the purpose sentence, followed by the HTTP-route and payment details. The URL line and payment boilerplate are somewhat verbose but appear to be the required x402 protocol framing rather than filler.

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

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

With no output schema, the description carries the return-value burden and does so ('Returns the number of transactions sent from an Ethereum address'). Combined with the payment-flow guidance, an agent has enough to invoke it correctly; a note on the numeric/hex encoding would make it fully complete.

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

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

Schema description coverage is 100% ('0x + 40 hex'), so the schema already documents the single parameter. The description adds only the semantic framing that the address is a transaction sender whose sent-count is returned, which is marginal over the schema 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 — an Ethereum mainnet on-chain read of an address's transaction count (nonce) — and includes the underlying RPC method name (eth_getTransactionCount). This clearly separates it from siblings such as eth_getbalance, eth_getcode, or erc20_balanceof.

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

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

Gives explicit operational guidance for the x402 payment handshake: 'Call once with no payment. The result is the payment terms. Retry the same call with the signed payment at _meta["x402/payment"].' That is a clear when-and-how, though it does not contrast usage against sibling read tools.

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

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

Annotations only declare readOnlyHint=true; the description adds meaningful behavior beyond that, including the return unit (wei), the zero-parameter nature, and the two-step x402 payment handshake. It stops short of describing rate limits or error conditions, so it is strong but not exhaustive.

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

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

The purpose is front-loaded in the first sentence, and the payment procedure follows logically. It is slightly redundant, restating 'the current gas price in wei' across two sentences, which costs a little tightness.

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 a trivial input schema, the description carries the load well by stating the returned value and unit plus the payment flow. Only the payment-terms response shape and any failure modes are left unstated, which is a minor gap.

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

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

There are zero parameters, so the baseline is 4. The description correctly and explicitly confirms 'takes no parameters', matching the empty schema, with no misleading parameter hints.

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+network: an Ethereum mainnet on-chain read returning the current gas price in wei, and explicitly notes it takes no parameters. This distinguishes it from siblings such as eth_mainnet_eth_blocknumber or x402_chain_reads_v1__chain_fees_digest at a glance.

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

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

Provides clear procedural guidance for invocation: call once without payment to obtain payment terms, then retry the same call with the signed payment at _meta["x402/payment"]. It does not, however, state when to prefer this over the chain_fees_digest sibling or other fee-related reads, so selection guidance is absent.

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

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so usefully: it discloses the two-phase payment handshake, the exact metadata key for the signed payment, and the shape of the returned payload. It does not mention rate limits, failure modes, or the fact that the second call's payment terms must match the first.

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 payment instructions are front-loaded and useful, but a ~2KB verbatim dump of a block header is pasted inline. That raw JSON is mostly unreadable noise and crowds out any concise summary of the return shape that would have served the same purpose in a fraction of the space.

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 sample payload does at least ground the agent in the return shape, and the payment flow is fully described. Combined with a fully documented single parameter, an agent has what it needs to make the call correctly; only failure/error behavior is left 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 'block' is already documented in the schema as 'a block number, or latest'. The description restates the same semantics without adding format detail (hex vs decimal, tag options), so it adds nothing beyond structured fields. 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: an Ethereum mainnet on-chain read that returns the block header for a given block number or 'latest'. Clear on its own, but it never distinguishes itself from the near-identical sibling x402_eth_reads_v1__eth_mainnet_eth_get_block_by_number, which an agent could easily confuse with this one.

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 invocation guidance for the x402 flow: 'Call once with no payment. The result is the payment terms. Retry the same call with the signed payment at _meta["x402/payment"].' That is genuinely actionable and not derivable from the schema. It offers no when-not guidance or alternative-selection criteria against the many sibling chain-read tools.

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

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

With readOnlyHint already covering the safety profile, the description adds real behavioral context: all-or-nothing execution (call succeeds only when every part answers), union semantics for combining part parameters, and the two-step x402 payment handshake. It does not discuss error behavior when a part fails or any return-shape details, keeping it short of a 5.

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

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

Purpose is front-loaded and the payment mechanics come last, which is sound ordering. But the first paragraph repeats "in one paid call" three times and opens two consecutive sentences with "Returns:", and one sentence is grammatically clipped ("each named part service's own result"), so the text is padded rather than 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?

For a bundle tool with no output schema, the description covers what is returned (both part results keyed by part name), the all-or-nothing condition, parameter merging, and the full payment flow. An agent has enough to invoke it correctly; only per-parameter-to-part mapping and failure-mode detail are absent.

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

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

Schema description coverage is 100%, so the schema already documents hash, address, blocks, and topic0. The only added semantics is that the tool takes the union of the parts' query parameters, which explains combining but not how each parameter maps to which part (logs vs tx). Baseline 3 is appropriate.

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

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

States a specific composition: an Ethereum mainnet bundle returning eth_getLogs plus eth_getTransactionByHash results, which is distinguishable from the sibling single-read tools (eth_mainnet_eth_getlogs, eth_mainnet_eth_gettransactionbyhash). However it never explicitly names those siblings or contrasts itself with them, relying on the reader to infer the bundle relationship.

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 operating guidance: call once with no payment to obtain payment terms, then retry with the signed payment at _meta["x402/payment"]. It also states the call succeeds only when every part answers, which tells the agent this is an all-or-nothing bundle. It stops short of explicitly routing the agent away from the individual single-read tools when only one result is needed.

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?

readOnlyHint=true already covers the safety profile, but the description adds real context beyond annotations: the return contents (status, block, gas used, logs) and the non-obvious two-call payment protocol. It does not state rate limits or error behavior, but for a simple read this is strong supplementary disclosure.

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

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

Front-loads the purpose well, but repeats essentially the same content three times ('transaction receipt...', 'via eth_getTransactionReceipt', 'Returns the node's receipt...') and says 'Ethereum mainnet' redundantly. The payment instructions are useful but the receipt description is not 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 does the required work of naming what the receipt contains and explaining the payment flow, so an agent has enough to invoke it correctly. Minor gap: no mention of failure modes (e.g., pending/missing transactions).

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

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

Schema description coverage is 100%, so the single hash parameter is fully documented. The description merely restates the '0x + 64 hex' format already present in the schema and adds no new semantic meaning, making the baseline 3 correct.

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 an Ethereum mainnet transaction receipt by hash, and enumerates the returned fields (status, gas used, logs). It is clearly distinct from the sibling eth_gettransactionbyhash (which returns the transaction, not the receipt), though it never names that sibling to make the distinction explicit.

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 operational flow for the x402 payment handshake (call once unpaid to get terms, retry with the signed payment at _meta['x402/payment']), which is valuable. However, it offers no guidance on when to choose this tool over the sibling transaction/block/log readers, so usage selection is left to inference.

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