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

Annotations declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds the nuance that this also tells you whether the address is a contract by checking code presence, and implies this is a lightweight read. It doesn't mention gas costs or that contract account code may change, but it's adequate given the annotations already communicate 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 consists of only two sentences that pack significant meaning: the first lists the returned fields, the second explains the EOA/contract distinction. 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?

Given the low complexity (3 flat params, no output schema needed for a simple read), the description adequately covers the tool's purpose. It could benefit from a brief note on the output shape, but since no output schema is required and params are well-documented, this is nearly complete.

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

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

Schema coverage is 100% and the schema describes each parameter (block, address, network) with defaults. The description doesn't need to add param semantics since the schema is complete and precise. 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 returns balance, nonce, and code presence for an address, and explains how to distinguish EOA from contracts. It uses specific nouns (balance, nonce, code) beyond the tool name. It doesn't explicitly distinguish from siblings like read_transaction or call_contract, but the resource and outputs are specific enough to guess.

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 account-level queries and provides a decision rule for EOA vs contract. However, it doesn't explicitly state when NOT to use it or name alternative tools, though the 'code presence' explanation hints at contract inspection. Sibling names like chain_info and read_contract are present, so some cross-referencing guidance would improve it.

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

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

Beyond the annotations (readOnlyHint, destructiveHint false), the description adds transparency about the internal process: keccak256 selector calculation, ABI encoding, and decoding of return values. It clarifies the read-only nature and no-gas behavior, which is consistent with annotations.

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

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

The description is concise (two sentences) and front-loaded with the main action. It conveys the necessary information without redundancy, making it well-structured and 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?

The description covers the essential aspects: purpose, process, and outcome. It lacks explicit mention of error handling or return value details, but given the schema richness and simplicity of the tool, it is sufficiently complete for a typical use case.

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 provides full coverage of all parameters with descriptions. The description adds context to the overall flow but does not provide additional per-parameter semantics beyond what is in the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: calling view/pure functions via eth_call, with explicit mention of selector computation and ABI encoding. It is distinct from sibling tools that read transactions, blocks, or tokens.

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 read-only queries ('view/pure', 'no state change, no gas') but does not explicitly contrast with alternatives or state when to prefer this tool over others. Guidance is implicit rather than explicit.

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

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

注解已声明 readOnlyHint=true、destructiveHint=false、openWorldHint=true，安全属性覆盖充分。描述未披露额外行为（如缓存、速率限制），但也没有矛盾。由于注解已负担安全上下文，描述未添加更多行为信息，因此评为中等。

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?

描述为一句紧凑的日文句子，信息完整，无冗余。开头即点出返回内容，后接使用场景，效率极高。

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?

工具参数少且简单，注解已涵盖安全性，描述充分覆盖目的和返回值，虽无输出 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?

参数 network 的 schema 覆盖率为100%，描述仅复述了 schema 中的默认值和可选值，没有新增语义。按规则高覆盖率时基线为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?

描述明确“返回链 ID、最新区块、基本费用和拥堵程度”，并指明这是“查看网络当前状态的初始工具”。动词“返回”与资源“链信息”明确，与兄弟工具（如 read_block、account_info）区分清晰。

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?

描述提到“第一次查看网络状态”，暗示了适用场景，但没有明确说明何时不使用，也未指出替代工具。缺乏明确的“当……时使用”或“而非……”的排除条件，指南尚可但不够完整。

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the important behavioral fact that it never accesses the network — information not present in annotations. It also clarifies it's a pure computation tool for educational use. No contradictions with annotations.

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

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

Two concise sentences: the first states the core function and outputs, the second adds the no-network constraint and purpose. Every sentence earns its place with no redundancy or filler.

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

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

For a simple one-parameter tool with strong annotations and no output schema, the description is complete. It explains what the tool does, what it outputs (selector/topic0), that it's offline, and its educational purpose. There is no ambiguity about usage or behavior.

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

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

