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

No annotations are provided, so the description must fully disclose behavior. It states it is read-only and lists errors (InvalidParams, InternalError), but does not mention that the call is a simulation (no gas cost), that the contract must have code, or that the data must be ABI-encoded. While examples help, more behavioral details would improve transparency.

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 with bullet points for args, returns, errors, and examples. It is fairly concise at about 10 lines, but could be slightly trimmed (e.g., remove some redundancy). The key information is front-loaded in the first sentence.

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 there is no output schema, the description adequately explains the return value (hexadecimal string) and errors. It covers the main parameters and provides examples. However, it misses the 'response_format' parameter (documented only in schema) and could mention that the call simulates execution on the specified network state. Overall, it is fairly complete for a tool with 4 parameters.

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 each parameter is documented in the schema. The description elaborates on 'to', 'data', and 'network' with formats and defaults, adding value beyond schema. However, the 'response_format' parameter (present in schema) is not mentioned in the description, leaving a gap. The examples add clarity for 'to' and 'data'.

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

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

The description clearly states 'Execute a read-only smart contract call without creating a transaction,' which specifies the verb (execute), resource (smart contract call), and read-only nature. This clearly distinguishes it from sibling tools like eth_getBalance or eth_sendTransaction (not listed but implied), making the 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?

The description gives when to use (read-only calls without creating a transaction) and includes examples and error conditions. However, it does not explicitly mention when not to use or compare with alternatives among the many sibling tools (e.g., eth_call vs. eth_estimateGas for gas estimation). The guidance is clear but lacks explicit exclusions.

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

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

With no annotations provided, the description fully carries the burden. It discloses the operation (read-only query), return type (hex string), and errors (Infura API unavailability), ensuring transparency about behavior.

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

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

The description is concise, well-organized with sections (Args, Returns, Examples, Errors), and front-loads the purpose. Every sentence serves a clear role.

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 simplicity of the tool (2 parameters, no output schema), the description covers purpose, major parameters, returns, examples, and errors. It lacks detail on 'response_format' but the schema covers it, making it adequately complete.

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

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

The schema has 100% coverage, so baseline is 3. The description adds value by explaining the 'network' parameter with default and examples, but does not mention 'response_format', which is only in the schema. Overall meaningful addition.

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

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

The description clearly specifies the tool retrieves the chain ID for EIP-155 signing. It distinguishes from sibling tools like eth_call or eth_getBalance, which serve different purposes.

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 examples and context for EIP-155, yet it does not explicitly state when not to use this tool or mention alternatives. However, the uniqueness of the function among siblings makes usage 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?

With no annotations, the description carries full burden. It discloses key behaviors: non-broadcasting, returns hex string, defaults to mainnet, and errors. It lacks discussion of rate limits or authentication, but adequate for a read-only query.

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?

Well-structured with headings (Args, Returns, Examples, Errors) and front-loaded purpose. Slightly lengthy but each section adds value. Could be more concise but remains 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?

No output schema, but description explains return format (hex string) with example. Covers errors and network default. Complete for a simple estimation tool with clear expected behavior.

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

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

Schema coverage is 100%, baseline 3. The description adds value by explaining hex formats, providing unit conversion example, and listing error conditions. However, it misses the response_format parameter, which has a schema description. Overall, adds meaningful context beyond 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 explicitly states 'Estimate the gas required to execute a transaction without broadcasting it.' This clearly distinguishes it from sibling tools like eth_call (which executes) and eth_gasPrice (which returns current price).

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 clear context and examples (ETH transfer, Sepolia network), but does not explicitly state when not to use or compare to alternatives. It is clear enough for typical usage.

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

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

With no annotations provided, the description fully carries the burden. It discloses the return format (hexadecimal string in wei), lists possible errors, and provides examples. It does not overpromise or hide side effects (none expected).

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-organized with clear sections (Args, Returns, Examples, Errors). It is concise yet comprehensive—every sentence adds useful information without redundancy.

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

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

