Tenzro Ethereum MCP

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

Describes the call as read-only and returns raw hex result. No annotations provided, so description carries full burden. It does not cover error behavior, gas implications, or edge cases. The presence of an output schema helps, but description adds minimal behavioral context.

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

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

Two sentences, zero fluff. Front-loaded with purpose, then enumerates parameters, return type, and a helpful sibling reference. 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?

Given the tool has 3 parameters, an output schema, and no nested objects, the description covers the main points: purpose, parameters, return type, and a hint for calldata construction. It could mention error handling or limitations, but overall it is sufficiently complete for a simple read-only call.

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

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

Schema coverage is 100%, so baseline is 3. The description rephrases parameters and adds default for block, slightly beyond schema. It also references eth_encode_function for building calldata, indirectly clarifying the 'data' parameter's purpose. This extra value justifies 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?

Clearly states it executes a read-only eth_call against a smart contract. The verb 'execute' and resource 'smart contract' are specific. It distinguishes from siblings by referencing eth_encode_function as a helper, implying this tool executes calls rather than encoding.

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 'read-only eth_call', indicating when to use. It also directs users to eth_encode_function for building calldata. However, it does not explicitly state when not to use (e.g., for state-changing calls use eth_send_raw_transaction).

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 discloses the encoding steps: Keccak-256 hash, left-padding to 32 bytes, hex output. It lacks error handling details but is sufficient for a simple encoding 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 concise with only 3 sentences, front-loading the core purpose. The example adds clarity without 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 presence of an output schema (not shown but indicated), the description is complete. It covers the encoding purpose and output format, and the sibling context makes the tool's role clear.

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

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

Schema coverage is 100% with descriptions for both parameters. The tool description adds value by explaining the padding behavior and providing a concrete example, enhancing 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 encodes a function call using ABI encoding, explains the process (Keccak-256 selector, left-padding), and distinguishes from siblings by specifying its output as calldata ready for eth_call or transactions.

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 the output is for eth_call or transactions, and provides an example. However, it does not explicitly compare to siblings or provide when-not-to-use scenarios.

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 bears full burden. Only states return format ('decimal and hex'), but omits behavioral traits such as estimate basis (recent blocks), potential failure conditions, rate limits, or side effects. Lacks disclosure of important execution details.

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?

