Skip to main content
Glama
0xGval
by 0xGval

Claude MCP를 위한 Ethereum 도구

Claude AI 내에서 Model Context Protocol(MCP)을 사용하여 Ethereum 블록체인을 직접 분석할 수 있는 포괄적인 툴킷입니다.

특징

  • 스마트 계약 감사 : 보안 문제에 대한 계약을 분석하고, 소스 코드를 검증하고, 토큰 표준을 감지합니다.

  • 지갑 분석 : ETH 잔액, 토큰 보유량, 거래 내역 확인

  • 수익성 추적 : 토큰 및 거래 전반에 걸친 지갑 수익/손실 계산

  • 블록체인 데이터 : 간단한 명령으로 온체인 데이터를 가져오고 분석합니다.

  • 토큰 분석 : 포괄적인 토큰 세부 정보, 가격 내역 및 거래 패턴을 확인하세요.

Related MCP server: Base MCP Server

설치

필수 조건

  • Node.js v16+

  • 데스크톱용 클로드

  • 무료 API 키:

    • Etherscan - 계약 검증 및 분석용

    • Moralis - 지갑 수익성 및 토큰 잔액

    • Codex - 토큰 가격 내역 및 고급 분석

    • (선택 사항) Infura 와 같은 RPC 공급자 또는 무료 공개 엔드포인트 사용

설정 단계

  1. 이 저장소를 복제하세요:

    지엑스피1

  2. 종속성 설치:

    npm install
  3. 구성을 생성하세요:

    • mcp.json.example``mcp.json 으로 복사합니다.

    • API 키와 올바른 파일 경로를 포함하도록 mcp.json 편집하세요.

    {
      "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"
          }
        }
      }
    }
  4. 데스크톱에 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) : 간단한 유틸리티 함수 예제

문제 해결

일반적인 문제:

  • 환경 변수를 찾을 수 없습니다 . mcp.json 에 API 키가 올바르게 설정되어 있는지 확인하세요.

  • 공급자 오류 : ETH_RPC_URL이 유효하고 액세스 가능한지 확인하세요.

  • 경로 오류 : Windows에서 적절한 이스케이프( \\ )를 사용하여 전체 절대 경로를 사용하고 있는지 확인하세요.

  • Codex API 문제 : Codex API 키가 유효하고 토큰 데이터에 액세스할 수 있는 권한이 있는지 확인하세요.

개발

새로운 도구를 추가하려면:

  1. tools/ 디렉토리에 파일을 생성하거나 수정합니다.

  2. main.js 에 도구를 등록하세요

  3. 변경 사항을 확인하려면 데스크톱용 Claude를 다시 시작하세요.

특허

이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다.

감사의 말

Available Tools

11 tools
addD
ParametersJSON Schema
NameRequiredDescriptionDefault
aYes
bYes

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
NameRequiredDescriptionDefault
addressYes
networkIdNoNetwork ID (1 for Ethereum, 101 for Solana)
daysNoNumber 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
NameRequiredDescriptionDefault
addressYes
chainNoeth

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
NameRequiredDescriptionDefault
addressYes

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
NameRequiredDescriptionDefault
addressYes
networkIdNoNetwork 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
NameRequiredDescriptionDefault
addressYes
networkIdNoNetwork ID (1 for Ethereum, 101 for Solana)
daysNoNumber of days of history
resolutionNoTime 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
NameRequiredDescriptionDefault
addressYes
chainNoeth
excludeSpamNo

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
NameRequiredDescriptionDefault
addressYes

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
NameRequiredDescriptionDefault
addressYes
chainNoeth

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
NameRequiredDescriptionDefault
queryYes
sectionNolatest
limitNo
min_retweetsNo
min_likesNo
min_repliesNo
start_dateNo
end_dateNo
languageNo

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
NameRequiredDescriptionDefault
topicNogeneral

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.

  1. 11 tool updates
    • First observedadd
    • First observedanalyzeToken
    • First observedauditContract
    • First observedgetEthBalance
    • First observedgetTokenInfo
    • First observedgetTokenPriceHistory
    • First observedgetTokensBalance
    • First observedgetTransactionCount
    • First observedgetWalletPnl
    • First observedsearchTwitter
    • First observedtwitterSearchHelp

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

Related MCP Servers