The tool is simple, and the description covers all necessary aspects: purpose, parameters, return format, usage examples, and error cases. There is no output schema, so the description adequately explains the return value. No gaps remain.

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%, but the description adds significant value: it explains the address format, enumerates tag options with meanings, clarifies the network parameter with a default, and includes concrete examples. This goes well beyond the schema 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 it retrieves the ETH balance of an address at a specific block. The verb 'Get' and resource 'ETH balance' are specific, and it distinguishes itself from sibling tools like eth_call or eth_getTransactionByHash, which have different purposes.

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 implicitly clarifies usage by specifying exactly what the tool does (get balance). It does not explicitly mention when not to use it or list alternatives, but the context of sibling tools makes it clear this is the correct tool for balance 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?

With no annotations, the description reveals error types (InvalidParams, InternalError) and the return of null for missing blocks, though it lacks details on rate limits or authentication.

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-organized with clear sections (Args, Returns, Examples, Errors), using concise language without wasting words.

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

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

Despite lacking an output schema, the description lists key return fields and error conditions, giving the agent a complete understanding of the tool's behavior and output.

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

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

Schema covers all parameters (100%), and the description adds value by specifying blockHash format (66 chars with 0x prefix), clarifying fullTransactions behavior, and providing examples. It omits response_format but is still helpful.

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 retrieves detailed block information using a block hash, distinguishing it from the sibling tool eth_getBlockByNumber which uses block 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?

The description provides examples and clarifies parameter options, but does not explicitly state when to use this tool over alternatives like eth_getBlockByNumber.

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?

No annotations exist, so the description fully covers behavior: it describes the return value (Block object or null), specific error types (InvalidParams, InternalError), and includes examples. It makes the tool's read-only, safe nature clear.

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-organized with Args, Returns, Examples, and Errors sections. Every sentence provides necessary information without redundancy. It is appropriately sized for the tool's complexity.

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

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

