Block402

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

Beyond the annotations, the description discloses the per-call cost (0.002500 test USDC on eip155:84532) and instructs the caller to preserve the idempotencyKey for retries, which is valuable context. It reconciles the readOnlyHint=false annotation by explaining the payment side effect. It still does not describe the response payload.

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

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

Three short sentences, each carrying distinct information (what, cost, retry handling), with the purpose front-loaded. No filler.

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

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

For a zero-parameter read RPC this covers the operation, cost, and key handling. With no output schema, the description should explain what the call returns (the best block hash), which it omits.

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 50%: the idempotencyKey is fully documented in the schema, and the description reinforces its retry/persistence semantics. The 'params' array (maxItems 0) is left unexplained in both schema and description, though it is an empty-by-design placeholder. 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 verb ('Read') and the resource name, plus the target chain (bip122:0000...). However, 'getbestblockhash' is an opaque RPC method name and the description does not decode what it returns (the hash of the most recent block), nor does it distinguish it from the sibling bitcoin_getblockhash. It reads close to a restatement of the tool 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?

There is no guidance on when to use this versus the many sibling methods (e.g. bitcoin_getblockhash, bitcoin_getblockheader). The only operational notes concern cost and idempotency-key handling, not tool selection.

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

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

Annotations cover idempotency and safety, but the description adds genuinely non-derivable behavior: a concrete cost (0.005000 test USDC on eip155:84532) and the instruction to persist the private idempotencyKey across retries. It still omits what happens on payment failure or what the response contains.

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

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

Three short sentences with no filler, and the cost/idempotency facts are easy to extract. The opening 'Read getblock from Bitcoin' is the weakest part but doesn't pad the rest.

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 doesn't describe return shape or the meaning of the verbosity flag, though for a paid RPC read the cost and idempotency notes cover the most agent-critical unknowns. The positional params gap keeps it from being complete.

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

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

Schema coverage is 50%: idempotencyKey is documented in the schema, but the required positional 'params' tuple (64-hex block hash plus a 0/1 verbosity flag) has no description anywhere. The description repeats the idempotencyKey advice but says nothing about the params array, which is the harder parameter to guess.

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 verb ('Read') and resource ('getblock') scoped to a specific Bitcoin chain identifier, but 'getblock' largely restates the tool name and the description never says what the call actually returns or how it differs from close siblings like bitcoin_getblockheader or bitcoin_getblockhash.

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?

There is no guidance on when to choose this tool over the many sibling block/transaction readers, nor on prerequisites such as payment or verbosity selection. The only usage-adjacent note is to preserve the idempotency key for retries.

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

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds genuinely new context the annotations don't carry: the price (0.002500 test USDC), the payment network (eip155:84532), and the requirement to persist the idempotency key across retries. Note the mild tension between 'Read' and readOnlyHint=false, though the payment side effect plausibly justifies the non-read-only hint rather than contradicting it.

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

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

Three short, front-loaded sentences with no filler: what it does, what it costs, how to retry. Minor deduction because the idempotency sentence largely duplicates the schema's own wording rather than adding new information.

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

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

There is no output schema, so the description should describe the return value (the chain height), which it never does — a real gap for a read tool. Payment and retry semantics are complete, but an agent still cannot tell what the call yields.

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 50%; the idempotencyKey is already richly documented in the schema, and the description only restates its retry/persistence purpose. The 'params' array is undocumented but is an empty array (minItems/maxItems 0), so there is nothing meaningful to explain — 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+resource ('Read getblockcount from Bitcoin') and pins the exact chain via its CAIP-2 identifier, so the agent knows this returns Bitcoin's block height. It does not explicitly differentiate itself from the analogous sibling ethereum_eth_blockNumber or the other bitcoin_getblock* tools, so it falls short of a 5.

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

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

No when-to-use or when-not-to-use guidance and no alternatives named, even though ~40 sibling chain-read tools exist. The only actionable instruction ('Preserve the private idempotencyKey for retries') is about retry mechanics, not tool selection.

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

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

Annotations cover safety flags, but with readOnlyHint=false on a nominal "read" the description usefully fills the gap by disclosing the paid nature (0.002500 test USDC on eip155:84532) and the retry/idempotency expectation. The payment cost and retry semantics are non-obvious behavioral facts that go beyond the annotations.

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

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

Three short sentences with little padding, but the lead sentence is a tautology that consumes prime real-estate while the two genuinely informative facts (cost, retry) are pushed to the back. Not wasteful, but not front-loaded with purpose either.

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 would need to convey the return value (the block hash for the given height), and it does not. Combined with the undocumented block-height parameter and the missing payment-flow detail, an agent lacks what it needs to call this confidently.

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 only 50% and the one undocumented parameter, the single-element `params` array, is left completely opaque — the description never says it is the block height. It adds only retry meaning for idempotencyKey, which the schema description already covers, so it fails to compensate for the gap.

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

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

"Read getblockhash from Bitcoin" essentially restates the tool name plus the chain identifier; it never says the tool maps a block height to its hash. Crucially it does not distinguish itself from the nearly identical sibling bitcoin_getbestblockhash, so an agent cannot tell which to pick from the text alone.

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

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

There is no when-to-use guidance and no mention of alternatives, even though bitcoin_getbestblockhash performs an obviously adjacent lookup. The only procedural note (preserve the idempotencyKey for retries) is a mechanical instruction, not selection guidance.

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

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

Annotations only cover the safety profile (idempotentHint=true, readOnlyHint=false), and the description adds genuinely useful behavior: the call costs 0.0025 test USDC on eip155:84532 and the idempotencyKey must be preserved across retries. This explains why readOnlyHint is false (a paid call) and tells the agent how to retry safely, though it omits failure/refund behavior.

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

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

Three short, front-loaded sentences with no filler; the cost and retry constraints are stated directly. Slightly terse for the ambiguity it leaves unresolved, but structurally clean.

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

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

For a paid tool with no output schema and a positional, undocumented params array, the description should explain the array's positional semantics and what the header response contains. Neither is present, leaving the agent likely to mis-order the arguments on a call that costs money.

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 50% and the uncovered half is the critical part: a positional 2-item array of [64-hex block hash, boolean] with no descriptions. The description only echoes the idempotencyKey retry rule already stated in the schema and never explains that the boolean is a verbose flag or what order the array items take.

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?

"Read getblockheader from Bitcoin" essentially restates the tool name; it never says that a block header is returned for a given block hash, nor distinguishes it from siblings like bitcoin_getblock (full block) or bitcoin_getbestblockhash. The chain identifier (bip122:0000...d668) is the only added specificity, which is metadata rather than purpose.

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?

There is no statement of when to choose this over bitcoin_getblock, bitcoin_getblockhash, or bitcoin_getbestblockhash, and no prerequisites beyond the cost note. The retry/idempotency sentence describes a mechanic, not usage selection, so an agent has no routing guidance.

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

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

With annotations present (openWorldHint, idempotentHint, readOnlyHint=false), the description still adds real value: it discloses the exact fee (0.005000 test USDC on eip155:84532) and instructs the agent to preserve idempotencyKey for retries, which is more concrete than the idempotentHint flag alone. The only friction is the "Read" wording against readOnlyHint=false, but that is explained by the paid-call side effect rather than being a true conflict.

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

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

Three short sentences, each carrying distinct information (method, chain, price, retry hygiene), with no filler. The long chain id is verbose but unavoidable for disambiguation.

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

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

For a paid tool with no output schema and a cryptographically patterned positional params array (txid, verbose=false, optional blockhash) that the schema doesn't describe, the description should have covered what params must contain and what is returned. It leaves the agent guessing about the core input and the raw-hex output.

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 only 50%, and the undocumented parameter (the 3-item positional params array) is not clarified at all in the description. The only parameter the description touches, idempotencyKey, is already fully documented in the schema, so the description adds essentially no parameter semantics of its own.

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?

