Loading ToolBench
Read-only Ethereum MCP server: lets an LLM inspect a chain in natural language, and records where every answer came from.
Strong foundation with 10 well-named, read-only Ethereum tools. All tools have descriptions (avg 180 chars, within baseline 194). Input schemas present with types and descriptions for all parameters. Tool names follow verb_noun pattern (chain_info, account_info, read_transaction, etc.). However, output schemas are not formally documented in the tool registration, responses are described in docstrings but not in structured JSON Schema format. Error handling is present but inconsistent: some tools validate inputs (assertAddress, blockTag) while others lack explicit error guidance. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Parameter descriptions are generally good (avg ~60 chars) but some lack format constraints (e.g., 'signature' param in call_contract and explain_selector could specify format more precisely).
アドレスの残高・送信済みトランザクション数 (nonce)・コードの有無を返す。コードの有無で EOA（秘密鍵で操作するアカウント）とコントラクトを判別する。
任意のコントラクトの view / pure 関数を eth_call で呼ぶ。関数署名から keccak256 でセレクタを計算し、引数を ABI エンコードして送り、戻り値をデコードして返す。状態は変わらず、ガスもかからない。
チェーン ID、最新ブロック、基本手数料 (base fee)、ブロックの混み具合を返す。「いまネットワークはどうなっているか」を最初に見るためのツール。
関数署名やイベント署名から keccak256 を計算し、セレクタ（先頭 4 バイト）や topic0 を示す。ネットワークには一切アクセスしない。ABI がどこから来るのかを黒板で説明するためのツール。
nonce・ガス見積もり・手数料を埋めた EIP-1559 形式のトランザクションを組み立てて返す。【重要】このサーバは署名も送信もしない。返るのは人間が MetaMask やハードウェアウォレットで内容を確認してから署名するための JSON。LLM に鍵を渡さないという境界を、実際に動く形で示すためのツール。
ブロックのヘッダ情報（親ハッシュ、時刻、ガス使用量、収録トランザクション数）を返す。
Output schemas not formally documented. Tool descriptions include return value details in prose (e.g., 'returns chain_id, latest_block, block_time_utc...') but no structured JSON Schema for responses. LLMs cannot reliably parse unstructured output or plan downstream tool calls without explicit response schemas.
Missing tool annotations. All 10 tools are read-only and idempotent, but none declare readOnlyHint or idempotentHint. This prevents clients from optimizing caching, retry logic, and safety checks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
コントラクトが発火したイベントを取得してデコードする。イベント署名の keccak256 が topic0 になり、indexed の引数だけが topic に載る、という仕組みがそのまま見える。dApp の画面更新はこれを購読している。
ERC-20 / ERC-721 / ERC-1155 を判別し、名称・記号・小数桁・総供給量を読む。holder を渡せば残高、token_id を渡せば NFT の所有者と tokenURI も読む。
トランザクションと領収書 (receipt) を突き合わせて、送信者・宛先・送金額・ガス・実際に払った手数料・成否・calldata の関数セレクタを人間が読める形で返す。Etherscan の画面を読むのと同じ作業。
手元のファイル（またはテキスト）の keccak256 を計算し、指定したトランザクションの calldata やイベントログにその値が現れるかを確認する。存在証明とタイムスタンプの検証。結果には「これで何が証明できて、何が証明できないか」を必ず併記する。
Parameter format constraints not formalized. 'signature' param (call_contract, explain_selector) and 'hash' param (read_transaction, verify_anchor) lack regex patterns or enum constraints in schema. Descriptions mention format (e.g., '0x from beginning') but JSON Schema should enforce via pattern field.
Error handling lacks recovery guidance. Input validation (assertAddress, blockTag) throws errors but does not suggest next steps. E.g., 'Invalid address format' should suggest 'Use a 0x-prefixed 40-character hex string' or offer a search_address tool.
prepare_unsigned_transaction lacks confirmation/dry-run pattern. Tool description states 'does not sign or send' but no explicit dry-run or confirmation step. For a tool that prepares transactions (even unsigned), a confirmation pattern prevents accidental misuse.