Given no output schema, the description explains the return object (including field examples) and null case. It also covers error conditions and provides concrete examples, making it complete for an agent to use effectively.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining blockNumber accepts hex or tags, fullTransactions boolean, and network defaults to mainnet. However, it omits the response_format parameter, though it does describe return format elsewhere. Examples and error info further enhance understanding.

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 'Get detailed block information using its number or tag,' which is a specific verb and resource. It distinguishes from siblings like eth_getBlockByHash (block by hash) and eth_getBlockNumber (just the 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?

The description provides clear context for when to use this tool, with examples demonstrating typical usage. However, it does not explicitly state when not to use it or compare to alternatives, leaving some implicit 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?

The description fully discloses the tool's behavior: it queries an Ethereum network, returns a hexadecimal string, and can raise InternalError if the Infura API fails. It also explains the default network. Since no annotations are provided, the description carries the full burden and does so thoroughly.

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 with sections for description, args, returns, examples, and errors. It is concise with no redundant sentences, making it easy 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?

Despite lacking an output schema, the description explains the return value (hex string) and covers errors. Both parameters are documented in the schema, and the description adds context for network. For a simple tool, this is complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value for the network parameter by explaining its usage and providing examples. However, it does not mention response_format, which is covered in the schema. Overall, it meets the baseline.

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

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

The description explicitly states 'Fetch the latest block number from an Ethereum network', which is a specific verb+resource. It clearly distinguishes from sibling tools like eth_getBlockByNumber or eth_getBlockByHash, which fetch full block data.

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

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

The description provides examples and notes the optional network parameter with a default. While it doesn't explicitly exclude siblings, the purpose is clear, and the context is sufficient for an agent to decide when to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It explains the return value (hex string, null if block not found), lists possible errors (InvalidParams, InternalError), and gives examples. It does not detail auth or rate limits, but for a read-only blockchain query 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 well-organized with sections for Args, Returns, Examples, and Errors. Every sentence adds value, and there is no redundant or extraneous 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 block transaction count tool with 3 parameters and no output schema, the description fully covers purpose, all parameters, return format, error conditions, and usage examples. It is complete enough for correct invocation.

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

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

Schema description coverage is 100%, providing baseline of 3. The description adds value by specifying blockHash format (66 chars with 0x prefix) and network default. However, it omits the response_format parameter present in the schema, missing the chance to explain its options (json/markdown).

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 gets the number of transactions in a block by its hash. It is distinct from sibling tools like eth_getBlockTransactionCountByNumber (which uses block number) and eth_getTransactionCount (which counts transactions for an address).

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

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

The description includes examples showing typical usage and optional network parameter, making it clear when to use. However, it does not explicitly state when not to use or suggest alternatives among the many siblings.

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

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

With no annotations, the description fully discloses return format (hex string or null), error types (InvalidParams, InternalError), and network parameter. It does not explicitly state it is a read-only operation, but the behavior is well-documented.

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 with clear sections (Args, Returns, Examples, Errors). Every sentence is informative, no fluff, and appropriately sized.

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 absence of annotations and output schema, the description completely covers parameters, return value, errors, and provides examples. It is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining blockNumber can be hex or tag, clarifying defaults for network, and including examples and error scenarios that go beyond schema details.

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 'Get the number of transactions in a block identified by its number or tag.', which specifies the action and resource. It distinguishes from siblings like eth_getBlockTransactionCountByHash by explicitly mentioning block number or tag as identifier.

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 includes examples and error information but does not explicitly state when to use this tool versus alternatives (e.g., eth_getBlockTransactionCountByHash). The usage context is implied but not contrasted with siblings.

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

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

Describes return format (hex string), error conditions, and that it queries Infura API. However, no mention of authentication or rate limits, though read-only nature is implied.

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

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

Well-structured with Args, Returns, Examples, and Errors sections. Every sentence adds useful information without redundancy.

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

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

Given no output schema, the description fully explains the return value, covers all parameters, provides examples, and lists possible errors. Sufficient for the tool's complexity.

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

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

With 100% schema coverage, baseline is 3. Description adds value by explaining contractAddress format, network defaults, and response_format enum with examples, going beyond what the schema 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?

Description clearly states 'Get the deployed bytecode of a smart contract' with a specific verb and resource. Distinguishes from sibling tools like eth_getBalance and eth_getStorageAt by focusing on deploying code retrieval.

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 with examples and notes on default network and return '0x' for non-contracts, but does not explicitly state when to use this tool over 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?

With no annotations, the description fully discloses behavior: it is a read-only historical query, returns specific fields (baseFeePerGas, gasUsedRatio, etc.), lists possible errors (InvalidParams, InternalError), and mentions the underlying API (Infura). This provides sufficient transparency for safe usage.

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-organized into sections (Args, Returns, Examples, Errors), concise with no wasted words, and front-loaded with the main purpose. Examples provide concrete usage patterns. Every sentence adds value.

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

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

The description covers purpose, parameter formats, return structure, examples, and errors. It lacks mention of the response_format parameter (though schema covers it), but otherwise is complete for a read-only tool with no output schema. The examples aid in understanding complex parameters like rewardPercentiles.

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%, but the description adds meaningful details beyond the schema: blockCount requires hex format (e.g., '0x4'), newestBlock can be 'latest', 'pending', or hex, rewardPercentiles is an array of numbers, and network defaults to 'mainnet'. Examples further clarify parameter use. The response_format parameter is not described, but schema already covers it.

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

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

The description clearly states 'Get historical gas fee data for EIP-1559 fee estimation.' This specifies the action (get), resource (historical gas fee data), and context (for EIP-1559 fee estimation), distinguishing it from siblings like eth_getGasPrice which returns current gas price.

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 for fee estimation, but provides no explicit guidance on when to use this tool versus alternatives (e.g., eth_getGasPrice for current price, other eth_call for data). No when-not-to-use or exclusion criteria are given.

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

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

With no annotations, the description carries the full burden. It discloses the return format (hex string), errors (InternalError), and default network. It does not mention idempotency, rate limits, or authentication, but for a simple read-only getter, the provided details are adequate and add value beyond the input 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 highly concise and well-structured with clear sections for Args, Returns, Examples, and Errors. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.

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 simplicity of the tool and lack of output schema, the description fully covers all needed context: input parameters, return value, error cases, and usage examples. It is complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining both parameters (network and response_format) in plain language, provides defaults, and includes example usage. This goes beyond the schema's minimal descriptions, especially for the response_format parameter which is given context.

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 gets the current gas price in wei, specifically for legacy (non-EIP-1559) transactions. It distinguishes from siblings like eth_getFeeHistory, which likely handles EIP-1559, and the sibling list includes many eth_get* functions with different purposes.

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 for legacy transactions via the phrase 'for legacy (non-EIP-1559) transactions', providing context on when to use. However, it lacks explicit guidance on alternatives like eth_getFeeHistory for EIP-1559 or when not to use. The examples show how to call with different networks, which aids usage.

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

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

With no annotations, the description fully carries the burden of behavioral disclosure. It explains that logs are queried with filters, pagination is supported, return format includes logs and pagination metadata, and lists possible errors. It does not explicitly state that the operation is read-only, but that is implicit. Overall, it provides sufficient transparency for an agent.

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 with separate sections for Args, Returns, Examples, and Errors. The first sentence succinctly states the core purpose. While the description is lengthy, every section adds value and there is no redundancy. It is appropriately detailed for the tool's complexity.

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 (8 parameters, pagination, error handling) and the absence of an output schema, the description is remarkably complete. It covers all parameters, return format including pagination metadata, error conditions, and provides multiple examples. No significant gaps remain.

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 has 100% coverage and the description adds substantial context beyond it. For example, it explains that fromBlock and toBlock accept hex or tags like 'latest', that topics are 32-byte filters, that network defaults to 'mainnet', and provides concrete examples for each parameter. This greatly aids correct parameter usage.

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 purpose: querying event logs from smart contracts with flexible filters. It explicitly includes support for pagination, which distinguishes it from other Ethereum tools that do not return logs, such as eth_call or eth_getTransactionByHash. The description is precise and action-oriented.

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 clear usage guidelines through examples and parameter explanations, including pagination for large result sets and filtering by address or topics. However, it does not explicitly contrast with sibling tools or state when not to use this tool. The information is present but could be more directive.

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

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

With no annotations provided, the description carries the behavioral clarity burden. It describes the return format (hex-encoded string) and possible errors (InternalError). However, it does not mention rate limits or authentication needs, though for a read-only call this is acceptable. No contradictions.

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 with clear sections (Args, Returns, Examples, Errors) and uses concise language. Every sentence adds value without redundancy. It is front-loaded with the core purpose.

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

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

For a simple read-only tool, the description covers the main use case, but it does not mention that it's a standard Ethereum JSON-RPC method or provide context about when the protocol version might differ from chain ID. Missing explanation of the 'response_format' parameter reduces completeness.

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?

Although the input schema covers both parameters (100% coverage), the description only discusses the 'network' parameter with examples and default. It completely omits the 'response_format' parameter, which is documented in the schema but not in the description. This leaves a gap for an AI to understand output options.

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 current Ethereum protocol version, specifying the resource and action. It also explains its usefulness for checking client compatibility and supported features, distinguishing it from sibling tools.

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

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

The description provides a general use case (checking compatibility) but does not explicitly guide when to use this tool versus alternatives, nor does it mention when not to use it. The examples help but lack comparative 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?

No annotations, so description carries full burden. It correctly identifies the read-only behavior and lists error types. However, it does not mention rate limits, authentication, or what happens if the slot does not exist.

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?

Well-structured with clear sections (Args, Returns, Examples, Errors). Each part is purposeful and not overly verbose. Could be slightly more concise but highly effective.

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 tool purpose, parameters, return format, errors, and examples. Missing mention of how to compute storage slots for complex data structures (mappings), but reasonably complete for a read-only storage tool with 4 parameters.

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%, but description adds context: hex formats, examples, and return description. The response_format parameter is not mentioned in the description, but the schema covers it. Overall, description adds enough value beyond 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 the tool reads raw values from a contract storage slot, using specific verbs and resource. It distinguishes from siblings like eth_getBalance (balance) or eth_call (execution).

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 for reading storage but provides no explicit when-to-use or alternatives. Missing guidance on when not to use it compared to eth_call or eth_getStorageAt for mapping slots.

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

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

With no annotations, the description carries full burden. It mentions returns null if not found, lists possible errors, and notes that network defaults to mainnet. Missing details on rate limits, authentication, or destructive actions, but adequate for a read-only lookup 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?

Well-organized with sections for args, returns, examples, errors. Could be slightly more concise, but every sentence adds value. Front-loaded with the core purpose.

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

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

Given 4 parameters and no output schema, the description covers input format, defaults, return structure, null case, error conditions, and provides two examples. No obvious gaps for this straightforward lookup 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 baseline 3. The description adds format details (66 chars, 0x prefix) and default value for network, but fails to mention the response_format parameter present in the schema. Partial added value offset by omission.

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 a transaction by its position in a block identified by hash. It distinguishes from sibling tools like eth_getTransactionByHash and eth_getTransactionByBlockNumberAndIndex, which use different lookup methods.

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 examples and explains the required input structure. Does not explicitly state when not to use or compare to alternatives, but the context and sibling list imply differentiation. Good practical guidance via examples.

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?

No annotations are provided, so the description carries the full burden. It discloses return values (transaction object or null), lists possible errors, and provides examples. However, it does not explicitly state the operation is read-only or safe, which would be helpful.

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 with clear sections (main description, args, returns, examples, errors). Every sentence is useful and the information is front-loaded.

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

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

Given no output schema, the description fully explains return values and errors. Schema coverage is 100% and examples cover typical use cases, making the tool complete for an agent to use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining blockNumber as hex or tag, transactionIndex as zero-based hex, and providing examples. This goes beyond the schema 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 retrieves a transaction by its position within a specific block using block number and index, distinguishing it from siblings like eth_getTransactionByHash or eth_getTransactionByBlockHashAndIndex.

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 includes examples showing when to use it (with block number or tag) but does not explicitly state when not to use it or provide alternatives. The sibling list implies alternatives, but explicit guidance is missing.

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

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

With no annotations, the description covers return value (transaction object or null), pending/not found behavior, and error conditions (InvalidParams, InternalError). It does not mention rate limits or authentication, but for a read-only query this is acceptable.

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 with Args, Returns, Examples, Errors sections. It is concise but includes necessary details; no extraneous content. Could be slightly tighter by integrating the missing response_format param.

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

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

Despite no output schema, the description fully explains the return object fields, null case, and error scenarios. It is complete for a query tool of this complexity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds format details for transactionHash and network default, but omits describing the 'response_format' parameter present in the schema, which slightly reduces added 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 'Retrieves detailed transaction information using its unique transaction hash', specifying the verb and resource. It distinguishes from sibling tools like eth_getTransactionByBlockHashAndIndex by focusing on hash lookup.

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 have a transaction hash) and provides examples, but does not explicitly state when not to use it or mention alternatives. It could be improved by noting that for other lookup methods, use sibling 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?

