Crypto Bot Audit + Market Data (x402 paid)

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

With readOnlyHint=true, idempotentHint=true, and destructiveHint=false already covering the safety profile, the bar is lower; the description earns credit by disclosing the $0.01 USDC x402 cost, a real behavioral side effect annotations cannot express. It also clarifies input format and enumerates exactly what findings are returned. Minor gap: it does not flag that the submitted source code is transmitted to an external service.

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

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

Two sentences, roughly 40 words, with zero filler. Input format and findings list are front-loaded, and the cost disclosure earns its place as the closing sentence. Every word adds signal.

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

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

For a simple one-required-param tool with annotations covering safety, the input format, cost, and findings categories give an agent enough to invoke it correctly. But with no output schema, the description carries the return-value burden and only lists finding names, not their structure; it also leaves 'filename' unexplained and does not differentiate from demo_audit. Adequate but with 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% (code has 'one JS/TS file', filename has none), so the description should compensate but does not. It merely restates the schema's type for 'code' ('Input one JS/TS source file (string)') and says nothing about 'filename's purpose or when it should be supplied. It adds essentially no meaning beyond the structured schema.

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

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

The description names a specific verb (audit), resource (crypto-bot JS/TS source), and enumerates the exact bug categories it detects (testnet-as-USD, silent-zero balance, cooldown key mismatch, fake faucet endpoint, speculative earnings text). The title echoes this. Among a sibling list dominated by chain_* and market_* tools, its purpose is unmistakable, and it is substantially differentiated from the closest sibling, demo_audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 context is implied via 'Input one JS/TS source file (string)' and the specific fake-earnings bug list, so an agent can infer when it applies. However, it never states when not to use it, names the alternative (demo_audit exists as a sibling), or gives selection conditions. Clear context, but no exclusions or alternative routing.

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

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

Adds non-obvious behavior beyond annotations: cost per call ($0.001 USDC) and formatting behavior ('formatted with whatever supply unit the contract uses'). These are not available in schema or annotations, and the description does not contradict the readOnlyHint/idempotentHint annotations.

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

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

The description is longer than strictly necessary but well-structured: purpose first, then cost, then chains, then a concrete REST equivalent. Each sentence adds value and the tool is not buried in fluff. Slightly verbose, but not rambling.

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

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

Covers the essential aspects for a read-only balance lookup: purpose, differentiation, cost, supported chains, and formatting behavior. The output schema handles return-value documentation, so the description need not explain that. It does not mention edge cases like invalid token or account, but that is minor for this kind of utility.

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

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

Schema coverage is 100%, so each parameter (chain, token, account, tokenId) is already documented with concise descriptions. The description's example URL underscores parameter usage but does not introduce new semantics beyond what the schema provides. 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?

Description states the exact operation (balanceOf for ERC-1155), specifies the contract type, and clearly differentiates from ERC-20/721 lookups. The mention of 'the read a Zora/Sudoswap-style position tracker needs' grounds it in a concrete use case, making the tool's purpose 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?

Provides clear context on when this tool is appropriate (ERC-1155 balance) and explicitly notes that ERC-20/721 lookups are insufficient. However, it does not name specific sibling tools like chain_1155_batch for multi-token queries or chain_1155_check for other checks, leaving the alternative selection partly implicit. The chain list and cost also help set expectations.

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?

Even though readOnlyHint, idempotentHint, and destructiveHint=false already cover safety, the description adds material behavior: $0.001 USDC cost per call, a 10-pair cap, supported chains, and byte-identical REST equivalence. No contradiction with annotations.

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

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

The main function is front-loaded and every segment—function, cost, chains, REST equivalence—carries distinct information. The long example URL is dense rather than 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 an output schema, full parameter descriptions, and strong annotations, the description covers purpose, cost, supported chains, batch limits, and exact endpoint equivalence. An agent has what it needs to select and invoke this tool.

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

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

Schema coverage is 100%, so the baseline applies and the description mostly restates positional matching and caps already in the schema. The byte-identical GET example demonstrates encoding (e.g., tokenIds=1,2) but leaves the accounts list delimiter implicit, so it adds only marginal value.

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

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

Description names the exact operation (balanceOfBatch) and resource (up to 10 ERC-1155 account/id pairs) in a single settled call, and positions it as a portfolio snapshot. This is distinct from the single-position 1155 siblings and from other chain balance tools.

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

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

It clearly indicates when to use the tool: when you need a multi-position snapshot and want to avoid one paid read per line. It does not explicitly name the single-balance sibling or state when not to use it, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context: it costs $0.001 USDC per call, supports a specific set of chains, and is byte-identical to a documented GET endpoint, which goes beyond the annotation defaults.

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

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

The description is front-loaded with its core purpose, then cost, chains, and REST equivalence. It is compact, though the byte-identical GET URL adds some redundant detail that could have been shortened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 annotations covering safety, an output schema covering return values, and a schema covering all parameters, the description provides the remaining essential context: why to use the tool, what it checks, what it costs, and where it works. Nothing critical is missing.

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

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

The input schema already documents all three parameters with 100% coverage. The description adds a concrete URL example showing chain, token, and tokenId, which is helpful, but it does not add material semantic meaning beyond what the schema already provides.

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

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

The description states a specific operation: checking ERC-1155 support via supportsInterface, contractURI, and an id probe. It clearly frames this as a pre-flight check before assuming a contract is a 721, distinguishing it from balance/URI siblings like chain_1155_balance and chain_1155_uri.

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

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

The description gives an explicit use case: 'the pre-flight before a client assumes a contract is a 721 and sends the wrong call.' It also lists supported chains and a per-call cost, giving context for when calling is appropriate, though it does not explicitly name alternatives or when not to use it.

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

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

Beyond the readOnly/idempotent hints, the description discloses valuable behavioral details: the `{id}` substitution is left visible, the URI is returned as text, the tool never fetches the URL itself, there is a $0.001 USDC cost, supported chains are listed, and results are byte-identical to a specific REST endpoint. This significantly exceeds the annotation baseline.

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

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

The description is compact and front-loaded with the most important semantic detail, then adds cost, chains, and an exact REST-equivalent reference. Every sentence contributes actionable information without 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 simple read-only ERC-1155 URI lookup, the description covers the output form, behavioral guarantee of not fetching, cost, supported chains, and REST equivalency. The output schema exists, and annotations cover safety/idempotency, so nothing critical is missing.

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

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