"Read getrawtransaction from Bitcoin" does state a verb and a resource, and the chain identifier pins down which network it targets. However, the resource is literally the upstream RPC method name restated from the tool name, and it never explains that the result is a raw serialized transaction (nor how it differs from siblings like bitcoin_gettxout). Purpose is decipherable but not enriched.

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?

There is no statement of when to use this tool versus the many sibling transaction/block lookups, and no prerequisites beyond the retry note. The cost line implies a paid call but doesn't tell the agent under what circumstances to prefer this over other Bitcoin reads.

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 idempotentHint=true, openWorldHint=true, destructiveHint=false, and readOnlyHint=false, so the safety profile is mostly covered. The description adds the payment cost (0.005 test USDC) and the retry-key persistence requirement, which is valuable payment context. It does not explain payment failure/refund behavior or return format, and the word 'Read' could mislead relative to readOnlyHint=false, though the cost sentence clarifies the side effect.

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

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

Three short sentences, front-loaded with the action and chain, and no wasted words. The brevity is appropriate, though it ultimately leaves key semantics undocumented.

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

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

For a paid, open-world RPC tool with no output schema and a cryptic positional params array, the description is incomplete. It mentions payment and idempotency but omits what the method returns, what the positional parameters mean, and how payment or errors are handled.

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 idempotencyKey parameter is well described in the schema itself, but the positional params array has no schema descriptions for its three items. The tool description adds no information about those positional arguments, leaving the 50% schema-description coverage gap unaddressed.

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 the verb 'Read' and the resource 'gettxout' along with the Bitcoin chain ID, but 'gettxout' is unexplained RPC jargon and the description does not distinguish this method from sibling Bitcoin tools such as bitcoin_getrawtransaction or bitcoin_getblock. An agent can tell it is a Bitcoin read method but not what data it retrieves.

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

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

The only usage guidance is around preserving the idempotencyKey for retries, which is an operational note rather than a when-to-use instruction. It gives no indication of when to call gettxout versus other Bitcoin RPC methods, nor any prerequisites for the call.

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

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

Annotations already declare idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the bar is lower. The description still adds real value beyond them: the exact cost (0.002500 test USDC on eip155:84532) and the instruction to preserve the idempotencyKey for retries, which operationalizes the idempotency hint. Note readOnlyHint=false is not contradicted by 'Read' here, since spending USDC makes the call non-read-only in effect.

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

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

Three short sentences, zero waste, and the action is front-loaded before the cost and the retry caveat. Every sentence carries a distinct piece of information.

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

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

There is no output schema, so the description should carry the return semantics, but it never says what eth_blobBaseFee yields (a per-blob gas fee in wei) or units. Payment and idempotency are covered well, but the missing return-value and empty-params information leaves gaps for a paid read tool.

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

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

Schema description coverage is 50%: the idempotencyKey is fully documented in the schema, but the 'params' array (which must be empty, minItems/maxItems 0) is undocumented anywhere. The description reinforces key-retention behavior for retries, which is useful, but adds nothing about the empty params contract.

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

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

States a specific verb and resource ('Read eth_blobBaseFee') and pins the chain ('eip155:1'), which separates it from the many sibling eth_* methods and from the testnet payment chain. It does not, however, distinguish itself from conceptually adjacent fee readers like eth_gasPrice or eth_maxPriorityFeePerGas, and never says what a blob base fee actually represents.

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?

No when-to-use guidance: it never says when an agent should call this instead of eth_gasPrice, eth_feeHistory, or eth_maxPriorityFeePerGas, all of which are siblings. The cost sentence implies a paid operation but does not state prerequisites or conditions for choosing 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?

Annotations already declare idempotentHint, destructiveHint, openWorldHint and readOnlyHint=false, so the description adds real value by disclosing the economic cost (0.0025 test USDC on eip155:84532) and the retry/idempotencyKey protocol. It could have explained why readOnlyHint is false (the payment debit), but the cost mention implies it.

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

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

Three short, front-loaded sentences with no filler. What it does comes first, then cost, then the retry constraint — a sensible ordering.

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

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

Given no output schema, the description does not describe the return value (a hex-encoded block number quantity) that an agent needs to interpret. Purpose, cost, and key handling are covered, but the lack of return semantics leaves a noticeable gap for a read tool.

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

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

Schema coverage is 50%: idempotencyKey is fully documented in the schema (pattern plus description), and the description only reinforces that with 'Preserve the private idempotencyKey for retries.' The empty params array is undocumented, but it is a zero-item array so this is a minor gap.

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

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

States a specific verb and resource (read eth_blockNumber) plus the chain context (eip155:1), which is more than the tool name alone conveys. It does not differentiate from sibling RPC methods, though the naming convention makes the target obvious.

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?

No explicit when-to-use, when-not-to-use, or routing to alternatives among the many sibling eth_* methods. The cost and idempotency notes concern how to invoke it, not when to pick it over another call.

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

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

Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false, but the description adds genuinely non-derivable behavior: the call costs 0.010000 test USDC on eip155:84532, and the idempotencyKey must be preserved for retries. That payment/retry context is exactly the kind of detail annotations cannot express. Minor tension with readOnlyHint=false is resolved by the description itself disclosing the payment side effect.

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

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

Three short, front-loaded sentences with no filler: purpose, then cost, then the retry constraint. It is efficient, though arguably too terse relative to the complexity of the underlying params structure.

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

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

For a paid tool with a deeply nested call-object schema and no output schema, the description omits the block-tag argument, the shape of the call object, and what is returned (raw hex return data). An agent cannot call this correctly from the description alone.

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 50%, and the covered half is idempotencyKey — which the description merely restates ('Preserve the private idempotencyKey for retries'). The far more complex 'params' argument (call object plus optional block tag with blockNumber/blockHash variants) is documented in neither the schema nor the description, so the description does not compensate for the coverage gap.

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

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

The description states a verb ('Read') and a resource ('eth_call from Ethereum (eip155:1)'), but 'eth_call' is just the JSON-RPC method name repeated back, so an agent unfamiliar with EVM semantics learns nothing about what the tool actually does (simulate a contract call without committing a transaction). It also gives no differentiation from the many sibling ethereum_eth_* read methods such as eth_estimateGas or eth_getCode.

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?

There is no statement of when to use this tool versus alternatives like eth_estimateGas or eth_getCode, nor any preconditions for calling it. The only operational guidance given is about cost and retry behavior, which is not usage guidance in the selection sense.

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 idempotentHint=true and openWorldHint=true, but the description adds material facts the schema does not: the exact cost (0.002500 test USDC), the settlement network (eip155:84532), and the requirement to reuse the idempotency key only for retries. The paid, non-read-only nature of the call is disclosed even though readOnlyHint=false.

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

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

Three short sentences, front-loaded with the operation, then cost, then retry handling. Every sentence carries information; nothing is padded.

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

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

With no output schema, the description should carry the return shape but only says 'Read eth_chainId' without noting it returns a hex-encoded chain id. The payment and idempotency context is strong, but the result contract is left implicit for a two-required-param paid tool.

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

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

Schema coverage is 50%: idempotencyKey is well documented in the schema, while the empty params array is undocumented anywhere. The description reinforces the idempotencyKey retry semantics but does not clarify that params must be an empty array for this RPC.

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

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

States a specific verb and resource: 'Read eth_chainId from Ethereum (eip155:1)', with the chain namespace disambiguating it from the bitcoin_* siblings and the other ethereum_* RPC methods. It does not explicitly contrast itself against named alternatives, but the resource is precise enough to identify.

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

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

Usage is implied by the read framing, and the retry guidance ('Preserve the private idempotencyKey for retries') covers a real operational case. There is no when-to-use vs when-not statement and no pointer to sibling methods for related reads.

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 idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context by disclosing the paid cost (0.010000 test USDC on eip155:84532) and the retry/idempotency requirement, which annotations do not convey. However, the verb 'Read' sits in tension with readOnlyHint=false, and nothing is said about what the call returns or whether payment is charged on 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?

