Skip to main content
Glama
enesjakozh
crazyrabbitLTC

MCP Etherscan Server

by crazyrabbitLTC
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

MCP Etherscan 서버

Etherscan API를 통해 이더리움 블록체인 데이터 도구를 제공하는 MCP(Model Context Protocol) 서버입니다. ETH 잔액 확인, 거래 내역 조회, ERC20 이체 추적, 컨트랙트 ABI 가져오기, 가스 가격 모니터링, ENS 이름 확인 등의 기능을 제공합니다.

특징

  • 잔액 확인 : 모든 이더리움 주소에 대한 ETH 잔액을 확인하세요

  • 거래 내역 : 최근 거래 내역을 자세한 정보와 함께 확인하세요

  • 토큰 전송 : 토큰 세부 정보를 사용하여 ERC20 토큰 전송을 추적하세요

  • 계약 ABI : 개발을 위한 스마트 계약 ABI 가져오기

  • 가스 가격 : 현재 가스 가격(안전 저가, 표준, 빠름)을 모니터링하세요

  • ENS 해결 : Ethereum 주소를 ENS 이름으로 해결

Related MCP server: MCP Etherscan Server

필수 조건

설치

  1. 저장소를 복제합니다.

지엑스피1

  1. 종속성 설치:

npm install

  1. 루트 디렉토리에 .env 파일을 만듭니다.

ETHERSCAN_API_KEY=your_api_key_here

  1. 프로젝트를 빌드하세요:

npm run build

서버 실행

서버를 시작합니다:

npm start

서버는 stdio에서 실행되므로 Claude Desktop과 같은 MCP 클라이언트와 호환됩니다.

작동 원리

이 서버는 Etherscan API를 통해 이더리움 블록체인 데이터와 상호작용하는 도구를 제공하기 위해 모델 컨텍스트 프로토콜(MCP)을 구현합니다. 각 도구는 호환되는 클라이언트에서 호출할 수 있는 MCP 엔드포인트로 제공됩니다.

사용 가능한 도구

  1. check-balance

    • 입력: 이더리움 주소

    • 출력: Wei와 ETH 모두의 ETH 잔액

  2. get-transactions

    • 입력: 이더리움 주소, 선택적인 제한

    • 출력: 타임스탬프, 값 및 주소가 포함된 최근 거래

  3. get-token-transfers

    • 입력: 이더리움 주소, 선택적인 제한

    • 출력: 토큰 세부 정보가 포함된 최근 ERC20 토큰 전송

  4. get-contract-abi

    • 입력: 계약 주소

    • 출력: JSON 형식의 계약 ABI

  5. get-gas-prices

    • 입력: 없음

    • 출력: Gwei의 현재 가스 가격

  6. get-ens-name

    • 입력: 이더리움 주소

    • 출력: 사용 가능한 경우 연관된 ENS 이름

Claude Desktop과 함께 사용

Claude Desktop에 이 서버를 추가하려면:

  1. npm start 사용하여 서버를 시작합니다.

  2. Claude Desktop에서:

    • 설정으로 이동

    • MCP 서버 섹션으로 이동

    • "서버 추가"를 클릭하세요

    • 다음 구성을 입력하세요.

      {
  "name": "Etherscan Tools",
  "transport": "stdio",
  "command": "node /path/to/mcp-etherscan-server/build/index.js"
}

    • 구성을 저장합니다

  3. 이제 Claude 대화에서 Etherscan 도구를 사용할 수 있습니다.

Claude에서의 사용 예

다음과 같은 명령을 사용할 수 있습니다.

Check the balance of 0x742d35Cc6634C0532925a3b844Bc454e4438f44e

또는

Show me recent transactions for vitalik.eth

개발

새로운 기능을 추가하거나 기존 기능을 수정하려면:

  1. 메인 서버 로직은 src/server.ts 에 있습니다.

  2. Etherscan API 상호 작용은 src/services/etherscanService.ts 에서 처리됩니다.

  3. 변경 후 빌드: npm run build

특허

MIT 라이선스 - 자세한 내용은 라이선스 파일을 참조하세요.

Available Tools

6 tools
check-balanceB

Check the ETH balance of an Ethereum address

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesEthereum address (0x format)

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only states a read operation, but fails to disclose return format, units, rate limits, or other 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.

Conciseness5/5

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

The description is a single concise sentence with no waste. It is front-loaded and efficient.

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

Completeness2/5

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

Despite the tool's simplicity, the description lacks information about return values (e.g., unit of balance), error cases, or any operational context. It is minimally complete.

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

Parameters3/5

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

Schema coverage is 100%, and the description adds no meaning beyond what the schema already provides for the address parameter. Baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool checks the ETH balance of an Ethereum address, with a specific verb and resource. It distinguishes from siblings like get-contract-abi or get-ens-name.

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

Usage Guidelines2/5

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 any when-not-to-use scenarios. A single sentence lacks context for selection.

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

get-contract-abiC

Get the ABI for a smart contract

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesContract address (0x format)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description carries full burden. It fails to disclose behaviors like what happens if the address is not a contract, network requirements, or whether the ABI is returned as JSON. This is insufficient for safe invocation.

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

Conciseness4/5

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

The description is a single sentence with no unnecessary words. However, it could benefit from slight expansion to include return format, which would improve completeness without harming conciseness.

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

Completeness2/5

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 should explain what the tool returns (e.g., JSON ABI array). It also lacks error states or network context. This is inadequate for a tool interacting with smart contracts.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter 'address', which is described with a pattern. The description adds no 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.