The schema already covers all three parameters with clear descriptions at 100% coverage, so the baseline applies. The description adds a concrete endpoint example and reiterates chain keys, but it does not substantially deepen parameter meaning beyond what the schema and example already convey.

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

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

The description clearly identifies the tool's action: decoding `uri(id)` from the ERC-1155 ABI and returning the metadata URL a wallet would fetch. It is specific about the resource and output format, and the title plus supported-chain list distinguish it from ERC-721-oriented sibling tools like `chain_nft_token_uri`.

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

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

The description implies when to use this tool—when you need the metadata URL for a token ID without fetching it—and clarifies that the tool never requests the URL. However, it does not explicitly direct users to alternative sibling tools (e.g., `chain_nft_token_uri` for ERC-721) or state when not to use it, leaving some routing to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: the cost per call ($0.001 USDC), the supported chains, the output format (raw and decimal), and a concrete example request. It also provides a byte-identical REST endpoint reference. This exceeds the minimum and enriches the agent's understanding of side effects and constraints.

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

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

The description is concise and front-loaded with the core purpose, followed by cost, chains, and a practical example. Each sentence adds value; the example is long but informative. It avoids unnecessary filler and is well-structured for quick scanning.

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

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

For a read-only, idempotent single-allowance lookup, the description covers the key context: cost, supported chains, output format, and a usage example. The output schema exists, so return values are defined elsewhere. It lacks error-case details or notes on edge cases, but these are not critical for a simple query tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description does not add significant semantic detail beyond the schema, but the included example request clarifies address format and the 'chain key' usage. Since the schema carries the heavy lifting, this is an adequate baseline score.

Input schemas describe structure but not intent. Descriptions should explain 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 clearly states the function's purpose: returning the allowance between owner and spender in raw and decimal form, with a contextual explanation ('how much a approval still lets a third party move'). It is specific about the resource and operation. However, it does not explicitly differentiate from sibling tools like chain_approvals_scan or chain_wallet_approvals, so it doesn't fully separate itself from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides no guidance on when to use this tool versus other allowance-related tools. It mentions the chains and cost but does not indicate scenarios where this specific call is preferred, nor does it mention alternatives or conditions for choosing another tool. The reader must infer usage from the name and description.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond those: the $0.001 USDC cost per call, supported chains, bounded windows, and byte-identical equivalence to a specific GET endpoint. This is exactly the operational detail an agent needs to safely invoke the tool.

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

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

The description is well-structured and front-loaded with the core purpose. It includes useful operational details like cost, chains, and an endpoint example. The byte-identical URL is long but serves as a precise, unambiguous example, so it earns its place.

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

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

With an output schema present, rich annotations, and fully described parameters, the description covers the remaining essentials: cost, chain list, bounded window, and exact endpoint equivalence. The only notable gap is not explicitly routing the agent away from closely related sibling tools like chain_wallet_approvals.

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

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

Schema description coverage is 100%, so the schema already documents chain, token, and blocks. The description adds an example request and clarifies the decoded output (owner/spender/amount), but it does not materially expand the meaning of the parameters themselves. 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 clearly states a specific action and resource: approving events for one token over a short, bounded window, decoded to owner/spender/amount. The 'who just gave someone leave to move their USDC' phrasing makes the tool's purpose vivid and easily distinguishable from siblings like chain_wallet_approvals, chain_allowance, and chain_transfers_scan.

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

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

The description gives clear context: use it for recent approval events for a single token, not for wallet-wide approvals or current allowance checks. It does not explicitly name alternatives or state when not to use it, but the 'one token' and 'short, bounded window' constraints make the intended usage reasonably clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false as safe. The description adds value beyond these by disclosing the return format (wei plus a decimal string), the inclusion of the chain symbol to prevent USD misreading, the per-call cost, and its byte-identical behavior to a REST endpoint—detail the annotations do not convey.

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

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

Four sentences, each dense with information: result semantics, pricing, supported chains, and endpoint equivalence. No filler or redundancy—every sentence contributes to the agent's ability to use the tool.

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

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

With an output schema present, return values need no elaboration. The description supplies cost, chain scope, block height semantics, and the exact REST equivalent, which is more than enough context for an agent to invoke this 2-parameter tool correctly.

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

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

Input schema coverage is 100%: both chain and address are documented with their expected formats. The description repeats the chain list but adds no new meaning about parameters beyond what the schema already states, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Native coin balance' for 'one address', further specifying 'at the latest block' and that it returns the chain's symbol. This clearly distinguishes it from siblings like chain_balances (plural) and chain_token_balance, and the supported chains list removes ambiguity.

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

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

The description gives useful context—pricing per call, supported chains, and the byte-identical REST endpoint—but does not explicitly say when to choose this tool over alternatives like chain_balances or chain_token_balance. Usage is implied by the 'one address' and 'native coin' phrasing, but no explicit when-to-use or when-not-to-use guidance is provided.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those annotations: the call is paid, costs $0.001 USDC, supports at most 25 addresses, and is byte-identical to a specific GET endpoint. No contradiction with annotations exists.

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

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

The description is compact and front-loaded: batching, limit, use case, cost, supported chains, and exact endpoint compatibility are all covered in four short sentences. No sentence is wasted, and the most decision-relevant facts appear first.

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

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

For a two-parameter batch read tool, the description covers everything needed to call it correctly: address limit, required chain selector, eligible chains, cost, and exact request shape. An output schema is present, so return-value documentation is not the description's responsibility.

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

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

Schema description coverage is 100%, so both chain and addresses are already documented in the schema. The description mostly repeats the chain list and 25-address limit, though the example URL does illustrate exact comma-separated formatting. This is helpful but not a substantial semantic addition beyond the schema.

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

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

The description clearly states that this is a batch native-balance lookup supporting up to 25 addresses in one call, and the title 'Batch native balances' reinforces the resource. It also distinguishes itself from single lookups by emphasizing batching and lower cost. The byte-identical endpoint reference makes the operation 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?