No annotations are provided, so the description must fully disclose behavior. It details the return value (hex-encoded integer), lists possible errors, and implies a read-only operation. Additional context like rate limits or authentication is absent but not critical for this simple query.

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 with clear sections (Args, Returns, Examples, Errors). It is concise with no redundant information, and each part serves a clear purpose.

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

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

Given no output schema, the description adequately explains the return format and error conditions. It covers three of four parameters in detail. The missing response_format parameter is a minor gap, but overall completeness is high for this tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value for address, tag, and network parameters with explanations and examples, but misses the response_format parameter present in the schema. The added examples and defaults justify a score of 3.

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

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

The description clearly states it returns the number of transactions from an address (nonce) and explains its use for next nonce determination. This is distinct from sibling tools like eth_getBalance or eth_getBlockByNumber, which serve different purposes.

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 examples and states the tool is for getting nonce values. While it doesn't explicitly say when not to use it, the context of sibling tools and the clear purpose make usage guidance adequate.

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

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

With no annotations, the description fully discloses behavior: returns null for pending/not found transactions, lists error types (InvalidParams, InternalError), and details the return object structure.

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 with sections (Args, Returns, Examples, Errors) and front-loaded with a clear purpose. It is slightly long but every section serves a purpose.

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

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

Despite no output schema, the description fully explains the return object and null case. It covers errors and provides examples, making it complete for a receipt retrieval 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 baseline is 3. The description adds value by providing format examples for transactionHash (hex) and default for network, though it omits the response_format parameter. Overall, it enhances understanding.

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 retrieves a mined transaction's receipt with status, gas used, and logs. It distinguishes itself from sibling tools like eth_getTransactionByHash by focusing on the receipt of a mined transaction.

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 specifies that the tool is only for transactions already in a block, and provides examples like checking transaction success. It does not explicitly exclude other contexts, but the usage is 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?