Three short sentences, front-loaded with the operation, then cost, then the retry constraint. No filler, though the sentences are terse to the point of omitting needed explanation.

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 tool whose params schema is large and nested, with no output schema, the description omits what an access list is, what the response contains, and how to populate the transaction params. Annotations cover the safety hints, but the remaining burden is largely unmet.

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 only 50%: the idempotencyKey is fully documented in the schema, but the dominant 'params' object (a large nested anyOf of transaction fields) has no description at all. The prose adds retry semantics for idempotencyKey but does nothing to explain the params structure, so it fails to compensate for the coverage gap.

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

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

The description names a specific RPC method and its chain ('Read eth_createAccessList from Ethereum (eip155:1)'), but 'Read eth_createAccessList' essentially restates the tool name without explaining what the tool produces (a simulated access list plus gas estimate). An agent that doesn't already know the JSON-RPC method learns nothing about the outcome from this text.

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 only guidance is 'Preserve the private idempotencyKey for retries,' which is a retry-handling rule, not a when-to-use rule. There is no indication of when to choose this over siblings like ethereum_eth_call or ethereum_eth_estimateGas, which perform closely related simulations.

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

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

Beyond the annotations, the description discloses concrete behavioral facts: a fixed cost of 0.010000 test USDC paid on a different chain (eip155:84532), and the requirement to persist and reuse the idempotency key only for identical retries, which reinforces idempotentHint=true. The 'Read' framing sits in mild tension with readOnlyHint=false, but the disclosed payment reconciles it (the underlying RPC is a read, yet the call spends funds), so it is not a contradiction.

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

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

Three short sentences, each carrying distinct information (purpose/chain, cost, retry key), with purpose front-loaded. No filler or redundancy; it could be a 5 only by also conveying the return semantics, which it omits.

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 tool whose input is a large nested object and which has no output schema, the description covers payment cost and idempotency handling but omits what the call returns (the gas estimate) and how the 'params' transaction object should be shaped. It is adequate for invoking the tool's payment flow but incomplete on the core payload and result.

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

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

Schema coverage is only 50%. The idempotencyKey parameter is fully documented in the schema and merely reinforced by the description. The far more complex 'params' argument (a deeply nested transaction-request object with from/to/gas/data/accessList/authorizationList/etc.) receives no explanation at all in the description, so the description does nothing to compensate for that gap.

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

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

States a clear verb and resource ('Read eth_estimateGas') plus the target chain (eip155:1), so an agent can identify the RPC method being wrapped. It does not, however, explain what estimateGas returns (a gas estimate) or distinguish itself from related siblings like eth_call or eth_gasPrice, so differentiation is left to the method 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?

The only usage guidance is 'Preserve the private idempotencyKey for retries,' which is about retry hygiene rather than when to choose this tool. There is no statement of when to use eth_estimateGas versus alternatives such as eth_call or eth_gasPrice, nor any prerequisite conditions.

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 openWorld=true and idempotent=true, but the description adds real operational context the annotations lack: an explicit monetary cost (0.005 test USDC on eip155:84532) and the retry discipline for the idempotencyKey. This meaningfully helps an agent understand the paid, retry-safe nature of the call. It stops short of describing return contents 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?

Three short front-loaded sentences with no filler; the resource and chain lead, followed by cost and retry guidance. Slightly terse given how much semantic payload is left out, but nothing is wasted.

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

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

It covers cost, network, and idempotency, which are the non-obvious parts. But with no output schema and an undescribed params argument, an agent still lacks the semantics of what it must pass and what feeHistory will return, leaving a moderate completeness gap.

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

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

Schema coverage is only 50%: idempotencyKey is well documented in the schema, and the description's 'preserve for retries' line merely restates that. Meanwhile the required params argument — which encodes block count, newest-block tag/hex, and reward percentiles — is undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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

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

States a concrete verb+resource ('Read eth_feeHistory') and pins the network (eip155:1), so the target chain is unambiguous. However, it only echoes the RPC method name and never explains what fee history returns, nor differentiates it from sibling gas-related methods like eth_gasPrice or eth_maxPriorityFeePerGas.

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?

There is no when-to-use guidance and no exclusion against the many similarly-scoped eth_* siblings. The only routing-ish content is the cost note, which does not help an agent decide between this and eth_gasPrice/eth_blobBaseFee.

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

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

Annotations declare idempotentHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is partly covered. The description adds genuinely new behavioral context: the exact cost (0.002500 test USDC on eip155:84532) and the retry contract for the idempotencyKey, which explains why readOnlyHint is false despite the 'Read' verb.

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

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

Three tight sentences, each doing distinct work: what to read, what it costs, and how to handle the key. The operation is front-loaded with no filler.

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

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

For a zero-argument paid RPC read with no output schema, the description covers the essentials an agent needs (network, cost, retry discipline). The only gap is that the return value (gas price in wei) is never hinted at, which is minor for a well-known RPC method.

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 50%; the idempotencyKey parameter is already fully described in the schema, and the description only restates the persist-for-retries guidance. The empty 'params' array carries no semantics in either place, so the description does not materially extend parameter understanding 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 ('Read eth_gasPrice from Ethereum (eip155:1)'), which is unambiguous and maps directly to the underlying RPC method. It is distinguishable from siblings like eth_maxPriorityFeePerGas and eth_blobBaseFee by name, though it does not explicitly contrast itself with them.

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

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

There is no guidance on when to use this tool versus alternatives such as ethereum_eth_maxPriorityFeePerGas or ethereum_eth_feeHistory, which are the natural competing choices for gas estimation. The cost statement implies a paid operation but does not tell the agent when that spend is warranted.

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

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

The annotations declare readOnlyHint=false on an obviously read-only RPC method, and the description supplies the missing explanation: the call costs 0.005000 test USDC on eip155:84532, which accounts for the non-readonly/payment behavior. It also adds the retry contract ('Preserve the private idempotencyKey for retries'), reinforcing the idempotentHint. It stops short of stating rate limits, failure/payment-refund behavior, or what a successful response contains.

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

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

Three short, front-loaded sentences with no filler: the operation, the cost, and the retry rule each carry distinct information. Nothing is repeated, though the sentences are telegraphic rather than explanatory.

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

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

There is no output schema, yet the description never states the return value (a hex-encoded wei balance) nor explains the nested 'params' shape, which is the only required data the caller must construct. For a paid, non-readonly-flagged call with a complex input schema, this leaves real gaps.

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

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

Schema description coverage is only 50%, and the undocumented half is the hard part: 'params' is a deeply nested anyOf of address + block tag/blockNumber/blockHash with no description in either the schema or the description. The description only echoes the already-documented idempotencyKey ('preserve for retries'), so it does not compensate for the coverage gap on the primary 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?