The description gives clear context for when this tool fits—portfolio and risk bot use cases needing many balances at once—and frames it as cheaper than 25 single lookups. It stops short of explicitly naming an exact alternative like chain_balance or stating a threshold for when to use the singular tool, so it earns a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns decoded/readable numbers rather than raw hex, includes a specific cost per call ($0.001 USDC), and states it is byte-identical to a REST endpoint. It does not mention pagination or error behavior, but for a single-block read tool this is sufficient.

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

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

The description is compact and front-loaded: it opens with the output fields, then cost, then chains, then the REST equivalence. Every sentence adds information. No filler or repetition of 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?

Given the tool's simplicity (2 params, 1 required, no nested objects) and the presence of an output schema, the description covers the essential context: what the output looks like, cost, supported chains, and the block parameter semantics. It does not explicitly state that the output schema describes the return shape, but the output schema exists and the description's field list aligns with it. A minor gap is not naming sibling tools for alternative lookup methods, but the 'by number or tag' phrasing is enough.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (chain and block) with their allowed values. The description adds the default for block ('latest') and the list of supported chains, but these are also present in the schema. The description does not add significant new meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description states a specific verb ('decoded'), a resource ('block header'), and the exact output fields (height, time, author, gas used vs limit, base fee in gwei, transaction count). It also distinguishes itself from sibling tools like chain_block_by_hash and chain_block_by_timestamp by clarifying it fetches by number or tag. The title 'Block by number or tag' reinforces the scope.

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

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

The description clearly states the supported chains and the block parameter options (number or latest|safe|finalized|earliest|pending), which tells an agent when to use this tool. It does not explicitly name alternatives like chain_block_by_hash or chain_block_by_timestamp, but the 'by number or tag' phrasing implies the distinction. It also mentions the cost and the byte-identical REST endpoint, which helps an agent decide if this is the right call.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description adds value beyond them by disclosing the $0.001 USDC cost, the supported chains, and byte-identical equivalence to the height-based endpoint. This gives the agent practical expectations about cost and response consistency. It does not cover error cases or rate limits, but those are less critical for a simple read-only lookup.

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

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

Three short sentences deliver purpose, usage context, cost, supported chains, and endpoint equivalence with no filler. The most important distinguishing information is front-loaded, and every clause earns its place.

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

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

For a two-parameter read-only lookup with a full output schema, the description covers everything an agent needs: what it returns, how it differs from the height-based sibling, which chains are supported, and the cost. No critical operational detail is missing.

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

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

Schema description coverage is 100%, with both chain and blockHash already documented. The description adds a concrete URL example and explains that blockHash is the key from receipts/logs/reorg reports, which slightly reinforces parameter meaning. However, it does not substantially expand beyond the schema's own descriptions.

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

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

The description clearly states the tool returns the same decoded block header as /chain/block but addressed by hash rather than height. This directly distinguishes it from chain_block and other block-related siblings. The resource and lookup key are unambiguous.

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

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

It explicitly identifies when to use this tool: when a receipt, log, or reorg report provides a block hash. It also contrasts with height-based lookup via '/chain/block', giving both a when and a when-not. The byte-identical note reinforces that the only difference is the addressing mode.

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

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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the $0.001 USDC per-call cost, the binary-search algorithm, the at-or-after boundary semantics, and the byte-identical REST endpoint equivalence.

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

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

Three sentences, zero filler: algorithm/purpose, cost, and chains + endpoint identity. The core semantics are front-loaded and every sentence carries operational value for the agent.

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

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

For a 2-param read-only tool with a full output schema and safety annotations, everything an agent needs is present: purpose, semantics, cost, supported chains, and endpoint reference. Return-value explanation is unnecessary given the output schema, and openWorldHint covers auth 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?

Schema description coverage is 100% — both chain (with the full chain list) and timestamp (unix seconds) are already documented in the schema. The description's example URL (chain=base&timestamp=1758000000) adds a concrete worked instance, but it mostly confirms rather than extends the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Binary-searches the header timestamps for the first block at or after a unix time') with precise matching semantics. This clearly differentiates it from siblings like chain_block_by_hash (lookup by hash), chain_block_number (latest block), and chain_block (by number).

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

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

Gives a concrete when-to-use: "every 'what was the supply / who held what on that date' question starts here," plus a differentiator ('no public node offers the lookup'). However, it never names sibling alternatives or states when not to use it, so the exclusion guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety. It adds useful behavioral context: data comes from a public node, the call costs a fixed amount, and the response is byte-identical to a REST endpoint.

Agents need to know what a tool does to the 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, each earning its place: the purpose and liveness use case, the cost, and the supported chains plus REST equivalence. It is front-loaded and has 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 one-parameter read-only tool with an output schema and strong annotations, this is complete. The agent knows what the tool does, when to choose it, how much it costs, which chains are supported, and how it maps to a REST endpoint.

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

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

Schema coverage is 100%, so the schema already fully documents the single required chain parameter. The description adds value by listing the supported chain keys in prose and restating that exactly one chain is queried, but this mostly duplicates the schema's parameter description.

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

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

States a specific verb and resource: returns the latest block number for one chain. It also distinguishes itself from the many chain_* siblings by framing it as the cheapest liveness/height check and noting it is byte-identical to a specific GET endpoint.

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

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

Explicitly says when to use it: as a cheap 'is the chain alive and where is it' check, with a concrete $0.001 USDC cost. It does not name alternative tools to prefer for deeper block data, but the 'one chain' and 'cheapest possible' framing gives clear context.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral details beyond annotations: the call costs $0.001 USDC, supported chains are enumerated, and it is byte-identical to a specific REST endpoint, giving agents information about cost, compatibility, and network coverage.

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

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

The description is a single dense sentence that packs purpose, cost, supported chains, and the alternative method without redundancy. It's slightly long but every clause earns its place, and the core purpose is front-loaded before supporting details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 an output schema present, return structure is covered. The description completes the picture with cost, chain list, and equivalence to the REST call. Nothing essential for correct invocation is missing, though error handling or rate limits are not mentioned (minor gap).

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

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

The input schema already provides complete descriptions for both 'block' and 'chain' (100% coverage). The description adds no extra parameter semantics—it doesn't explain parameter formats, defaults, or constraints beyond what the schema documents. Baseline 3 is appropriate when schema covers parameters fully.

Input schemas describe structure but not intent. Descriptions should explain 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 specific verb 'eth_getBlockReceipts' on the resource 'block receipts', lists the exact data returned (per-transaction gas, status, log count, fee distribution), and explicitly contrasts with per-transaction reads, making it unmistakable what this tool does and how it differs from siblings.

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

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