No annotations are provided, so the description carries full burden. It discloses returns null if not found, lists error types (InvalidParams, InternalError), and explains uncles are ommers. It could mention the read-only nature explicitly, but overall good 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 well-structured with clear sections (Args, Returns, Examples, Errors). It is concise with no redundant sentences, and every sentence adds value.

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 4 parameters, no output schema, the description fully explains the return object fields, null case, optional network parameter, and error conditions. It is complete for the tool's complexity.

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%, but the description adds value by clarifying the hex format for the index parameter with an example and providing a usage example. It enhances 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?

The description clearly states the tool retrieves an uncle block by block hash and uncle index, specifying the resource (uncle block) and action (retrieves). It distinguishes from siblings like eth_getUncleByBlockNumberAndIndex by using different indexing.

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

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

The description explains when to use the tool (to get uncles) and provides parameter details, but does not explicitly state when not to use it or compare with alternatives. Sibling tools provide context, but the description lacks explicit exclusions.

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

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

No annotations, but description explains return value (null if not found), errors (InvalidParams, InternalError). Lacks readOnly disclosure but is inherently 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?

Well-organized with sections (Args, Returns, Examples, Errors), succinct sentences, no wasted words.

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?

Fully covers parameters, return object fields, and error cases. No gaps given the tool's simplicity and lack of output 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?