It names a specific verb ('Read') and the exact RPC method and chain ('eth_getBalance from Ethereum (eip155:1)'), but the method name is essentially a restatement of the tool name, and it never says what the call actually returns (an account's wei balance). An agent that doesn't already know the Ethereum JSON-RPC spec gets no semantic explanation, and there is no differentiation from the ~40 sibling eth_* read methods beyond the method identifier itself.

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

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

There is no when-to-use guidance and no mention of alternatives (e.g. eth_getCode, eth_getTransactionCount, or the bitcoin_* siblings). The only contextual line is the price, which tells the agent nothing about when this tool is the right choice over a sibling.

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

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

Annotations cover the safety profile (destructiveHint=false, idempotentHint=true), and the description adds genuinely useful context not in the structured data: the chain (eip155:1), the exact per-call cost (0.005000 test USDC on eip155:84532), and the retry/idempotency-key handling. This explains why readOnlyHint is false despite the 'Read' verb, resolving an apparent tension rather than contradicting 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?

Three short, front-loaded sentences with no filler. The core identity comes first, then cost, then retry handling, which is a sensible ordering for an agent to scan.

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?

Payment, chain, and idempotency handling are covered, and no output schema means return values need not be explained. But the positional params (hash and boolean) are left opaque and no sibling routing to getBlockByNumber is provided, leaving a real gap for an eth_getBlockByHash call.

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

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

Schema coverage is 50%; the idempotencyKey has a full schema description and the description reinforces its retry/persistence semantics. However, the required params array (a block hash plus a boolean, presumably full-transactions) is completely undocumented in both schema and description, so an agent gets no help on the two positional arguments it must supply.

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?

"Read eth_getBlockByHash" essentially restates the tool name rather than explaining what the operation does or returns. It never states that it fetches block data keyed by a block hash, nor distinguishes itself from the sibling ethereum_eth_getBlockByNumber, which is the immediately competing choice.

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 only actionable guidance is 'Preserve the private idempotencyKey for retries,' which is a narrow retry instruction. There is no indication of when to use this tool versus getBlockByNumber or any other block-reading sibling, and no prerequisites beyond the cost note.

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

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

Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false. The description adds genuinely useful, non-obvious context: the 0.005000 test USDC cost and the distinct payment chain (eip155:84532), which explains the readOnlyHint=false side effect. However, the idempotencyKey note largely duplicates the schema field description and no failure/rate-limit behavior is 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?

Three short sentences with the purpose front-loaded, then cost, then the retry note. Nothing is padded and every sentence is load-bearing, though the idempotency clause is somewhat redundant with the schema.

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

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

For a two-param read tool with no output schema and no param docs, the description should at least sketch the block/tag argument and the returned block. It covers purpose, cost, and idempotency adequately but leaves the parameter semantics and return shape to inference.

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 50%: idempotencyKey is documented in the schema, but the two-element params array (block number/tag and full-transaction boolean) is undocumented anywhere. The description adds no meaning to those parameters, so it fails to compensate for the gap.

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

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

States a specific verb (Read) and resource (eth_getBlockByNumber) plus the chain (eip155:1), so an agent knows it fetches a block by its number/tag. The method name itself implicitly distinguishes it from the by-hash sibling, though the description never spells that out.

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?

Only 'Preserve the private idempotencyKey for retries' gives any usage direction, and that is about retries rather than tool selection. There is no guidance on when to use this versus eth_getBlockByHash or the other block-number siblings.

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

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

The description adds genuinely non-schema context: the cost (0.010000 test USDC on eip155:84532) and the retry/idempotency contract. However it calls the operation a 'Read' while annotations set readOnlyHint=false, leaving the payment-as-write side effect unclarified, so the behavioral picture is incomplete.

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

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

Three short, front-loaded sentences with no filler; the operation name, cost, and retry rule each earn their place.

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

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

For a paid read RPC with no output schema, the definition covers cost and idempotency but omits any hint of the returned receipt structure and does not resolve the readOnlyHint=false tension. Adequate but leaves gaps an agent would want closed.

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 50% schema description coverage, the schema already fully specifies idempotencyKey's format and purpose and constrains params via a rich anyOf. The description reinforces the idempotency/retry semantics but adds nothing about the params shape (block number vs hash vs tag).

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

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

States a specific verb and resource ('Read eth_getBlockReceipts from Ethereum'), which an agent can clearly distinguish from sibling block/transaction lookup tools. It does not explain what a 'block receipt' comprises or how this differs semantically from eth_getBlockByHash, but the operation 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?

There is no when-to-use guidance and no routing to alternatives (e.g., eth_getBlockByHash for block data vs this for receipts). The only usage-adjacent advice is 'Preserve the private idempotencyKey for retries', which covers retry handling but not tool selection.

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

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

Annotations declare idempotentHint=true and readOnlyHint=false, but the description's payment/idempotencyKey note is the only behavioral context and it does not explain read semantics, error behavior, or why a read is flagged non-readOnly. The readOnlyHint=false against a pure read of a block-hash lookup reads as a contradiction worth noting.

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

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

Three short sentences, front-loaded with the method and network. No wasted words, though the payment detail could be trimmed or moved after the purpose.

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

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

For an RPC passthrough with no output schema, the description should indicate the return value (a transaction count) and the block-hash-vs-number choice. Both are missing, as is any note on the unusual readOnlyHint=false on a read operation.

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 50% and the sole param is a 32-byte block hash array. The description adds nothing about the hash format, so the schema is doing the heavy lifting; 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 names the method eth_getBlockTransactionCountByHash and the network, but only restates the tool name without explaining what the method returns or how it differs from its sibling eth_getBlockTransactionCountByNumber. An agent unfamiliar with the RPC would learn nothing about purpose.

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?

There is no guidance on when to use this versus the ByNumber sibling or other block methods. The only quasi-usage content is a payment cost note, not 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?

Annotations cover safety traits (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), but the description adds genuinely useful context not present in them: the exact cost (0.002500 test USDC), the payment chain (eip155:84532), and the requirement to persist the idempotency key before payment and reuse it only for retries. This pricing/payment behavior is valuable operational 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?

Three short clauses, front-loaded with the operation, then cost, then the idempotency instruction. Efficient and easy to parse, though the opening clause largely duplicates the tool name rather than adding substance.

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 low-complexity 2-parameter proxy call with no output schema, the description covers the operational essentials (chain, cost, idempotency handling). However, it omits what the call returns (a hex quantity for the transaction count) and clarification of the block parameter, leaving a modest 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 50%: the idempotencyKey is documented in the schema, but the core 'params' block-number/tag argument has no description. The description only reinforces the idempotency key rule and says nothing about the block-number-or-tag semantics, which is the parameter an agent most needs to understand.

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 says 'Read eth_getBlockTransactionCountByNumber from Ethereum (eip155:1),' which essentially restates the tool name rather than explaining what the method returns (the count of transactions in a block for a given block number/tag). It does not distinguish this from the sibling ethereum_eth_getBlockTransactionCountByHash, so an agent gets little beyond the method identifier it already sees in 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?

There is no statement of when to use this tool versus the ByHash sibling or other block-inspection tools. The only procedural note is 'Preserve the private idempotencyKey for retries,' which addresses retry behavior but not tool selection or prerequisites.

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

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

Beyond the annotations (openWorld, idempotent, non-destructive) the description adds valuable behavioral context: a concrete cost of 0.005000 test USDC paid on a separate chain (eip155:84532) and a retry instruction. This cost disclosure also usefully explains why readOnlyHint is false despite the word 'Read'.

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

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

Three short sentences, front-loaded with the purpose and no filler. Every sentence carries concrete information (chain, cost, retry key), making it tight and scannable.

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 50% parameter coverage, the description should explain return values (contract bytecode) and the params shape, but it does neither. For a 2-required-param tool it leaves key invocation and interpretation details unstated.

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

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

Schema description coverage is only 50%: idempotencyKey is documented in the schema, but the params array (address plus block tag/number/hash) is undocumented there. The description only echoes idempotencyKey retry advice and adds nothing about the actual eth_getCode parameters, so it fails to compensate for the coverage gap.

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

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

The description says 'Read eth_getCode from Ethereum (eip155:1)', giving a verb+resource and pinning the network, but 'eth_getCode' merely restates the tool name. It never explains what the method actually does (retrieve contract bytecode at an address), so it only helps agents already fluent in EVM RPC semantics.

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?

There is no when-to-use/when-not guidance and no routing advice. The description names the network and cost but never distinguishes this tool from the many sibling methods like eth_getBalance or eth_getStorageAt, leaving the agent to infer usage context entirely.

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

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

Annotations cover safety (destructiveHint=false, idempotentHint=true) but the description adds genuinely useful context beyond them: the exact payment cost (0.010000 test USDC on eip155:84532) and the instruction to preserve the private idempotencyKey for retries. This is meaningful for a paid, non-free method and explains why readOnlyHint is false. It does not describe return shape or rate limits.

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

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

Three short, front-loaded sentences with no filler; the operation is stated first, then cost, then the key-handling caveat. Efficient, though the first sentence is near-tautological.

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

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

For a paid tool with no output schema, the description does cover payment cost and idempotency handling, which are the key operational facts. It falls short on the filter parameters (the substance of eth_getLogs) and gives no sense of the log records returned, so it is adequate but not complete.

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

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

Schema coverage is 50%, and the idempotencyKey already carries a detailed schema description. The description adds retry semantics ('reuse only for retries') which is useful, but the entire params object (topics, address, fromBlock/toBlock, blockHash) is undocumented in both the description and schema, leaving the core query parameters opaque.

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 verb ('Read') and resource ('eth_getLogs from Ethereum') plus the chain id, so an agent knows it fetches event logs. However, 'Read eth_getLogs' largely restates the tool name, and it offers no differentiation from the ~20 sibling eth_* read methods (e.g. eth_getBlockReceipts). The eip155:1 qualifier is the only added specificity.

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?

There is no guidance on when to use getLogs versus alternatives like eth_getBlockReceipts or eth_getTransactionReceipt. The only conditional instruction is about retries with idempotencyKey, which is operational rather than usage-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 openWorldHint, idempotentHint, destructiveHint and readOnlyHint=false, so the safety profile is largely covered. The description adds real value beyond that: the exact cost (0.010000 test USDC on eip155:84532) and the retry/idempotencyKey preservation rule, which an agent cannot derive from structured fields. It does not reconcile the 'Read' framing with readOnlyHint=false (the per-call payment is the likely reason) or explain failure/refund behavior, but the added context 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?

Three short, front-loaded sentences: purpose first, then cost, then retry instruction. Every sentence carries distinct information (what, price/chain, idempotency handling) with no filler or repetition.

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

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

For a paid proxy exposing a structurally complex RPC (nested anyOf for address, storage keys, and block identifier), the description leaves the parameter contract entirely unexplained and says nothing about the returned proof object. No output schema exists to offload that burden, so an agent must already know the eth_getProof signature to call this correctly.

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

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

Schema description coverage is 50%: idempotencyKey is fully documented in the schema, while the 'params' anyOf array (address + storage-key list + optional block tag/object) has no description anywhere. The description adds nothing about params — the only parameter mention ('Preserve the private idempotencyKey') restates the schema text rather than compensating for the undocumented half.

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') and the exact underlying RPC method plus chain ('eth_getProof from Ethereum (eip155:1)'), so the agent knows precisely what is being called. However, it offers no differentiation from the ~40 sibling ethereum_eth_* methods and never explains what an eth_getProof (account/storage Merkle proof) actually yields, so an agent unfamiliar with the RPC must infer the purpose from the name alone.

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

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

There is no when-to-use guidance and no comparison to alternatives such as ethereum_eth_getBalance, eth_getCode, or eth_getStorageAt, which overlap in the account-state space. The only directive ('Preserve the private idempotencyKey for retries') concerns retry mechanics, not tool selection.

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

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

Annotations already declare idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuine value by disclosing that the call costs 0.005 USDC on eip155:84532 and that the idempotencyKey must be persisted for retries — behavior not in the annotations. It does not explain whether retries incur charges again, leaving a gap.

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

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

Three short, front-loaded sentences with no wasted words: purpose first, then cost, then the retry constraint. Efficient, though the brevity comes at the cost of substance rather than being purely economical.

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

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

For a paid read RPC with two params and no output schema, the description covers method, chain, cost, and idempotency, which is a reasonable minimum. It omits what the call returns and how it relates to sibling tools, so it is adequate but not 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 50%; the two ordered params (block hash, index) have no descriptions, and the description never explains them — only the method name hints at their meaning. The idempotencyKey note merely repeats the schema's own detailed description. The description fails to compensate for the undocumented params.

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 largely restates the tool name ('Read eth_getRawTransactionByBlockHashAndIndex'), elaborating only with the chain id (eip155:1). It does not explain what the method actually returns (RLP-encoded raw transaction) nor differentiate it from near-identical siblings like getRawTransactionByHash or getRawTransactionByBlockNumberAndIndex. This is effectively a tautology.

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?

No guidance on when to use this tool versus the many alternative transaction-fetching siblings (by hash, by block number, non-raw variants). The cost and idempotency notes are operational, not selection criteria. An agent gets no help choosing between this and adjacent methods.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and the description usefully adds that the call costs 0.005000 test USDC on a specific chain (eip155:84532) and that the idempotencyKey must be preserved for retries. That payment-chain and retry-persistence context is genuinely beyond what the annotations provide. It does not say what happens if the payment succeeds but the RPC fails, which would round this out.

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

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

Three short sentences with no filler, and the cost/idempotency warnings are front-loaded after the opening line. However, the opening sentence is a pure restatement of the name and earns little space relative to the two substantive sentences that follow.

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

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

With no output schema, the description correctly does not need to explain return values, and it covers the payment and idempotency mechanics. But for a paid, non-read-only call among many near-identical siblings, it omits the usage distinction and any parameter meaning, leaving gaps an agent would have to resolve elsewhere.

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 50%: the idempotencyKey is well documented in the schema, but the params array carries no description (it relies on pattern/enum constraints to convey block-number-or-tag semantics). The description adds no parameter meaning at all, so it neither compensates for the gap nor improves on the structured data. 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's first sentence largely restates the method name ('Read eth_getRawTransactionByBlockNumberAndIndex from Ethereum'), which is tautological rather than a plain-language statement of what the tool does. It does add the chain identifier (eip155:1), but it never distinguishes this tool from close siblings like ethereum_eth_getRawTransactionByBlockHashAndIndex or ethereum_eth_getRawTransactionByHash.

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?

There is no guidance on when to use this method versus the block-hash or by-hash variants of the same lookup. The only contextual statement is about payment, not about selection. An agent must infer the choice entirely from the method 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 already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely new behavioral context beyond that: the per-call cost (0.005 USDC on eip155:84532), which reconciles the non-read-only flag, and the requirement to persist the private idempotencyKey for retries. It does not, however, describe the return payload or latency/rate behavior.

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

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

Three short sentences, front-loaded with purpose and then cost and retry mechanics; nothing is bloated. The idempotency sentence is somewhat redundant with the schema description, which keeps it from a 5.

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

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

With no output schema and two parameters, the description should say more about what comes back (the raw RLP-encoded transaction hex) and what params represents. It covers purpose, cost, and idempotency adequately for invocation, but leaves the return value and the hash parameter 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 coverage is 50%: the idempotencyKey field is already fully documented in the schema, and the description's retry note only reinforces it. The params array (a single 0x-prefixed 64-hex transaction hash) is documented in neither the schema nor the description, so the description does not compensate for that gap.

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

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

The description states a verb ('Read') and the resource (eth_getRawTransactionByHash) plus the chain (eip155:1), so the operation is identifiable. However, it largely restates the self-descriptive method name and offers no differentiation from close siblings such as ethereum_eth_getRawTransactionByBlockHashAndIndex or ethereum_eth_getTransactionByHash.

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?

There is no guidance on when to use this tool versus the many sibling getters (e.g., getTransactionByHash returns the decoded transaction, this returns the raw encoded one). The only operational note is preserving the idempotencyKey, which is retry mechanics rather than tool-selection guidance.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the bar is lower. The description nonetheless adds two pieces of genuinely useful context the annotations do not carry: the exact price (0.005000 test USDC on eip155:84532) and the requirement to retain the private idempotencyKey for retries, which reconciles the non-read-only hint with a paid call. It still omits what a successful response contains, but the pricing/payment 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?

Three short, front-loaded sentences with no filler: purpose first, then cost, then key handling. It is appropriately sized, though the opening sentence is so terse that the brevity costs it some explanatory value rather than being pure efficiency.

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 burden of telling the agent what comes back, and it never does (a 32-byte storage word). It also leaves the two-element/three-element 'params' tuple, with its nested block-tag and block-identifier unions, entirely unexplained. Payment and idempotency are covered, but the core call semantics are not.

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 only 50%: idempotencyKey is documented in the schema, while the 'params' tuple (address, slot, block tag/object) has no description anywhere. The description only echoes the idempotencyKey advice already present in the schema and does nothing to explain the nested anyOf structure of 'params', so it fails to compensate for the coverage gap.

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

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

The description states a verb ('Read') and a resource ('eth_getStorageAt') and pins the chain (eip155:1), but the resource is simply the JSON-RPC method name restated, so it borders on tautology. It does not explain what is being read (a contract's storage slot at an address) nor differentiate from near-identical siblings like eth_getBalance, eth_getCode, or eth_getProof.

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?

There is no when-to-use guidance and no comparison against the many sibling read methods on the same chain. The only procedural instruction is about retrying with the same idempotencyKey, which is retry hygiene rather than tool selection guidance.

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

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

Annotations already declare idempotentHint=true, openWorldHint=true and destructiveHint=false, but the description adds genuinely new context: the exact cost (0.005 test USDC on eip155:84532) and the instruction to persist and reuse the idempotencyKey on retries. These operational facts are not derivable from annotations or schema. The 'Read' wording sits slightly in tension with readOnlyHint=false, though the disclosed payment explains the non-read-only characterization.

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

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

Three tight sentences, front-loaded with the operation and then the cost and retry constraint. No filler, and each sentence carries distinct information, though the opening sentence is essentially the tool name restated.

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?

The description covers the operational essentials (purpose, cost, idempotency handling) but omits the argument ordering for the undocumented params array and, with no output schema present, gives no signal about the returned transaction shape. Adequate for invoking the call but not fully complete for a schema-light RPC 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?

Coverage is 50%: the idempotencyKey parameter is fully documented in the schema, while the required two-element params array (block hash + transaction index) has no description in either place. The description merely restates the idempotency behavior already in the schema and adds no new meaning for the RPC arguments, so this lands at the baseline for partial coverage.

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

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

States a clear verb (Read) plus the exact resource (eth_getTransactionByBlockHashAndIndex) and the chain (eip155:1), so an agent knows it retrieves a transaction identified by block hash and index. However, it offers no differentiation from near-identical siblings such as eth_getRawTransactionByBlockHashAndIndex or eth_getTransactionByBlockNumberAndIndex, and the phrasing largely mirrors the tool 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?

There is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives (e.g., getTransactionByHash, getTransactionByBlockNumberAndIndex). The only invocation-adjacent hint is 'Preserve the private idempotencyKey for retries,' which does not address tool selection.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true), so the bar is lower. The description nonetheless adds genuinely useful context the annotations don't carry: the exact cost (0.005 test USDC on eip155:84532) and the retry/idempotency contract. This explains why readOnlyHint is false despite the 'Read' framing. It stops short of describing failure or refund behavior on a failed call.

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

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

Three short, front-loaded sentences with no filler; purpose, cost, and retry semantics each earn their place. The opening clause is largely redundant with the tool name, which keeps it from a 5.

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

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

With no output schema, the description should carry more of the return-value burden, yet it never states what a transaction object contains or how 'not found' is signaled. It does cover the payment and idempotency dimensions well, so it is adequate but incomplete for an agent invoking a paid RPC method blind.

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 50%: the idempotencyKey is well documented in the schema, but the required two-element 'params' array (block number-or-tag plus transaction index) has no description in either the schema or the description. The one line about idempotencyKey only echoes what the schema already says, so the description fails to compensate for the undocumented params array.

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 restates the RPC method name verbatim ('Read eth_getTransactionByBlockNumberAndIndex from Ethereum') and adds only the chain id. An agent familiar with Ethereum can infer the verb+resource from the method name, but the prose itself adds no plain-language explanation and does not distinguish it from close siblings like eth_getTransactionByBlockHashAndIndex or eth_getRawTransactionByBlockNumberAndIndex.

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?

There is no guidance on when to use this method versus the ByHash, ByIndex, or Raw variants. The only usage-adjacent statement is 'Preserve the private idempotencyKey for retries', which addresses retry handling, not tool selection.

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

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

The description discloses behavioral facts the annotations do not: an explicit per-call cost (0.005 test USDC on eip155:84532) and the requirement to persist the idempotencyKey across retries. readOnlyHint=false is consistent with a paid call that effects a payment, so 'Read' plus the cost disclosure is coherent rather than contradictory. It stops short of describing the returned payload or failure/timeout 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?

Two short sentences, front-loaded with the operation and chain, followed by cost and retry guidance. Nothing is padded, though the phrasing is telegraphic rather than fully explanatory.

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 omits any hint of the returned transaction object, and it never explains what the single params entry should be. Payment, chain, and idempotency are covered, but for a hash-lookup call the input/return semantics are left to a reader already fluent in the raw eth_getTransactionByHash RPC.

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 50%: idempotencyKey is fully documented in the schema, but the params array (a single 32-byte hex transaction hash) has no description anywhere. The description reinforces the idempotencyKey advice but adds nothing about the hash parameter, so it only marginally compensates for the coverage gap.

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

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

The description states a read operation against Ethereum mainnet (eip155:1), which adds chain scoping and safety intent beyond the tool name. However, 'Read eth_getTransactionByHash' largely restates the RPC method already embedded in the name, and it does not differentiate from close siblings like ethereum_eth_getRawTransactionByHash or the ByBlockHashAndIndex variants. Purpose is inferable but not sharpened.

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?

There is no guidance on when to choose this tool over the many sibling lookups (raw vs. non-raw, by hash vs. by block+index). The only directive — 'Preserve the private idempotencyKey for retries' — is retry hygiene, not selection guidance.

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

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

Annotations cover the safety profile (idempotentHint, openWorldHint, destructiveHint=false), and the description adds behavior not in them: a fixed cost of 0.005 test USDC on a specific chain and the retry/persistence discipline for the idempotencyKey. This meaningfully helps an agent understand the paid, retry-safe nature of the call.

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

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

Three short sentences, front-loaded with the operation, then cost, then retry discipline. Every sentence carries distinct information and there is no filler.

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

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

There is no output schema, and the description never says what the method returns (an account nonce) or the format/shape of the 'params' input. For a tool whose only non-schema-documented parameter is the RPC params array, this leaves meaningful gaps.

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

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

With only 50% schema description coverage, the description must compensate, but it adds nothing about the 'params' array (address plus block tag/hash) beyond what is implied. Its idempotencyKey sentence largely repeats the schema's own description of that field, so net new parameter meaning is minimal.

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 verb ('Read') plus the exact RPC resource ('eth_getTransactionCount') and the chain (eip155:1), which is more than a bare name. However, the resource is essentially the tool name restated, and it does nothing to distinguish this from the dozens of sibling ethereum_eth_* read methods. Clear but not sibling-differentiating.

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 tells the agent the call costs test USDC and to keep the idempotencyKey for retries, which is useful operational framing. But it gives no guidance on when to use this method versus siblings like eth_getBalance or eth_getTransactionByHash, and no prerequisites beyond the price.

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

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

With readOnlyHint=false already declared, the description adds real context the annotations don't carry: the price (0.005 test USDC), the payment chain (eip155:84532), and the retry discipline for idempotencyKey. It still doesn't explain that the call is paid and why readOnlyHint is false despite 'Read', leaving a mild tension, but the cost/payment disclosure is genuinely useful.

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

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

Three short sentences, front-loaded with the operation, then cost, then retry rule. No filler, though the retry sentence duplicates what the schema already states about idempotencyKey.

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

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

There is no output schema and the description says nothing about what the tool returns (status, logs, gas used) or the exact shape of the required hash argument. For a paid, open-world read call it covers payment and retries but leaves the call semantics thin.

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 50%: idempotencyKey is fully documented in the schema and merely echoed here ('preserve ... for retries'), while the params array — the 32-byte transaction hash — is undocumented in both places, so the description does not compensate for the schema gap.

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

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

It names a verb ('Read') and a resource (eth_getTransactionReceipt on eip155:1), so the target is unambiguous, but it does nothing beyond restating the JSON-RPC method name — it never says what a receipt is or how it differs from siblings like ethereum_eth_getTransactionByHash, which an agent must pick between.

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?

There is no when-to-use guidance at all. The description gives no condition telling the agent to prefer eth_getTransactionReceipt over eth_getTransactionByHash or eth_getBlockReceipts, and no prerequisites beyond the implicit idempotency-key note.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true, destructiveHint=false), and the description adds genuinely new behavioral context: the call costs 0.005000 test USDC on eip155:84532 and the idempotencyKey must be preserved for retries. However, the 'Read' framing sits in mild tension with readOnlyHint=false, and the description says nothing about return semantics or rate limits.

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

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