Extremely concise: two sentences with no redundancy. Front-loads the purpose, then lists parameters and return format efficiently. Every word 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 moderate complexity, no annotations, and an existing output schema, the description is adequate but minimal. It covers purpose, params, and return type, but lacks usage scenarios, error handling, or interpretation details. Adequate for a basic tool, but leaves gaps for an AI agent to infer.

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 covers all 4 parameters with full descriptions. The description merely summarizes the list (to required, others optional) without adding new meaning or constraints. With 100% schema coverage, baseline is 3; no additional semantic value provided.

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 the tool estimates gas required for a transaction, naming the RPC method (eth_estimateGas). The verb 'estimate' and resource 'gas required for a transaction' are specific and unambiguous. Distinguishes well from siblings like eth_get_gas_price (current price) and eth_call_contract (simulate 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?

Lists parameters (required vs optional) but provides no explicit guidance on when to use this tool versus alternatives. Usage context is implied by the tool's purpose, but no 'when not to use' or comparative advice against siblings is 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?

No annotations are provided, so the description carries full burden. It discloses that the tool posts a GraphQL query to an external indexer (easscan.org) and lists the returned fields (attester, recipient, schema, data, timestamp, revocation status, decoded data when available). This provides good behavioral context beyond a simple 'returns data'.

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 concise sentences that front-load the purpose and key details. No unnecessary words; 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 1 simple parameter, an output schema exists (though not provided in input), and the description lists return fields. The context is sufficient for an agent to understand what the tool does and what it returns.

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

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

The only parameter (uid) has a complete schema description (hex bytes32). The tool description does not add additional 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 clearly states the verb 'Query' and the resource 'attestation from Ethereum Attestation Service (EAS) by UID'. It is specific and distinct from sibling tools like eth_get_transaction or eth_call_contract, though it does not explicitly differentiate itself.

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

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

No guidance on when to use this tool versus alternatives. It mentions a GraphQL query to easscan.org but does not provide context for selection, prerequisites, or exclusions.

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

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

Annotations are absent, so the description carries full burden. It discloses that the tool returns balance in multiple units, but does not mention that it is a read-only operation, requires no special permissions, or any rate limits. No destructive behavior is implied, but the description does not explicitly confirm safety.

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 concise sentences, front-loading the primary purpose and output format. Every word adds value 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?

Given low parameter count, high schema coverage, and presence of an output schema, the description is adequate. It could mention default block behavior or error scenarios, but these are covered in the schema. Sibling tools are distinct enough that no further disambiguation is needed.

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 parameters documented. The description adds no extra detail about parameters themselves; it only discusses output format. 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 the action ('Get') and resource ('ETH balance of an address'), and specifies the return units (wei, Gwei, ETH). It effectively distinguishes from siblings like eth_get_token_balance (ERC-20) and eth_get_price (token 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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. Sibling tools exist for token balances (eth_get_token_balance) and prices (eth_get_price), but no comparisons are made.

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 burden. It states the return includes block header, transactions, and metadata, implying it is read-only, but does not explicitly disclose safety or 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?

Two concise sentences with no fluff. Front-loaded with purpose and parameters.

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

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

The description covers the essential purpose and parameters. With no output schema provided and a large set of siblings, it could include more detail on return structure or error handling, but it is adequate for a simple get block 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% with both parameters described in the schema. The description summarizes the parameters but adds no new 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 clearly states 'Get block by number' with specific verb and resource. It distinguishes from siblings like eth_get_transaction and eth_get_balance by focusing on block 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?

No explicit when-to-use or alternatives are given. The description implies usage for block data but does not differentiate from siblings like eth_get_balance or provide guidance on 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?

No annotations are provided, so the description carries the full burden. It discloses the return values (base fees, gas used ratios, reward percentiles) and mentions the underlying method (eth_feeHistory). However, it does not mention any potential constraints like rate limits, pagination, or error conditions. For a standard read-only RPC, this is adequate but not rich.

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 with no filler. It front-loads the purpose and then details the return values. Every sentence is informative and necessary.

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

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

Given that an output schema exists and the schema covers all parameters, the description is largely complete. It explains the purpose and return values, though it could mention the default block count or the fact that newest_block defaults to 'latest' (already in schema). The absence of annotations is compensated by the standard nature of the tool.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by linking the parameters to the use case: 'Returns ... reward percentiles for EIP-1559 gas estimation,' which clarifies the purpose of the reward_percentiles parameter. This extra context 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's purpose: 'Get fee history for recent blocks via eth_feeHistory.' It specifies the resource (fee history) and the verb (Get), and explains what it returns (base fees, gas used ratios, reward percentiles). This distinguishes it from sibling tools like eth_get_gas_price, which returns a single 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 EIP-1559 gas estimation but does not explicitly state when to use this tool versus alternatives like eth_get_gas_price or eth_estimate_gas. No when-not or alternative guidance is provided, leaving the agent to infer context from the 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?

The description discloses the return format and the underlying JSON-RPC method, which is adequate for a simple read operation. However, with no annotations provided, the description does not cover potential side effects, rate limits, or caching behavior.

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

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

Two sentences, no redundancy. The key verb 'Get' is front-loaded, and all information is relevant and compact.

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 fully covers the tool's purpose and output for a parameterless read operation. An output schema exists but is not needed given the description's clarity.

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

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

There are no parameters, so the description adds value by explaining the return values across multiple units. The lack of parameters makes this straightforward.

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 the current gas price, specifying the JSON-RPC method and the units returned (wei, Gwei, hex). This differentiates it from sibling tools like eth_get_fee_history or eth_get_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?

No guidance on when to use this tool versus alternatives, nor any conditions or prerequisites mentioned. The description is minimal and lacks usage 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?

No annotations provided, so description carries full burden. It discloses the call to latestRoundData(), return fields (price, round ID, timestamps), and default feed. While it does not mention auth or rate limits, for a read-only eth call this is acceptable. The description is honest and provides key behavioral traits.

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 covering action, method, defaults, and return format. No filler or redundancy. Every sentence 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?

With an output schema present, the description's mention of price precision, round ID, and timestamps suffices. The tool is simple (one purpose, two optional params) and the description covers all 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 coverage is 100% with both parameters described. The description adds value beyond schema by explaining default feed (ETH/USD mainnet), default chain_id behavior, and the 8-decimal precision. This enriches the agent's understanding beyond the schema's brief explanations.

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 token price from a Chainlink AggregatorV3Interface data feed', specifying the verb (get), resource (token price), and underlying method (eth_call to latestRoundData). It distinguishes from sibling tools like eth_get_balance or eth_get_token_balance which deal with different 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?

Description implies usage context by mentioning default feed and return details (price with 8 decimals, round ID, timestamps). However, it does not explicitly state when not to use this tool or suggest alternatives, leaving slight room for ambiguity among the many 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?

Despite no annotations, the description discloses the internal mechanism (eth_call to balanceOf) and the fact that the return is raw balance needing decimal conversion. It implies a read-only operation. 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?

Extremely concise: two sentences with no filler. Front-loaded with the core purpose. 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 the tool's simplicity and presence of output schema, the description adequately covers mechanism, return format, and a key usage caveat (decimals). Could optionally mention error handling, but not necessary.

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 description reiterates parameter roles (token_address and owner_address) which are already well-described in the schema. It adds no new parameter semantics beyond what is in the schema. The return value hint is about behavior, not 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 clearly states it gets an ERC-20 token balance for an address via eth_call. It specifies the resource (ERC-20 token) and action (get balance), distinguishing it from sibling eth_get_balance which retrieves native ETH balance.

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: it is for ERC-20 tokens, via eth_call. It implies when to use (for ERC-20) vs eth_get_balance (native ETH). However, it does not explicitly state alternatives or 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, the description carries the burden. It implies a read-only operation but does not explicitly state safety or side effects. It does list return fields, adding some transparency but not full behavioral context.

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

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

The description is a single sentence with no superfluous information, directly stating purpose and return fields. It is efficiently structured and 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 the tool's simplicity (single parameter) and presence of an output schema, the description provides sufficient context about what the tool does and returns. No gaps for typical 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 the schema itself documents the parameter. The description adds no semantic value beyond restating the hash format, which is already in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action ('Get transaction details by hash') and lists the returned fields, distinguishing it from siblings like eth_get_transaction_receipt or eth_get_block.

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 guidance on when to use this tool versus alternatives (e.g., eth_get_transaction_receipt for receipts). While the purpose is clear, the lack of explicit context for selection misses an opportunity.

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 effectively discloses key behaviors: the status codes (0x0=failure, 0x1=success), gas used, logs, and contract address. It is transparent about the output but omits edge cases like null receipt for pending transactions.

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 sentence that immediately states the purpose and lists key return fields. Every word is informative, and it is front-loaded for quick understanding.

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 (one parameter) and presence of an output schema, the description is complete: it explains what the tool does and what the output contains, covering all necessary context 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 coverage is 100%; the description ('by hash') adds minimal value beyond the schema's description of tx_hash. No additional details on format or constraints are provided.

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 verb 'Get' and the resource 'transaction receipt by hash', distinguishing it from sibling eth_get_transaction which retrieves transaction details. It also specifies the returned fields, making the purpose explicit.

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

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

The description implies usage context but does not explicitly state when to use this tool versus alternatives like eth_get_transaction. It lacks guidance on when not to use it or prerequisites.

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

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

With no annotations, the description discloses that the tool builds calldata for specific functions, indicating no blockchain state change (read-only). It does not mention errors or limitations, but the core behavior is 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 two sentences: the first states the primary action, the second adds technical context. No unnecessary words, 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?

Given the simple input and presence of an output schema, the description explains the purpose and how the output (calldata) is intended to be used with eth_call_contract. It does not detail the output format, but that is presumably covered by the 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?

The schema already describes the parameter. The description adds value by explaining how the parameter maps to on-chain functions (getAgent vs getAgentsByOwner) and accepts both agent ID and owner address, which is not fully captured in the schema 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?

The description clearly states the tool looks up an AI agent in the ERC-8004 Agent Registry by agent ID or owner address, distinguishing it from sibling tools like eth_lookup_ens or eth_register_agent_8004.

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 that the tool builds calldata for use with eth_call_contract, but does not explicitly state when to use this tool versus alternatives like eth_encode_function or when not to use it. No prerequisites or exclusions are mentioned.

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 on-chain mechanism (constructs .addr.reverse domain and calls resolve()) and notes a fallback to OnchainKit ENS API, which is good. However, it does not disclose failure modes, rate limits, gas costs, or what happens when no ENS name is found.

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

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

Two concise sentences that front-load the purpose and provide technical detail. No wasted words; 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?

For a single-parameter tool with a schema description covering 100%, the description covers the method, fallback, and parameter format. It lacks details on error cases or network specificity, but overall is mostly complete given the tool's simplicity and existing 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?

Schema coverage is 100% and the description merely restates the parameter (address as hex) without adding new meaning beyond what the schema already says (e.g., 'hex, with or without 0x prefix' is in both). 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 performs a reverse-lookup of an Ethereum address to its ENS name, using the Universal Resolver on-chain. It specifies the verb and resource, but does not distinguish this from sibling tool eth_resolve_ens (which likely does forward resolution), so no explicit differentiation.

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

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

No guidance on when to use this tool versus alternatives like eth_resolve_ens or other ETH tools. The description does not mention when to choose this over other tools or any prerequisites, leaving the agent without context 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?

With no annotations, the description discloses that the tool builds ABI-encoded data (not executing the transaction) and that the caller must handle signing and submission. This sufficiently covers behavioral traits, though potential error conditions are omitted.

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 concise sentences, front-loaded with the primary purpose and standard, followed by essential details. No superfluous 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?

Given the presence of an output schema (not shown) and the tool's moderate complexity (3 required string params, no nesting), the description adequately covers what the tool does and what the user needs to do (sign and submit).

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds the function signature 'registerAgent(string,string[],string)' which provides context, but does not significantly enhance 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 builds transaction data for registering an AI agent via ERC-8004, specifying the function signature and output. This distinguishes it from siblings like eth_call_contract or eth_send_raw_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 implies usage for agent registration and notes that the caller must sign and submit the transaction, but does not explicitly exclude alternative tools or provide when-not-to-use scenarios. Context 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?

Discloses the resolution method: tries on-chain via eth_call, falls back to OnchainKit API. Mentions specific contract address and function signature, providing good behavioral context beyond what annotations (none) offer.

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?

Concise two-sentence description; front-loaded with the core purpose. Efficient with 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?

For a simple one-parameter tool with an output schema, the description explains the resolution process and fallback. Lacks mention of error cases, but output schema likely covers return values.

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 the single parameter with 100% description coverage. Description repeats parameter name and gives an example, adding marginal 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?

Clearly states it resolves an ENS name to an Ethereum address (specific verb+resource). However, sibling tool eth_lookup_ens exists with similar purpose; no differentiation provided.

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

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

No guidance on when to use this tool versus alternatives like eth_lookup_ens, nor any prerequisites or when-not-to-use scenarios.

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 full burden. It discloses that the tool broadcasts a signed transaction and returns the transaction hash as plain text. It also mentions the requirement for a properly signed transaction and chain_id matching, which provides adequate transparency for a mutation 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 two sentences, front-loaded with the purpose, and each sentence adds necessary information. No redundant words or phrases; it is efficiently structured for quick parsing by an AI 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?

Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers all essential aspects: what the tool does, how to prepare the input, and what the output is. It is fully adequate 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 coverage is 100% (raw_tx described in both schema and description). The description adds value by clarifying that the hex string can have an optional '0x' prefix, and it reiterates the building process, which aids interpretation beyond the schema's static 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?

The description clearly states the action ('broadcast a pre-signed Ethereum transaction') and the specific resource (via eth_sendRawTransaction). It distinguishes from siblings like eth_call_contract (read-only) and eth_estimate_gas (preparation), making the tool's unique role evident.

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 step-by-step workflow for building the raw transaction using eth_encode_function, eth_estimate_gas, and an external signer, indicating when to use this tool. While it doesn't explicitly list when not to use it, the context from sibling tools and the clear preparation steps suffice for most scenarios.

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