The description clearly implies when to use this tool—when you need all receipts for a block rather than one at a time—and gives the equivalent REST endpoint for reference. It doesn't name the sibling tool 'chain_receipt' explicitly, but the contrast 'instead of one receipt read per transaction' is a strong usage signal.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond those: the $0.001 cost, the supported chain list, the block cap, and byte-identical equivalence to the REST endpoint. No contradiction with annotations.

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

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

Each sentence earns its place: fields and purpose, cost, supported chains, and REST equivalence. It is compact, front-loaded with the most decision-relevant information, and contains 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 simple read-only tool with a full output schema and clear annotations, the description is nearly complete. The only minor gap is that it does not explicitly contrast itself with single-block or stats tools, but an agent can infer this from the raw-series framing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the chain list and the 'up to 25' cap, but it does not add new semantic details beyond the schema, such as how to format the blocks value as a string.

Input schemas describe structure but not intent. Descriptions should explain 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 exactly what is returned — height, timestamp, transaction count, gas used, and base fee for up to 25 consecutive blocks — and frames it as 'the series itself.' It also ties the tool to a concrete GET endpoint, making it easy to distinguish from single-block or aggregate-stat siblings.

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

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

It gives a clear use case: callers who want to plot throughput or fee pressure from raw series data rather than rely on an average. Supported chains and cost are stated, but it does not explicitly name alternatives like chain_block or chain_block_stats, so the guidance is strong but not fully explicit.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable non-obvious behavior: it uses two real header timestamps, does not smooth stalls, charges $0.001 USDC per call, and is byte-identical to a REST endpoint. No contradiction with annotations.

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

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

The description is compact and well-ordered: metric first, then the key behavioral differentiator, cost, supported chains, and REST equivalence. Every sentence earns its place and there is no filler or redundant schema 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?

Given the output schema exists and annotations cover safety/idempotency, the description is complete enough for an agent to call the tool correctly: it names required chain values, default window parameter, cost, and REST endpoint behavior. The only minor gap, exact bounds for 'blocks', is already disclosed as 'bounded' in the schema.

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

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

Schema coverage is 100%, so the baseline is 3. The description mostly restates the chain list and window concept already present in the schema; the REST query example ('chain=base&blocks=20') is mildly useful but does not add new parameter constraints or format details beyond the schema.

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

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

The description states a specific metric ('Seconds per block and blocks per hour') and the exact method ('timestamps of two real headers at the edges of a window'), which clearly identifies the resource as a raw block-cadence measurement. It also distinguishes itself from smoothed alternatives by noting that a stalled block widens the span rather than being averaged away, helping an agent separate it from siblings like chain_block_series.

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

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

It gives concrete operational context: supported chains, cost per call, and byte-identical REST endpoint equivalence, which makes invocation expectations clear. It does not explicitly name alternatives or state when not to use this tool, though the 'instead of being smoothed away' clause implies a preference for raw cadence measurements.

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, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. It adds valuable behavioral context by disclosing the $0.001 USDC cost, supported chains, and exact byte-identical REST endpoint equivalence.

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

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

The description is tightly written, front-loading the core purpose, then adding cost, supported chains, and endpoint equivalence. Every sentence earns its place without redundancy or 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 simple two-parameter read tool with a rich output schema and full parameter coverage, the description covers all needed context: result shape, cost, chain scope, and relationship to receipt-heavy alternatives. Nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents chain and block well. The description adds no additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states what the tool returns: every transaction hash in one block plus a count. It also differentiates itself from heavier alternatives by explicitly saying it does so 'without pulling full receipts,' which separates it from siblings like chain_block_receipts.

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

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

The description gives useful context for when to use this tool: it is the intermediate step between locating a block and seeing actual transfers, and it avoids pulling full receipts. It does not name a specific sibling alternative, but the receipts reference clearly signals the trade-off against receipt-level tools.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly a safe, read-only, idempotent operation. The description adds useful context about cost ($0.001 per call) and that results are derived from code rather than assumed, which goes beyond the annotations. However, it doesn't detail response structure or error behavior, but that is partially covered by the output schema.

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

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

The description is concise, with three sentences covering purpose, pricing, and chain list. It is front-loaded with the main purpose. The mention of a byte-identical GET endpoint is useful for debugging but adds a bit of extra length. Overall, every sentence earns its place, though it could be slightly tightened.

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

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

The description is complete for an agent to call the tool correctly: it explains what it does, costs, supported chains, and parameter defaults. The output schema is present, so return values are documented elsewhere. Cost and the difference from trusting a README are not in the schema or annotations, making the description cover the needed context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds context like the default count (40) and max (60) for the count parameter, which is helpful but not critical. The chain parameter's supported values are listed both in the schema description and the tool description, so the description adds limited extra value. 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 clearly states it scans deployed bytecode for 4-byte selectors and identifies named functions. It distinguishes from siblings like chain_bytecode_fingerprint by focusing on function discovery rather than fingerprinting. However, the phrasing 'which functions this code carries' is somewhat colloquial and could be more precise.

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

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

The description implies usage when you need to know what functions a contract supports by reading on-chain code, not trusting documentation. It mentions pricing and supported chains, which helps decide when to use it. However, it does not explicitly state when NOT to use it or mention any alternatives.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the $0.001 USDC cost, the list of supported chains, and the fact that it is byte-identical to a specific GET endpoint. This goes beyond annotation coverage and gives the agent practical operational knowledge. No contradiction with annotations.

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

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

The description is compact yet information-dense: definition, use case, cost, chains, and API equivalence all in a few sentences. The first sentence front-loads the core concept (fingerprint), and every clause serves a purpose. 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?

With an output schema present, return format is handled externally. Annotations cover safety and idempotence. The description covers use case, cost, supported chains, and a REST equivalence reference. An agent has everything needed to decide when to use this tool and how to invoke it correctly. Complete within its scope.

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

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

Schema description coverage is 100% for both parameters (chain lists allowed values, address specifies 0x + 40 hex). The description reinforces the chain list and provides a concrete example address in the URL, but adds little semantic nuance beyond the schema. Baseline 3 is appropriate since the schema fully documents parameters.

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

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