Adds significant value beyond schema: explains hex format, tag shortcuts, index zero-based meaning, and provides concrete examples.

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 an uncle block by block number and index, distinguishing it from sibling tools like eth_getUncleByBlockHashAndIndex.

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 examples and implies usage context, but doesn't explicitly state when not to use or compare to alternatives. Still clear enough for an agent.

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

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

No annotations are provided, so the description carries the full burden. It explains the return format (hex-encoded integer), lists example outputs, and describes possible errors (InvalidParams, InternalError). However, it does not disclose rate limits, authentication requirements, or potential side effects.

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 with clear sections: Args, Returns, Examples, Errors. It is front-loaded with the core purpose and uses minimal but sufficient text. Every sentence provides essential information.

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

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

Given the moderate complexity of the tool and no output schema, the description fully explains inputs, outputs (including format and examples), and error cases. An agent can correctly invoke the tool based on this description alone.

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

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

Schema coverage is 100%. The description adds context to blockHash (example format '0xabc...') and network (defaults to 'mainnet', examples like 'sepolia'). For response_format, it clarifies the difference between 'json' and 'markdown' beyond the enum. This adds meaningful 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 'Returns the number of uncle (ommer) blocks in a specific block identified by its hash.' It specifies the verb 'returns', the resource 'uncle count', and the required input 'block hash'. It is distinct from siblings like eth_getUncleByBlockHashAndIndex and eth_getUncleCountByBlockNumber.

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 alternatives such as eth_getUncleCountByBlockNumber or eth_getUncleByBlockHashAndIndex. It does not mention when not to use it or any prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It transparently describes the return format (hex integer), provides examples, and lists possible errors. It does not mention any side effects or authentication needs, but for a read-only query tool, it is adequately transparent.

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 with sections for Args, Returns, Examples, and Errors. It is moderately concise; each section earns its place. A slight reduction in examples could improve conciseness, but overall it is well-organized.

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, the description covers purpose, parameters, return values, and errors. No output schema exists, but the description sufficiently explains the return format. It is complete for an agent to use correctly.

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

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

Schema coverage is 100%, providing a baseline of 3. The description adds meaning for 'blockNumber' (hex or tag) and 'network' (examples), but it omits the 'response_format' parameter entirely, which is included in the schema. Thus, it adds some value but not complete 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 'Returns the number of uncle (ommer) blocks in a specific block identified by its number or tag.' It provides a specific verb and resource, and the sibling tools show a distinct variant for block hash, ensuring no confusion.

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 includes args, defaults, examples, and errors, clearly indicating when to use this tool (e.g., for uncle count by block number/tag). However, it does not explicitly state when not to use it or mention alternative tools like eth_getUncleCountByBlockHash, though the context is sufficient.

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?

No annotations provided, so description carries full burden. It describes return values in detail (false when not syncing, object with hex-encoded fields when syncing) and mentions errors. It does not discuss destructive behavior or auth needs, but those are not relevant here.

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

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

The description is well-structured with clear sections: description, Args, Returns, Examples, Errors. It is concise with no wasted words, and each sentence adds value.

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 is simple with no output schema. The description explains returns and errors. Missing mention of 'response_format' parameter slightly reduces completeness, as it could help agents understand output formatting options. Otherwise solid.

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%, but the description only documents the 'network' parameter in Args and omits 'response_format' entirely. While the schema fully covers both, the description fails to add value for the missing parameter and does not explain output format control.

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 returns the sync status of an Ethereum node, using specific verb 'Returns' and resource 'sync status'. It distinguishes from siblings by focusing on sync status, which is unique among the listed eth_ functions.

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 mentions when to use: 'useful for determining if the node is fully synced before relying on its data.' It does not provide explicit exclusions or alternatives, but the context makes it clear this is the only sync-checking tool.

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

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