Three short, front-loaded sentences that move from purpose to cost to retry handling with no padding. The final sentence largely duplicates what the schema already says about idempotencyKey, which is the only mild waste.

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

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

For a low-complexity paid RPC proxy with no output schema, the description covers the tricky bits (payment amount, chain, idempotency handling) but omits what the call returns and what the two required positional parameters mean. It is adequate but leaves real gaps.

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

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

Schema description coverage is only 50%: idempotencyKey is documented in the schema while the positional params array (block hash + uncle index) is not. The description repeats the idempotencyKey guidance already in the schema and adds nothing about the two positional parameters, so it fails to compensate for the coverage gap.

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

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

The description states a verb ('Read') and a concrete resource (eth_getUncleByBlockHashAndIndex on eip155:1), so an agent can distinguish it from sibling RPCs by name. However, it essentially restates the method name without explaining what the call actually does (return the uncle block at a given index for a block identified by hash), so the purpose is only weakly conveyed.

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?

There is no guidance on when to use this tool versus close siblings such as eth_getUncleByBlockNumberAndIndex, eth_getUncleCountByBlockHash, or eth_getUncleCountByBlockNumber. The only context given (cost, idempotency) concerns invocation mechanics, not tool selection.

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

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

Annotations cover the safety profile (openWorld, idempotent, destructive=false), and the description adds meaningful operational context they don't carry: a concrete price (0.005000 test USDC), the settlement chain (eip155:84532), and a privacy/idempotency-warning to persist the key. The one tension is that it leads with 'Read' while readOnlyHint=false, but that is defensible because the op spends funds, which the description does disclose.

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

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