The description states a clear verb (fingerprint) and resource (contract's bytecode), and defines exactly what the tool computes: SHA-256 of deployed bytecode plus size and edges. It explicitly explains the semantic meaning (same fingerprint = same compiled contract) and the use case (detecting clones of known scams), distinguishing it from sibling tools like chain_code, chain_code_at, and chain_bytecode_capabilities. The purpose is unmistakable.

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

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

The description gives a concrete usage scenario: detecting clones of known scams before interaction. It also provides operational constraints (cost per call, supported chains) and references a REST endpoint equivalence. It does not explicitly state when NOT to use it or compare with alternative tools, which would have made it a 5, but the context clearly implies its intended use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it returns raw data plus decoded uint/address forms, costs $0.001 USDC per call, and is pinned to one public node. It does not mention rate limits or failure modes, but the added cost and return-format context justify a 4.

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

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

The description is compact and front-loaded: it states the core operation, the escape-hatch role, the cost, supported chains, and even a byte-identical REST example in three sentences. Every sentence earns its place, and the most important selection-relevant info (escape hatch, cost, chains) appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 the tool's complexity (raw calldata, multiple chains, cost, output schema present), the description covers the essential selection and invocation context: what it does, when to use it, what it costs, and which chains it supports. The output schema exists, so return values need not be described. Minor gaps like rate limits or node behavior are not critical for a read-only, idempotent 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 description coverage is 100%, so the schema already documents all four parameters. The description adds context about calldata being hex and the max size (4096 bytes) which is also in the schema, and it names the chains. It doesn't add much beyond the schema, but the 'raw return data plus decoded forms' hint helps an agent understand what the data parameter produces. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'eth_call with your own calldata against one pinned public node.' It clearly distinguishes itself as 'the escape hatch for any view function we did not wrap,' which differentiates it from the many chain_* sibling tools that wrap specific view functions. The title 'Read-only contract call' reinforces the 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?

The description explicitly frames this as the fallback for any view function not wrapped by a dedicated tool, which tells an agent when to use it versus the many chain_* siblings. It also lists supported chains and the exact cost, giving clear context for selection. The byte-identical REST equivalence further clarifies the operation.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds useful behavioral information: per-call cost, supported chain list, and byte-identical equivalence to a REST endpoint. No contradiction with annotations.

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

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

Four short sentences, each purposeful: purpose and rationale, cost, supported chains, and REST equivalence. No filler or redundant detail.

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

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

For a one-parameter read-only tool with an output schema and clear annotations, the description covers purpose, cost, supported chains, and REST equivalence. Nothing essential for correct invocation is missing.

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

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

The schema already fully describes the single chain parameter with the same chain list. The description repeats the supported chains and shows the REST equivalent but adds minimal semantic value beyond the schema. Baseline 3 is appropriate.

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

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

States explicitly that it returns web3_clientVersion for the node that served the call and explains the build string distinguishes reth, erigon, and proxies. This is a specific verb+resource and clearly sets it apart from the many chain_* siblings.

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

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

Provides clear context: use this to identify which client/implementation actually served the call, especially to detect a proxy serving a different chain. It also lists supported chains and cost, but does not explicitly name alternatives or when-not-to-use.

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 this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond those hints by specifying the eth_getCode size-check mechanism, per-call cost, supported chains, and REST equivalence, without contradicting any annotation.

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

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

The description is compact and front-loads the core purpose before cost and chain support. The byte-identical REST reference is mildly extra but useful and does not bloat the text.

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

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

For a simple two-parameter, read-only tool with an output schema, the description covers the essential context: what it checks, when to use it, cost, and supported chains. It does not describe alternatives or edge cases, but those are not critical given the schema and annotation coverage.

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

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

Schema coverage is 100%, so the baseline is 3. The description largely reiterates what the schema already provides (chain keys and address format) with the example URL, adding little new meaning beyond an illustrative concrete address.

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

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

The description clearly states the tool's function: an eth_getCode size check that reports bytecode length and whether an address is a contract, aimed at answering 'did I just send funds to an EOA'. This is specific and actionable, but it does not explicitly differentiate itself from closely named siblings like chain_code_at or chain_contract_check.

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

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

The description gives a clear use case: 'the two-second answer to did I just send funds to an EOA'. It does not explicitly mention when not to use this tool or which sibling to prefer, so it falls short of full alternative routing.

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

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive. The description adds valuable non-obvious behavior: the $0.001 USDC cost per call, supported chains, comparison-to-today semantics, and the byte-identical REST endpoint. This goes beyond what annotations alone provide.

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

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

The description is compact and front-loaded: function first, then use case, cost, chains, and REST mapping. Every sentence earns its place, and there is no redundancy with the structured 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?

Given an output schema exists and annotations fully cover the safety profile, the description supplies everything needed for correct selection and invocation: purpose, cost, supported chains, parameter format via example, and exact REST behavior. No critical practical detail appears missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the historical-block meaning and provides a concrete example query, but it does not add meaningful per-parameter semantics beyond what the schema already documents.

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

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

The description states a precise function: historical eth_getCode compared against today, and explicitly lists the outputs (bytecode present then, size at both points, change flag). This clearly distinguishes it from sibling tools like chain_code (current code) or chain_contract_diff.

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

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

The description gives a concrete use case: 'what did this address look like when I traded', which tells an agent when this historical comparison is appropriate. It does not name sibling alternatives or state when not to use it, but the context is clear enough for selection.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds per-call cost of $0.001 USDC, the supported chain set, and byte-identical equivalence to a REST GET endpoint with a worked example. It does not describe behavior for non-contract addresses, but the output schema exists and there is no contradiction with the annotations.

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

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

Three sentences, front-loaded with the core value proposition before cost, chains, and REST equivalence. No filler; the endpoint example is compact and informative rather than redundant. Every sentence earns its place.

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

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

Between the output schema, the annotations, and the description's cost/chain/endpoint details, nothing needed to call the tool correctly is missing. It would be marginally improved by naming exactly which interface standards are covered, but the phrase 'supported-interface answer' and the output schema cover that territory.

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

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

Schema description coverage is 100%: chain already lists all supported keys and address is described as 'contract to fingerprint'. The description's only extra parameter signal is the example URL showing chain=base and a 0x-prefixed address, which does not substantially change how an agent would populate the fields. Baseline of 3 is appropriate when the schema already carries the parameter documentation.

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

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

The description names a concrete deliverable — bytecode size plus supported-interface answers — and frames it as a pre-flight check for whether an address is a contract and which standards it claims. This differentiates it from sibling tools like chain_bytecode_fingerprint, chain_bytecode_capabilities, and chain_token_meta by emphasizing a combined one-call fingerprint. The verb 'check' is generic, but the resource and outcome are specific.

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

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

It explicitly states when to reach for it: before interacting with a token address, as a pre-flight. The 'one call' framing and the cost/chain details give clear context for use. It does not name alternatives or exclusion criteria, leaving the agent to infer the boundary against chain_bytecode_fingerprint and chain_bytecode_capabilities, but the guidance is still strong.

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

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

Annotations already mark the tool read-only, non-destructive, idempotent, and open-world. The description adds useful behavioral detail beyond that: the exact comparison method (size, SHA-256, prefix/suffix equality), the cost of $0.001 USDC per call, supported chains, and that it is byte-identical to a specific GET endpoint.

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

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

The description is compact and front-loaded: it states the core behavior first, adds a memorable use case, then lists cost, chains, and endpoint equivalence. Every sentence adds relevant decision or invocation information without unnecessary padding.

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

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

For a simple three-parameter read-only tool with a full input schema and output schema, the description covers what it does, why it is useful, cost, supported chains, and an exact REST equivalent. No critical information for invoking the tool correctly is missing.

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

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

Schema coverage is 100%, so the structured schema already documents chain, address, and other. The description reinforces that the two addresses are compared bytecode-level and provides a concrete example URL, but it adds little substantive parameter meaning beyond what the schema already provides.

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

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

The description uses a specific verb and resource: comparing bytecode fingerprints (size, SHA-256, and prefix/suffix equality) of two addresses. It also grounds the purpose in a concrete question—detecting whether a new token is a redeploy of a previously rugged one—making it clear and distinct from related chain_* tools.

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

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

The description gives a clear intended use case: checking if a contract at one address is a redeploy of another known contract. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough to guide an agent toward this tool for contract-diff comparisons.

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

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

Annotations already cover read-only/idempotent/non-destructive. The description adds beyond them: cost per call, supported chains, and the fact that it compares a function call with a storage read. No contradictions with annotations.

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

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

Three sentences, all essential: what it returns, why it matters, then cost/chains/API equivalence. Front-loaded with the core behavior and no filler.

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

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

The tool has an output schema sufficient for return values, annotations cover the safety profile, and the description supplies operational details (cost, chains, byte-identical endpoint). Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and both parameters are already described. The description repeats the chain list but adds no meaning beyond the schema, so it meets the baseline 3 without extra compensation.

Input schemas describe structure but not intent. Descriptions should explain 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 clearly states that the tool decodes owner() and checks whether the same address answers as a storage read, then explains why that matters (who can pause, mint, upgrade). This is specific and easily distinguished from sibling chain_* tools.

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

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

It provides clear context by telling the agent the owner field decides who can pause/mint/upgrade, which signals when to use it. However, it does not explicitly name alternatives or define when not to use it, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the exact fee components returned, the 21000-gwei transfer assumption, the per-call cost, and the byte-identical equivalence to a specific REST endpoint. It also discloses the chain list. The only minor gap is not describing the output schema structure, but an output schema exists, so that burden is reduced.

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

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

Three sentences, each earning its place: the first defines the output and scope, the second gives the cost, the third lists chains and the REST equivalence. The most decision-relevant information (what it returns, cost, chains) is front-loaded. No filler or repetition of schema content.

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

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

For a single-parameter read-only tool with a full output schema, the description is complete. It tells the agent what the tool returns, which chains are valid, what the call costs, and that it matches a known REST endpoint. The annotations cover safety, and the output schema covers return structure. Nothing an agent needs to decide whether to call this tool is missing.

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

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

Schema coverage is 100% and the single parameter 'chain' is already described in the schema with the allowed values. The description adds value by listing the supported chains again in prose and by clarifying that the quote is for 'one chain' at a time. With only one parameter and full schema coverage, the description doesn't need to do much more; the baseline 3 is exceeded slightly because the description reinforces the chain-key semantics and the per-chain scope.

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

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

The description states a specific verb ('get' implied via 'what sending costs right now'), a clear resource (EIP-1559 fee quote), and enumerates the exact fields returned (gasPrice, base fee, priority fee, all-in cost of a 21000-gwei transfer in wei and native units). It also names the supported chains, which distinguishes it from generic fee tools. The title 'Full EIP-1559 fee quote' reinforces the resource. This is clearly differentiated from siblings like chain_fee_history and gas_prices.

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

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

The description implies when to use it: when you need current EIP-1559 fee components and the all-in cost of a standard transfer on a specific chain. It names the supported chains and notes the cost per call ($0.001 USDC), which is a practical usage consideration. However, it doesn't explicitly state when NOT to use it or name alternatives like chain_fee_history or gas_prices, so it misses the explicit exclusion/alternative guidance that would earn a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds the cost of $0.001 USDC per call and notes byte-identical equivalence to a specific REST endpoint, which are behavioral traits beyond the annotations. It does not cover rate limits or pagination, but for a read-only tool this is adequate.

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

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

The description is moderately long but every sentence adds value: functionality, limitation, cost, supported chains, and REST equivalence. It is front-loaded with the primary purpose, and the structure is logical. It could be trimmed slightly but remains efficient and 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?

Given the existence of an output schema and annotations covering safety, the description provides sufficient context: purpose, when to use vs. alternative, cost, chain support, and a concrete REST equivalent. No critical information is missing for an agent to correctly invoke this tool.

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

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

Schema coverage is 100% for both chain and blocks parameters, each with clear descriptions. The description does not add any parameter-specific details beyond what the schema already provides, such as syntax or format. With full schema coverage, the baseline of 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 clearly states it retrieves eth_feeHistory over a bounded window, detailing the exact data (base fee plus 25/50/75 priority-fee percentiles). It also differentiates from the sibling chain_fee_data by explicitly stating that a single instantaneous quote cannot answer whether gas is rising, making its purpose unambiguous and distinct.

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

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

It explicitly contrasts with /chain/fee-data (instantaneous quote) and explains that this tool is needed to assess fee trends over multiple blocks. It also lists supported chains and a REST equivalent, but it does not name other potential alternatives like chain_gas_estimate or gas_prices, so the guidance is clear but not exhaustive.

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 it read-only and idempotent, so no contradiction. The description adds pricing information and the exact HTTP endpoint for cross-referencing, but does not clarify that it performs a simulation without state changes or that the result is a gas estimate in wei. It adds some value beyond annotations but could be more explicit about the non-persistent nature.

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

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

The description is compact and front-loads the core purpose, followed by pricing, chains, and an example. It is efficient with no fluff, though the example URL is lengthy and might be unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 the tool has 5 parameters and an output schema, the description covers the main use case but lacks details on edge cases (e.g., what if 'from' is omitted, how the estimate is interpreted, or whether it supports token transfers beyond native value). It is adequate for basic usage but not comprehensive for complex contract interactions.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds context that the 'to' parameter is a contract address and that 'data' is hex calldata, but this is also in the schema. It does not clarify the default for 'from' (e.g., zero address) or the format of the returned estimate, so the description adds limited extra value.

Input schemas describe structure but not intent. Descriptions should explain 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 clearly states the purpose: estimating gas for a transfer or contract call, with specific reference to eth_estimateGas. It distinguishes itself from siblings like chain_call and chain_fee_data by focusing on gas estimation for a call the agent describes, without needing a wallet.

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

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

The description provides enough context for when to use it: when you need to estimate gas for a specific transaction before signing. It also lists supported chains and mentions pricing, but does not explicitly say when NOT to use it or suggest alternatives like chain_fee_data for general fee info.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description is free to add non-safety traits. It discloses the cost ($0.001 USDC per call) and the byte-identical endpoint equivalence, both valuable for the agent. No contradictions with annotations; no side effects need mentioning since it's read-only.

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

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

Two sentences with zero waste. The core output is front-loaded ('Latest block... block fullness'), followed by the use case, cost, supported chains, and API equivalence. Every clause contributes value, making it highly efficient for an agent to parse.

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

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

For a single-parameter, read-only tool with an output schema, the description covers what it returns, cost, supported chains, and exact API mapping. It doesn't mention error handling or rate limits, but those are minor for such a simple call. The presence of an output schema covers return structure.

Complex tools with many parameters or behaviors need more documentation. 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 input schema already provides 100% coverage of the 'chains' parameter (comma list, up to 4, allowed values, default). The description merely repeats this list and limit without adding new meaning like formatting examples or edge-case behavior. Baseline 3 is appropriate given high schema 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 precisely states the resource ('Latest block, its age in seconds, base fee and block fullness') and scope ('for up to 4 chains'), making it distinct from sibling tools like chain_block or chain_fee_data. It even frames the use case ('fastest answer to which chain is caught up'), so an agent can immediately tell this is a multi-chain head-status aggregator.

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

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

It gives a clear situational trigger ('fastest answer to which of these chains is actually caught up right now') and mentions the paid nature, but does not explicitly name alternatives or state when NOT to use it. The specific use case effectively separates it from other chain_* tools, though a direct comparison would strengthen it.

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

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

Beyond the readOnly/idempotent annotations, it discloses chunked window walking, response-size-related refusals, reporting ranges no node would serve instead of failing a settled call, per-call cost, and supported chains. This gives the agent a detailed expectation of execution behavior and error handling.

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

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

Four dense sentences plus a concrete REST example with no filler. The core operation is front-loaded before cost, chains, and the example, and every sentence earns its place.

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

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

Between the annotations, schema, output schema, and this description, an agent knows parameters, filters, block cap, chain support, cost, and failure behavior. The description does not need to explain return values because an output schema exists.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description adds value by clarifying the 1000-block cap, the address/topic filtering requirement, and the toBlock default behavior, which goes beyond baseline but stops short of per-parameter documentation.

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

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

The description opens with 'eth_getLogs over a bounded window (max 1000 blocks) with an address and/or first topic — transfers and events without running an indexer', giving a definite verb, resource, and access mechanism. This clearly separates it from sibling chain block/transaction tools, and the title reinforces the address/topic focus.

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

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

It states the intended filter conditions (address and/or topic), the block-window constraint, supported chains, and warns that unfiltered scans are refused, so an agent knows when it fits a request. It does not explicitly name a sibling alternative, but the context is clear enough for bounded log queries.

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

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

Beyond the readOnly/idempotent annotations, it discloses partial-failure semantics ('one reverting view cannot fail the rest'), per-call pricing, supported chains, and byte-identical REST equivalence. This is exactly the behavioral context an agent needs.

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

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

Dense but efficient: core operation first, then failure semantics, cost, supported chains, and a concrete example. 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 read-only batch tool with full schema coverage, rich annotations, and an output schema, the description covers selection, invocation format, cost, and edge-case behavior. Nothing essential is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a concrete URL example showing exact call formatting (0xTo:0xCalldata, comma-separated) and blockTag usage, which reinforces the schema's parameter descriptions.

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

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

States a specific verb and resource: batched eth_call over up to ten (target, calldata) pairs. The phrase 'each answered independently' and the title's 'contract reads' distinguish it from single-call siblings like chain_call.

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

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

The description gives clear context for when to use it: multiple contract reads, with a cost advantage ('A tenth of the per-call cost of doing them one at a time'). It does not explicitly name chain_call or state when not to use it, but the batching and pricing make the intended use obvious.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: it performs two internal calls, costs $0.001 USDC, and explains the real-world consequence of a mismatch. This enriches the behavioral model without contradicting annotations.

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

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

The description is compact – three sentences that front-load the core purpose, then add cost and chain list. No filler or redundant phrases. It could be slightly tighter (e.g., merging chain list with schema) but is well-structured and easy 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?

For a one-parameter tool with an output schema, the description covers the essential context: what it does, cost, supported chains, and an endpoint reference. It doesn't explain the output structure, but that's already provided by the output schema. No critical missing detail for an agent to invoke it correctly.

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

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

Schema description coverage is 100% – the single parameter 'chain' is fully described with an explicit list of accepted values. The description repeats that list and adds the example endpoint URL, but does not introduce new syntactic meaning. Since the schema already carries full parameter semantics, a baseline of 3 is appropriate; slight credit for the endpoint mapping, but not enough for a 4.

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

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

The description clearly states the tool's function: comparing eth_chainId and net_version for a given chain. It explains the purpose (safety check against signing on the wrong network) and distinguishes it from other chain_* tools by focusing on ID agreement rather than balances, blocks, or calls. The verb 'check' and resource 'chain ID vs network ID' are specific and 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?

The description gives strong context for when to use it ('two-call safety check'), notes the cost, and lists supported chains. It doesn't explicitly name alternatives or say when not to use it, but there are no direct siblings (e.g., no other tool checks chain ID agreement), so the guidance is adequate. The endpoint equivalence adds helpful practical context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond those: the $0.001 USDC cost per call, the supported chains, and byte-identical equivalence to a REST GET endpoint. No contradiction with annotations.

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

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

The description is compact and front-loaded: purpose, result interpretation, cost, supported chains, and REST equivalence each earn their place. There is no filler or repetition of schema details.

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

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

For a read-only single-approval lookup with full schema coverage and an output schema, the description covers the essential context: what the result means, cost, chains, and REST parity. The only minor gap is not explicitly routing the agent away from chain_nft_approved_for_all, but the 'single-operator' phrasing largely covers that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the tokenId parameter through getApproved(tokenId) and provides a concrete example URL, but it does not add substantial semantic meaning beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain 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 operation — getApproved(tokenId) — and the resource: the single-operator approval for one specific NFT id. It also distinguishes itself from the sibling chain_nft_approved_for_all by emphasizing 'single-operator' and 'one id', so an agent can tell them apart.

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

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

The description implies when to use it: to check whether a single non-owner operator is approved to transfer one exact token. It explains the meaning of a non-zero result, but it does not explicitly state when not to use it or name alternatives such as chain_nft_approved_for_all.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the cost ($0.001 USDC per call), the supported chains, and the byte-identical REST endpoint. It also explains the security relevance (NFT drain headlines), which helps the agent understand the semantic meaning of the result. No contradiction with annotations.

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

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

The description is compact and front-loaded with the core function name and security context. The cost and chains are listed efficiently. The byte-identical REST endpoint example is a bit long and arguably redundant, but it provides a concrete reference. Overall, every sentence earns its place, though the endpoint example could be trimmed.

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

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

The tool has an output schema, so return values are covered elsewhere. The description covers the purpose, cost, chains, and the exact function. It doesn't mention pagination or edge cases, but for a simple boolean check that's acceptable. The only gap is not explicitly stating when to prefer this over chain_nft_approved, but the function name and 'per pair' make it clear enough.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters (chain, token, owner, operator). The description adds the function signature isApprovedForAll(owner, operator) and clarifies operator as 'delegate/operator address being tested' in the schema. The description doesn't add much beyond the schema, but the schema is complete. 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 clearly states the tool checks isApprovedForAll(owner, operator), the setApprovalForAll permission behind NFT drain headlines, per pair. It names the exact function and the resource (NFT approval state), and the title reinforces the question. It distinguishes itself from siblings like chain_nft_approved (single token approval) by specifying the setApprovalForAll permission.

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

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

The description gives clear context: it answers the setApprovalForAll permission per pair, and mentions chains supported. It doesn't explicitly say when to use this vs chain_nft_approved or chain_approvals_scan, but the phrase 'per pair' and the function name imply the use case. It also notes it's a paid call, which is a usage consideration. Missing explicit exclusions or alternatives, so not a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's burden is reduced. It adds valuable details not in annotations: the $0.001 USDC cost per call and the supported chains. These enrich the agent's understanding of cost and applicability without contradicting any annotation.

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

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

The description is two sentences long, front-loads the core function, and packs in cost and chain support without fluff. The example URL is somewhat lengthy but serves as a concrete reference. Every sentence adds value, though the example could be trimmed without losing essential info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 that an output schema exists (return format is presumably handled there), the description adequately covers the tool's purpose, cost, supported chains, and the nature of the query. For a simple balance check, no critical usage details are missing. The only minor gap is the lack of explicit guidance on when to use this versus sibling NFT tools, but that's covered under usage guidelines.

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

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

The schema covers all three parameters with descriptions, so the baseline is 3. The description adds the list of valid chain values (base, ethereum, arbitrum, bsc, polygon, optimism, avalanche) that the schema lacks (no enum), and provides a concrete example URL illustrating parameter usage. This meaningfully enhances 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?

Clearly states it performs balanceOf(owner) on an NFT contract and returns the count of token IDs held by a wallet. Explicitly differentiates from other NFT tools by noting it avoids indexing every transfer, and the phrase 'how many ids one wallet holds' is precise. The tool name 'chain_nft_balance' is reinforced with concrete 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?

Provides context that it's a balance query and mentions efficiency ('without indexing every transfer'), but does not explicitly name alternative tools or state when to prefer this over siblings like chain_nft_owner or chain_nft_approved. The absence of explicit exclusions or alternative routing leaves some inference to the agent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds significant value by stating a per-call cost, listing supported chains, and explaining the mechanism (via supportsInterface). It also mentions it's byte-identical to a specific GET endpoint, which adds operational detail 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?

The description is only two sentences, yet packs in purpose, cost, supported chains, and an exact endpoint reference. Every sentence contributes, and the key information is front-loaded. There is no fluff.

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

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

For a read-only tool with only two parameters and an output schema, the description covers the essential aspects: what it returns, cost, chains, and an exact API mapping. It also distinguishes from siblings by describing its specific function. Nothing critical is missing for an agent to decide whether and how to call it.

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

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

The input schema already describes both parameters (chain and token) with 100% coverage. The description adds a concrete example endpoint with a specific token address, which could help agents understand the expected format, but it doesn't add semantic meaning beyond what the schema provides. Thus a 3 is appropriate given the high schema 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 clearly states the tool returns the NFT contract's name, symbol, and the token standards it claims via supportsInterface, specifically listing ERC-165, ERC-721, ERC-721Metadata, and ERC-1155. This distinguishes it from sibling tools like chain_nft_balance or chain_nft_owner, which address different aspects of NFTs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 provides context: it lists supported chains and the cost per call, and gives an exact byte-identical API endpoint. It doesn't explicitly say when to prefer this over alternative tools, but the purpose (metadata and standards) is clear enough to guide selection. It doesn't mention exclusions or alternatives, so it's not a full 5.

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