No annotations are provided, so the description bears full responsibility. It discloses return format (hex-encoded integer), default network, error cases (InternalError), and usage examples. However, it does not explicitly state read-only or non-destructive nature, but context implies it.

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

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

The description is concisely structured into clear sections (purpose, args, returns, examples, errors). Each sentence is informative and earns its place, with no redundancy.

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

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

For a simple tool with no output schema, the description covers return format, parameter details, examples, and errors. It is sufficiently complete for an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100% (baseline 3). The description adds value for the 'network' parameter via examples and default, but does not mention the 'response_format' parameter, which is only defined in the schema. Thus, it partially adds meaning but misses one parameter.

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

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

The description clearly states it returns the number of connected peers, with a verb 'returns' and specific resource. It differentiates itself from sibling tools like net_getVersion and net_isListening by focusing on peer count, a distinct metric.

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 does not provide explicit guidance on when to use this tool versus alternatives. It only states it's useful for monitoring connectivity, but lacks comparison or exclusion criteria.

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

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

No annotations provided. Description discloses error conditions (InternalError when Infura API unavailable), default behavior (defaults to mainnet), and return format (string). Lacks info on rate limits or idempotency, but is fairly transparent.

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?

Description is well-structured with clear sections (Args, Returns, Examples, Errors). No unnecessary words, front-loaded with purpose. 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 2 parameters and no output schema, description explains return value (string with examples) and errors. Missing explanation of response_format parameter. Overall fairly complete but could cover response_format and differentiate from sibling tools.

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%, baseline 3. Description adds examples and default for the 'network' parameter but neglects to mention 'response_format' parameter or its enum values. Schema already documents both parameters, so description adds 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 clearly states it returns the current network ID and explains its purpose (identifying Ethereum network). Includes examples with mainnet and Sepolia, and mentions network IDs. No tautology.

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

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

Description mentions it's useful for identifying which Ethereum network, but does not explicitly differentiate from sibling tools like eth_chainId or provide when-not-to-use guidance. However, it includes error handling context and examples.

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

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

With no annotations, the description carries full burden. It explains the boolean return, lists an error case (InternalError), and provides examples of network usage. It does not disclose any side effects or rate limits, but for a simple read-only 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 concise and well-structured, with a clear purpose followed by Args, Returns, Examples, and Errors sections. Every sentence provides value, and there is no redundancy or 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 simple tool with no output schema and minimal parameters, the description fully covers behavior, parameters, examples, and an error case. It is complete for an agent to select and invoke the tool correctly.

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

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

The schema has 100% coverage, so baseline is 3. The description adds examples and default for 'network' but omits the 'response_format' parameter from its Args section. It does not go beyond the schema in meaning for that parameter, so it meets the baseline.

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

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

The description clearly states the tool returns whether the client is listening for network connections, with a specific verb and resource. It distinguishes itself from sibling tools like net_getPeerCount and eth_isSyncing by focusing on connectivity status.

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 indicates it is 'useful for checking node connectivity status,' providing clear context. However, it does not explicitly state when not to use it or mention alternatives like net_getPeerCount, which limits 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?

No annotations provided, so description carries full burden. It describes the return type with an example and notes potential InternalError from Infura unavailability. However, it does not explicitly state read-only nature or other behavioral details like rate limits.

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

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

The description is well-structured with clear sections (Args, Returns, Examples, Errors), front-loaded with the main purpose. Every sentence adds value, and it is appropriately sized for the tool's simplicity.

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 tool with no output schema and no annotations, the description is complete: it explains return value, provides examples, covers errors, and lists parameters. It sufficiently enables an agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds an Args section for 'network' but does not mention 'response_format' parameter beyond schema. The Returns and Errors sections provide context, but parameter information is not enhanced beyond 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 it returns the current Ethereum client version string, specifying its purpose of identifying node software and version. This is distinct from sibling tools that focus on chain data, block info, or network stats.

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 by stating its usefulness for identifying node software, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned, though the purpose alone suggests it's for client version queries.

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