Three short sentences, front-loaded with the operation and followed by cost and retry guidance. Nothing is padded, though the opening line is close to a name restatement and earns little.

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?

Payment amount and idempotency handling are well covered, but there is no output schema and the description never explains the params array or the shape of an uncle result. For a two-required-param tool, the param/return story is left incomplete.

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 50%. The description reinforces the idempotencyKey semantics (persist, private, retries only), which the schema partly covers, but the required two-element params array (block number/tag + uncle index) is documented nowhere, so an agent must infer it from the method name.

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 verb ('Read') and effectively restates the method name, plus the chain id (eip155:1). It does not explain what an uncle block is or distinguish the tool from getUncleByBlockHashAndIndex or getUncleCountByBlockNumber, so an agent that doesn't already know the JSON-RPC method gets little beyond 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?

The only usage guidance is 'Preserve the private idempotencyKey for retries,' which is a retry instruction, not a when-to-use rule. There is no indication of when to prefer the by-number variant over the by-hash sibling or the count methods.

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 idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds genuinely new behavioral context: the call costs 0.002500 test USDC on eip155:84532, which explains the readOnlyHint=false annotation (payment is a side effect) and warns the agent a payment is required. This is useful information not available in the structured fields.

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

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

Three short, front-loaded sentences: action first, then cost, then key-retention advice. No filler, though the third sentence largely duplicates the schema's idempotencyKey description.

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

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

