A
licenseB
qualityD
maintenanceEnables Claude to interact with Ethereum nodes, allowing users to check ENS token balances, view smart contract code, and decode transactions through natural language.
5
1
MIT
ethereum-tools
by 0xGval
Claude MCP 向け Ethereum ツール
モデル コンテキスト プロトコル (MCP) を使用して、Claude AI 内で直接 Ethereum ブロックチェーンを分析するための包括的なツールキット。
特徴
スマートコントラクト監査: セキュリティ上の問題がないか契約を分析し、ソースコードを検証し、トークン標準を検出します。
ウォレット分析：ETH残高、トークン保有量、取引履歴を確認する
収益性追跡：トークンと取引全体のウォレットの利益/損失を計算します
ブロックチェーンデータ: シンプルなコマンドでオンチェーンデータを取得して分析
トークン分析: 包括的なトークンの詳細、価格履歴、取引パターンを取得します
Related MCP server: Base MCP Server
インストール
前提条件
Node.js v16+
デスクトップ版クロード
無料のAPIキー:
セットアップ手順
このリポジトリをクローンします:
git clone https://github.com/giovannialbero1992/ethereum-tools-mcp cd ethereum-tools-mcp依存関係をインストールします:
npm install構成を作成します。
mcp.json.exampleをmcp.jsonにコピーします。mcp.jsonを編集して API キーと正しいファイルパスを追加します
{ "mcpServers": { "ethereum-tools": { "command": "node", "args": ["YOUR_ABSOLUTE_PATH_TO/main.js"], "env": { "ETH_RPC_URL": "https://eth.llamarpc.com", "MORALIS_API_KEY": "your_moralis_api_key", "ETHERSCAN_API_KEY": "your_etherscan_api_key", "CODEX_API_KEY": "your_codex_api_key" } } } }Claude をデスクトップ用に設定する:
Windowsの場合:
%APPDATA%\Claude\claude_desktop_config.jsonを作成/編集します。mcp.jsonファイルの内容をこの構成にコピーします
利用可能なツール
契約分析
auditContract(address: "0x..."): スマートコントラクトのセキュリティ監査を実行します。
残高とトークン
getEthBalance(address: "0x..."): ETH残高を取得するgetTransactionCount(address: "0x..."): トランザクション数を取得する (nonce)getTokensBalance(address: "0x...", chain: "eth", excludeSpam: true): すべてのトークン残高を取得する
収益性
getWalletPnl(address: "0x...", chain: "eth"): ウォレットの損益を分析する
トークン分析
getTokenInfo(address: "0x...", networkId: 1): 名前、シンボル、供給を含む基本的なトークン情報を取得します。getTokenPriceHistory(address: "0x...", networkId: 1, days: 7, resolution: "1D"): 過去の価格データを取得するanalyzeToken(address: "0x...", networkId: 1, days: 30): ボラティリティや取引パターンを含む包括的なトークン分析を実行します。
ユーティリティ
add(a: 1, b: 2): シンプルなユーティリティ関数の例
トラブルシューティング
よくある問題:
環境変数が見つかりません: API キーが
mcp.jsonに正しく設定されていることを確認してくださいプロバイダーエラー: ETH_RPC_URLが有効でアクセス可能であることを確認してください
パスエラー: Windows で適切なエスケープを使用した完全な絶対パスを使用していることを確認してください (
\\)Codex API の問題: Codex API キーが有効であり、トークン データにアクセスする権限があることを確認してください
発達
新しいツールを追加するには:
tools/ディレクトリ内のファイルを作成または変更するmain.jsにツールを登録する変更を確認するには、Claude for Desktopを再起動してください。
ライセンス
このプロジェクトは MIT ライセンスに基づいてライセンスされています。
謝辞
Anthropicによるモデルコンテキストプロトコル（MCP）
Available Tools
11 toolsaddD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyzeTokenD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| networkId | No | Network ID (1 for Ethereum, 101 for Solana) | |
| days | No | Number of days to analyze |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
auditContractD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getEthBalanceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenInfoD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| networkId | No | Network ID (1 for Ethereum, 101 for Solana) |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokenPriceHistoryD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| networkId | No | Network ID (1 for Ethereum, 101 for Solana) | |
| days | No | Number of days of history | |
| resolution | No | Time resolution (e.g. 1D, 1H, 60) | 1D |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTokensBalanceD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth | |
| excludeSpam | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getTransactionCountD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getWalletPnlD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchTwitterD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| section | No | latest | |
| limit | No | ||
| min_retweets | No | ||
| min_likes | No | ||
| min_replies | No | ||
| start_date | No | ||
| end_date | No | ||
| language | No |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
twitterSearchHelpD
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | general |
TDQS
D1/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
11 tool updates
- First observed
add - First observed
analyzeToken - First observed
auditContract - First observed
getEthBalance - First observed
getTokenInfo - First observed
getTokenPriceHistory - First observed
getTokensBalance - First observed
getTransactionCount - First observed
getWalletPnl - First observed
searchTwitter - First observed
twitterSearchHelp
TDQS
D1.6/5.0
Scored across 11 tools
Disambiguation3/5
Most tools have distinct purposes targeting different Ethereum-related functions like balances, token analysis, and contract auditing, but there is some overlap between 'searchTwitter' and 'twitterSearchHelp' which could cause confusion. The lack of descriptions exacerbates potential ambiguity for tools like 'add' which has no clear domain context.
Naming Consistency2/5
Naming is inconsistent with a mix of camelCase ('analyzeToken', 'getEthBalance') and snake_case ('get_token_info' implied but not used), and vague verbs like 'add' without a clear pattern. While some tools follow a 'getX' structure, the overall convention is mixed and lacks predictability.
Tool Count4/5
With 11 tools, the count is reasonable for an Ethereum-focused server, covering areas like wallet management, token analysis, and social media search. It's slightly high but well within typical bounds for such a domain without feeling overly heavy or thin.
Completeness3/5
The tool set covers key Ethereum operations like balance checks, token info, and contract auditing, but has notable gaps such as transaction sending, smart contract interaction beyond auditing, and wallet creation. The inclusion of Twitter search tools feels tangential and incomplete for core blockchain functionality.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Claude-ready DeFi MCP — risk-scored yields, profit sims & whale tracking across 86 blockchains
Claude-powered AI tools: research, write, code, analyze, translate, debate, pitch, score, and more.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Related MCP Servers
Base MCP Serverofficial
AlicenseNot gradedqualityFmaintenanceProvides onchain tools for Claude AI to interact with the Base blockchain and Coinbase API, enabling wallet management, fund transfers, and smart contract deployment.148 npm350MIT- AlicenseBqualityDmaintenanceProvides Claude with access to Ethereum and EVM-compatible blockchain operations, enabling wallet management, transaction handling, contract interactions, and blockchain queries through natural language.43558 npm10MIT
- FlicenseBqualityDmaintenanceA local Ethereum contract analysis tool that retrieves on-chain information, integrates Etherscan and RPC data, and automatically executes view functions to provide comprehensive contract insights.23-