Purpose4/5

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

The description clearly states the action ('Get') and the resource ('ABI for a smart contract'), making the tool's purpose easily understandable. It distinguishes from siblings which handle balances, ENS names, gas prices, transfers, and transactions.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or what prerequisites are needed (e.g., contract must be verified or on a supported network). The sibling tools are unrelated, but lack of any usage context reduces score.

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

get-ens-nameB

Get the ENS name for an Ethereum address

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesEthereum address (0x format)

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states a read operation. It does not disclose potential failures (e.g., whether it returns null for addresses without ENS names), network dependencies, or any side effects. Minimal behavioral context beyond the obvious.

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

Conciseness5/5

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

The description is a single sentence that conveys the core action and object. Every word is functional; there is no fluff or redundancy. It is optimally concise for the tool's simplicity.

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

Completeness3/5

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, no output schema, no annotations), the description covers the essential purpose but omits details about the return value format, potential errors, or whether it resolves primary ENS names. It is minimally adequate but leaves gaps for an agent unfamiliar with ENS.

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

Parameters3/5

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

Schema coverage is 100% as the single parameter 'address' has a description, pattern, and type. The description adds no extra meaning beyond restating the parameter's purpose ('for an Ethereum address'). It does not provide examples or clarify format nuances beyond the schema.

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

Purpose5/5

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

The description uses a specific verb ('Get') and resource ('ENS name') combined with a clear target ('Ethereum address'). It clearly distinguishes from sibling tools which deal with balances, ABIs, gas, transfers, and transactions, leaving no ambiguity about the tool's function.

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

Usage Guidelines2/5

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. There is no mention of prerequisites, exclusions, or context where this tool is preferred, leaving the agent to infer usage solely from the name and siblings.

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

get-gas-pricesA

Get current gas prices in Gwei

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, and the description omits behavioral details like data freshness, polling limits, or whether it returns a single value or multiple fee levels. For a zero-parameter tool, the description carries full burden and leaves ambiguity.

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

Conciseness4/5

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

Extremely concise single sentence, no wasted words. However, could have added output format without harming conciseness.

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

Completeness2/5

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

Despite low complexity and no parameters, the lack of output schema means the description should clarify what 'gas prices' includes (e.g., low/avg/high). Fails to fully inform an agent about return format.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. No additional param info needed; the description appropriately has no redundant details.

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

Purpose5/5

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

The description clearly states the action (get), the resource (current gas prices), and the unit (Gwei). It effectively distinguishes from sibling tools like check-balance or get-transactions, which are unrelated.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or alternatives, but the tool's simplicity and unique purpose among siblings make usage straightforward. Lacks when-not or context for multi-fee levels.

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

get-token-transfersC

Get ERC20 token transfers for an Ethereum address

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of transfers to return (max 100)
addressYesEthereum address (0x format)

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, and the description fails to disclose important behavioral details such as pagination, ordering, or whether the result includes all transfers or only recent ones.

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

Conciseness3/5

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

The description is a single sentence and front-loaded, but lacks important context. It is not overly verbose, but could be more informative.

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

Completeness3/5

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

Given the simple nature of the tool and the presence of schema descriptions for both parameters, the description is minimally adequate. However, it does not cover aspects like return format or usage constraints.

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

Parameters3/5

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

Schema coverage is 100%, so baseline score of 3 applies. The description adds no additional meaning beyond the already documented parameters.

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

Purpose4/5

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

The description clearly states that the tool retrieves ERC20 token transfers for a given Ethereum address. It is specific about the resource and action, but does not differentiate from siblings like get-transactions.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as get-transactions or check-balance. The description lacks context for appropriate usage.

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

get-transactionsB

Get recent transactions for an Ethereum address

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of transactions to return (max 100)
addressYesEthereum address (0x format)

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states 'Get recent transactions' without specifying behavior like pagination, rate limits, confirmation status, or what constitutes 'recent'. This leaves key behavioral traits unaddressed.

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

Conciseness5/5

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

A single, well-front-loaded sentence that conveys the purpose without fluff. Every word earns its place.

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

Completeness2/5

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

Despite the simple interface, the lack of output schema and behavioral details means the description does not sufficiently inform an agent about what data to expect or how to handle results, leaving it incomplete for effective use.

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

Parameters3/5

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

All parameters are described in the input schema with 100% coverage. The description adds no extra semantic meaning beyond the schema, aligning with the baseline score.

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

Purpose5/5

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 ('recent transactions for an Ethereum address'), immediately distinguishing it from siblings like 'check-balance' or 'get-token-transfers'.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'get-token-transfers' for token-specific data or 'check-balance' for balances. Context for appropriate selection is missing.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.1
    • First observedcheck-balance
    • First observedget-contract-abi
    • First observedget-ens-name
    • First observedget-gas-prices
    • First observedget-token-transfers
    • First observedget-transactions
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool targets a distinct Ethereum data type (balance, ABI, ENS, gas prices, token transfers, transactions) with no overlap, making it easy for an agent to choose the correct one.

Naming Consistency4/5

All tools follow a verb_noun pattern with 'get' as the verb except 'check-balance' uses 'check', which is a minor inconsistency but still predictable.

Tool Count5/5

6 tools is well-scoped for an Etherscan server, covering the most common Ethereum queries without being overwhelming or too sparse.

Completeness4/5

The set covers core Ethereum operations (balance, transactions, ABI, ENS, gas, token transfers), but lacks some common endpoints like block queries or event logs, which are minor gaps.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crazyrabbitLTC/mcp-etherscan-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server