Schema description coverage is 100% (the single parameter 'signature' includes examples for both function and event signatures). The description adds no further parameter-level detail beyond what's already in the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states it calculates keccak256 for function/event signatures and shows the selector (first 4 bytes) or topic0. It names the specific resource (signatures) and the action (calculate/show), making it distinct from sibling tools that are all network-dependent.

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 'no network access at all', which clearly distinguishes it from the network-heavy sibling tools. It also states its purpose ('to explain where ABI comes from on a whiteboard'), giving context. However, it doesn't explicitly name alternative tools or say 'use this when you need offline computation', so it's short of a 5.

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

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

readOnlyHint=trueとdestructiveHint=falseのアノテーションと整合し、説明では「署名も送信もしない」と明記。さらに「LLMに鍵を渡さないという境界」という重要な設計意図が追加されており、単に安全操作であるだけでなく、その目的まで伝わる。これはアノテーション以上の価値を提供している。

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?

2文で構成され、最初の文でツールの機能を明確に述べ、2文目で重要な注意点と目的を説明している。冗長な情報は一切なく、必要な情報が効率的に配置されている。

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?

出力スキーマがないため、返り値の詳細は説明されていないが、説明に「人間がMetaMaskやハードウェアウォレットで内容を確認してから署名するためのJSON」とあり、利用目的が明確で出力の概要は伝わる。パラメータも6つで複雑さは中程度であり、説明が十分に補完している。ただし、完全な出力形式の例があればさらに良かった。

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?

パラメータのスキーマ説明は100%網羅されているが、説明はそれを超える情報を加えている。特に「from」アドレスがnonceとガス見積もりにのみ使用され鍵が不要、という重要なセマンティクスが説明文に含まれており、スキーマだけでは得られない情報がある。さらに「value_eth」の既定値や「network」の既定値などもスキーマにない補足がある（ただしスキーマにも既定値はある）。

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?

説明には具体的な動詞（組み立てて返す）、具体的なリソース（EIP-1559形式のトランザクション）、そして結果が人間の確認用JSONであることが明記されている。さらに送信/署名しないと明確な境界が述べられており、read系の兄弟ツールとの差別化にもつながっている。

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?

「署名も送信もしない」という明示的な使用制限があり、返り値が人間の確認用であると書かれている。ただし、いつ使うべきかに関する明確な指示や、代わりに使うべきツール（例: 署名が必要な場合は別のツール）への言及はない。

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. Description adds behavior: returns header info and optionally first 50 transaction hashes (if include_transactions=true). Still, lacks details on error cases, network handling, or whether latest is resolved dynamically. Given read-only annotation, this is acceptable 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?

Single sentence, efficient and front-loaded with the core information. No fluff. Would be 5 if it included a usage guideline, but given its simplicity, it's near-optimal.

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?

Tool is simple (3 optional params, read-only, no output schema). Description covers purpose and optional behavior (50-transaction limit). Could mention that network accepts URL, but that's in schema. With good annotations and full schema coverage, it's sufficiently complete for its 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 covers 100% of parameters with descriptions. Description adds nothing beyond param names. It mentions '先頭 50 件' in include_transactions description, so schema already explains behavior. Baseline 3 is correct; the description does not need extra param info since schema is complete.

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: reads block header info and specifies exact fields (parent hash, time, gas used, transaction count). Differentiates from siblings like read_transaction, account_info, and call_contract by focusing on block-level data. Even without title/name details, the verb '返す' plus resource 'ブロックのヘッダ情報' makes 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?

No explicit when-to-use or alternatives mentioned. The description implies usage for block header queries, but doesn't exclude cases like needing full transactions (which could be handled by read_transaction) or chain info (chain_info). Basic context given, but no guidance on choosing this over other 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?

The annotations already indicate read-only, open-world, and non-destructive behavior. The description adds valuable context about how events are decoded (topic0, indexed arguments) and its typical use case in dApp UIs, going beyond the annotation basics without contradicting them.

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, consisting of three short sentences that convey the core functionality, technical detail, and typical usage. No redundancy or unnecessary elaboration.

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 an output schema, the description sufficiently explains what the tool does and its technical underpinnings. It covers the purpose, the event topic mechanism, and a real-world use case, providing enough context for a user to understand its role. It does not describe return format, but that is not required without an 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 input schema provides comprehensive descriptions for all parameters (coverage 100%). The tool description does not add parameter-specific meaning; it only gives general context about the event decoding process. 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 tool's function: retrieving and decoding contract events. It also explains the topic structure, making the purpose precise and distinct from sibling tools like read_transaction or read_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 implies usage by mentioning dApp UI subscriptions and the technical topic mechanism, but it does not explicitly compare to alternatives or state when to prefer this tool over others. However, the distinct purpose and sibling names make the appropriate context 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?