For a standard read RPC method with no output schema, the description covers payment and key handling but omits what the call returns (an uncle count) and how it differs from the by-number sibling. It is adequate but leaves the agent to infer return semantics and method selection.

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 50%: the idempotencyKey is fully documented in the schema, while the block-hash 'params' array has no description. The description only echoes the idempotencyKey guidance and adds nothing about the block-hash parameter, so it does not compensate for the undocumented half. Baseline 3 given partial coverage.

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

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

The description states the verb and resource but essentially restates the tool name ('Read eth_getUncleCountByBlockHash'), adding only the chain identifier (eip155:1). It does not distinguish this from the obvious sibling ethereum_eth_getUncleCountByBlockNumber, so an agent must infer the by-hash vs by-number distinction from the name alone.

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

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

There is no guidance on when to use this tool versus alternatives such as ethereum_eth_getUncleCountByBlockNumber or ethereum_eth_getUncleByBlockHashAndIndex. No prerequisites or context for selection are given beyond the implicit by-hash input.

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

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

Annotations already declare openWorldHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: the per-call price (0.002500 test USDC) and that the idempotencyKey is a private value that must be persisted before payment and reused only for identical retries. It stops short of explaining what happens if payment fails or how the call settles.

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

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

Three short sentences, front-loaded with the purpose and followed by cost and retry guidance, with no filler. It is efficiently sized for a simple RPC wrapper, though the first sentence carries no real information.

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

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

For a paid, two-parameter RPC tool with no output schema, the description covers chain, cost and idempotency adequately but omits the block-reference semantics and gives no hint of the return value (a hex uncle count). Nothing an agent needs is dangerously missing, but the core method behavior 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 coverage is only 50%; the sole element of the params array (a block number hex or latest/safe/finalized/earliest/pending tag) is undocumented in both the schema and the description, even though it is the tool's core input. The description only repeats the idempotencyKey semantics that the schema already spells out in full.

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 restates the tool name almost verbatim ('Read eth_getUncleCountByBlockNumber from Ethereum'), which is tautological rather than explanatory. It never says what the method returns (the number of uncles in a referenced block) nor how it differs from the many uncle-related siblings like getUncleCountByBlockHash or getUncleByBlockNumberAndIndex.

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?

There is no guidance on when to call this versus the ByBlockHash variant or any other sibling, and no prerequisites beyond the retry note. The only conditional hint ('Preserve the private idempotencyKey for retries') concerns retry mechanics, not tool selection.

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

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

Annotations only give readOnlyHint=false / openWorldHint=true / idempotentHint=true, which on their own look puzzling for a read method. The description resolves that by disclosing the paid nature (0.002500 test USDC on eip155:84532) and the idempotency-key retention rule for retries — real context the annotations cannot convey. It stops short of stating failure/refund behavior.

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

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

Three short sentences, zero padding, and the highest-value facts (what is read, where, at what cost, retry key handling) are front-loaded. Nothing could be removed without losing information.

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

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

For a zero-argument paid read with no output schema, the definition covers chain, price, and idempotency behavior adequately. It omits what the call returns (a wei-denominated priority fee) and what happens if payment fails or the key is reused incorrectly, which would round out an agent's expectations.

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 only substantive parameter, idempotencyKey, is already fully documented in the schema (private 32-byte hex, persist before payment, reuse only for retries). The description reinforces that with 'Preserve the private idempotencyKey for retries,' and 'params' is an empty array carrying no semantics to explain, so there is little left to add.

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

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

The description names the exact RPC method (eth_maxPriorityFeePerGas) and pins it to a specific chain (eip155:1), so the resource and scope are unambiguous. It does not, however, contrast itself with the many sibling eth_* read methods (gasPrice, feeHistory, blobBaseFee) that an agent must choose between.

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?

There is no when-to-use guidance: nothing says to prefer this over eth_gasPrice or eth_feeHistory, nor what precondition (e.g. needing an EIP-1559 tip estimate) selects it. The only operational hint is 'Preserve the private idempotencyKey for retries,' which is retry mechanics rather than tool selection.

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

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

The description adds genuinely useful behavior beyond annotations: it discloses the paid cost (0.0025 test USDC on eip155:84532) and the idempotency-key retry contract, which explains why readOnlyHint is false for a read method. However, it does not explain the payment flow, whether the key is consumed per call, or what happens on a failed 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?