The annotations already declare this as a read-only, non-destructive operation. The description adds behavioral context by explaining what the tool returns for different parameters, which is beyond the annotations. No contradiction with annotations.

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

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

The description is two concise sentences, front-loaded with the core function, then optional behavior. No redundant information, perfectly efficient.

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 complexity of handling multiple token standards and optional params, the description provides adequate coverage of functionality. It doesn't describe the exact output format, but since no output schema exists, it partially compensates by listing what data is read. Minor gaps remain about error handling, but overall it is sufficient for a read tool.

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

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

The schema covers all parameters with descriptions, but the tool description adds semantics by explaining how holder and token_id affect the output (balance vs. NFT owner/URI). It also clarifies the network default, exceeding the schema's basic param 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 reads token metadata (name, symbol, decimals, total supply) and optionally balance or NFT owner/URI. It uses specific verbs ('read', 'identify') and a clear resource (token), distinguishing it from siblings like account_info or call_contract.

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 optional parameters (holder for balance, token_id for NFT details), giving clear context for usage. However, it does not explicitly compare to alternatives or state when not to use, so it lacks exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds that it cross-references the receipt and returns human-readable fields, which is useful but doesn't detail any constraints like requirements for the network parameter or handling of pending transactions. With annotations providing the safety profile, a score of 3 is appropriate.

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 two sentences that pack substantial information about what the tool returns and its analogy to Etherscan. It is front-loaded with the main verb and resource, and every sentence contributes value. 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?

Given the tool's moderate complexity, the description covers the key outputs and the analogy to Etherscan. With no output schema, the description should clarify return values, and it does list the fields. However, it does not mention edge cases like pending transactions or error conditions, but for a read-only tool with good annotations, this is acceptable. A score of 3 reflects that it is adequate but not exhaustive.

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

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

Schema description coverage is 100%, so the schema already explains both parameters (hash and network). The description mentions 'network' implicitly through 'Etherscan' context but adds no extra syntax or format details beyond the schema. Baseline 3 is correct when the schema fully covers 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 the tool's purpose: to read a transaction and its receipt, returning sender, destination, amount, gas, actual fee, success/failure, and calldata function selector in human-readable form. It distinguishes from siblings by focusing on transaction-level details, though it doesn't explicitly name alternatives.

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

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

The description implies the tool is for reading transaction details, similar to viewing Etherscan, but does not explicitly state when to use it versus alternatives like read_block or call_contract. It mentions it reads both transaction and receipt, providing some context, but no exclusions or alternative tool names.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral context by explaining that the tool checks both calldata and event logs, and that the result includes an explicit statement of what can and cannot be proven. This is valuable beyond the annotations.

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

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

The description is two sentences, front-loaded with the action, and ends with a note about the output's epistemic caveat. Every sentence earns its place with no redundancy or filler.

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

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

For a tool with no output schema, the description gives a reasonable sense of the output by mentioning the proof-limitation note. It does not explicitly clarify that only one of text/file_path/expected_hash should be provided, nor does it describe the return structure in detail, but the core behavior is well covered.

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

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

Schema coverage is 100%, so the schema already documents all five parameters. The description mentions file/text as input options but does not elaborate on the relationship between file_path, text, and expected_hash, nor does it add format details. It meets the baseline but does not add significant parameter meaning.

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 core action: compute the keccak256 of a local file/text and verify whether that value appears in a given transaction's calldata or event logs. It also specifies the purpose as existence proof and timestamp verification, which distinguishes it from the sibling read/query 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 implies usage context: it is for verifying that a file's hash is anchored on-chain, useful for existence proofs and timestamp verification. However, it does not explicitly mention alternatives or state when not to use this tool, so it stops short of a 5.

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