Three short sentences, front-loaded with the method and chain, then cost, then the retry constraint. No filler, though the cost/idempotency sentences are terse enough to leave questions open.

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

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

With no output schema, the description should hint at what eth_syncing returns (false when synced, or a sync-status object), but it says nothing about the return value. Cost and idempotency are covered, but the agent lacks the semantic meaning of 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?

The idempotencyKey is fully documented in the schema (pattern, persistence rules, secrecy), and the description reinforces the 'preserve for retries' behavior. The params array is fixed at zero items and the description never mentions that this method takes no parameters, so 50% coverage is not fully compensated.

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 eth_syncing from Ethereum') and pins the chain via eip155:1, so the agent knows exactly which RPC method is invoked. It does not, however, differentiate this from the many sibling read methods (eth_blockNumber, eth_chainId, etc.) beyond the method name itself.

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

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

There is no guidance on when to call this versus alternatives such as eth_blockNumber or net_peerCount, nor any precondition noted beyond the payment. The agent must infer usage from the method name alone.

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

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

The description adds real value beyond the annotations: the price (0.002500 test USDC on eip155:84532) and the instruction to preserve the idempotencyKey for retries, which complements idempotentHint=true and explains why readOnlyHint=false despite a read-style RPC. It still omits the return value/shape (no output schema exists), which matters for a tool whose whole output is a single boolean.

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

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

Three short sentences, each carrying distinct information (what, cost, key handling), with purpose front-loaded and zero filler.

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

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

For a zero-parameter read with no output schema, the description covers payment and key handling but never states what is returned (a listening boolean) or what the flag means operationally, leaving the agent unable to interpret the response without outside knowledge.

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 only meaningful parameter, idempotencyKey, is already fully documented in the schema, and the description reinforces its retry-only reuse semantics. The other parameter is a maxItems:0 array that needs no explanation, so the 50% coverage is not a real gap.

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

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

States a specific verb and resource ('Read net_listening from Ethereum (eip155:1)') and disambiguates from the many sibling RPC methods by naming the exact method and chain. However, it never explains what net_listening actually reports (client listening-for-connections boolean), so an agent without prior Ethereum RPC knowledge understands the target but not the payload.

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?

There is no guidance on when to call this versus close siblings like ethereum_net_peerCount or ethereum_net_version, nor any preconditions beyond the payment note. The cost sentence gives context but not usage direction.

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 openWorld, idempotent, non-read-only behavior, and the description adds real value beyond them by disclosing the payment requirement (0.0025 test USDC on eip155:84532) and the retry-key handling rule. This is meaningful operational context an agent needs before calling, though it stops short of describing the result of the call.

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

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

Three short sentences, each earning its place: the operation first, then the cost with its settlement chain, then the retry instruction. Zero filler and correctly 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 zero-argument RPC read with no output schema, the description covers chain, cost, and idempotency, but never explains what the call returns (the count of connected peers). With no output schema present, that return-value context would have been the description's job, leaving a real 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?

The 'params' array is fixed to zero items and needs no documentation, and the only meaningful parameter (idempotencyKey) is fully described in the schema, including its format and never-publish warning. The description's retry instruction largely restates the schema rather than adding new semantics, so this 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 clear verb (read) plus a specific resource (net_peerCount) scoped to Ethereum mainnet (eip155:1), so an agent immediately knows what operation this is. It does not, however, differentiate itself from adjacent network tools such as ethereum_net_listening or ethereum_net_version, which an agent could easily confuse for 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?

The description offers no when-to-use guidance, no prerequisites, and no comparison to alternative tools in the large RPC sibling set. The only contextual information given is transactional (cost and retry key), not about choosing 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?

Annotations declare openWorld and idempotent, but nothing in them reveals that this call is paid. The description adds real behavioral context: a concrete price (0.002500 test USDC on eip155:84532) and the instruction to preserve the idempotencyKey for retries. readOnlyHint=false is consistent with a call that spends funds, so no contradiction; it does not, however, describe failure/refund behavior when payment or the RPC call fails.

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

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

Three short sentences, purpose front-loaded, no filler. The third sentence is mildly redundant with the schema's idempotencyKey description, which keeps it just below a 5.

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

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

The call is trivial (no parameters, no output schema), and the description covers purpose, cost, and retry handling. What is missing is any hint of the return value - net_version is meaningless to an agent that doesn't know it returns a decimal network-id string - and no statement of what happens if the paid call fails.

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

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

The 'params' array is empty by definition (maxItems 0) so there is nothing to document there, and the recurring idempotencyKey semantics are already fully spelled out in the schema ('Persist before payment and reuse only for retries... Never publish it'). The description's 'Preserve the private idempotencyKey for retries' largely echoes the schema rather than adding new meaning, so this sits at the baseline for a half-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?

States a specific verb and resource ('Read net_version') pinned to a named chain (eip155:1), so the agent knows exactly which JSON-RPC method runs. It does not differentiate from close siblings like net_listening or net_peerCount, and it never says what net_version actually yields (the network id), so the agent must already know the RPC method to use it well.

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?

There is no when-to-use guidance, no mention of alternatives among the many net_/eth_ siblings, and no precondition beyond cost. The agent is told what it costs but not when choosing this call over ethereum_net_listening or ethereum_eth_chainId is right.

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

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, openWorldHint=true), and the description adds genuinely new context: the tool costs 0.002500 test USDC on eip155:84532 and the idempotencyKey must be preserved across retries. The cost disclosure also explains why readOnlyHint is false despite the word 'Read', so the two are consistent. It still omits what the returned version string looks like, keeping it from a 5.

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

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

Three tight sentences, front-loaded with the action and resource, then cost, then retry behavior. Every sentence carries information and there is no filler, though the cost sentence slightly interrupts the read/retry flow.

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 no-output-schema tool the description covers the payment and idempotency mechanics but never indicates the shape of the return value (a client version string). Given the tool's simplicity and the well-annotated safety profile, this is adequate but leaves a small gap an agent might want filled.

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 50%: idempotencyKey is fully documented in the schema (persist before payment, reuse only for retries), and params is a fixed empty array with no meaningful semantics. The description's 'preserve the private idempotencyKey for retries' reinforces the schema but adds little beyond it, and says nothing about the params array. Baseline 3 is appropriate given the schema does most of the work.

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

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

The description names a specific verb (Read) and a precise resource (web3_clientVersion) plus the chain (eip155:1), so the agent knows exactly which RPC method is invoked. It does not explicitly contrast itself with the many sibling eth_*/net_* methods, but the method name is distinctive enough to route correctly.

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?

There is no guidance on when to call this versus alternatives like eth_chainId or net_version, nor any stated prerequisites beyond an implied retry note. The only procedural hint is to preserve the idempotencyKey for retries, which is operational rather than usage-selection guidance.

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

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

Beyond the annotations, it discloses a concrete cost (0.002500 test USDC), the payment chain, and the retry contract for the idempotencyKey, which is genuinely useful context for a paid call. It does not explain the pure-computation nature of the method, and 'Read' sits in mild tension with readOnlyHint=false.

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

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

Three compact sentences, front-loaded with the target resource and then the operational constraints. No filler, though the first clause is almost too terse to be informative.

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 only two parameters, the operational side (cost, idempotency, chain) is well covered. What is missing is the method's semantics and return value, which the description leaves entirely to the agent's prior knowledge.

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 50%: idempotencyKey is fully described in the schema, and params is pattern-only with no textual meaning. The description reinforces the key's retry-persistence semantics but adds nothing about what data to pass as params.

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 verb and resource ('Read web3_sha3 from Ethereum') and names the chain, which separates it from the bitcoin_* siblings by namespace. However, it never says what web3_sha3 actually does (compute a Keccak-256 hash of the supplied data), so an agent unfamiliar with the raw RPC method gets no functional understanding.

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?

There is no guidance on when to call this versus the ~40 other ethereum_* methods. It only gives operational hints (cost, idempotency), not a condition for selecting this tool over alternatives.

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