Skip to main content
Glama
0xGval
by 0xGval

Herramientas de Ethereum para Claude MCP

Un kit de herramientas completo para el análisis de la cadena de bloques Ethereum directamente dentro de Claude AI utilizando el Protocolo de Contexto de Modelo (MCP).

Características

  • Auditoría de contratos inteligentes : analice los contratos para detectar problemas de seguridad, verifique el código fuente y detecte estándares de tokens

  • Análisis de billetera : verifique saldos de ETH, tenencias de tokens e historial de transacciones

  • Seguimiento de rentabilidad : Calcule las ganancias/pérdidas de la billetera en todos los tokens y transacciones

  • Datos de blockchain : obtenga y analice datos en cadena con comandos simples

  • Análisis de tokens : obtenga detalles completos de los tokens, historial de precios y patrones comerciales

Related MCP server: Base MCP Server

Instalación

Prerrequisitos

  • Node.js v16+

  • Claude para escritorio

  • Claves API gratuitas:

    • Etherscan : para verificación y análisis de contratos

    • Moralis - Para la rentabilidad de la billetera y los saldos de tokens

    • Codex : para el historial de precios de tokens y análisis avanzados

    • (Opcional) Proveedor de RPC como Infura o utilice puntos finales públicos gratuitos

Pasos de configuración

  1. Clonar este repositorio:

    git clone https://github.com/giovannialbero1992/ethereum-tools-mcp
    cd ethereum-tools-mcp
  2. Instalar dependencias:

    npm install
  3. Crea tu configuración:

    • Copiar mcp.json.example a mcp.json

    • Edite mcp.json para incluir sus claves API y rutas de archivo correctas

    {
      "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. Configurar Claude para escritorio:

    • En Windows: crear/editar %APPDATA%\Claude\claude_desktop_config.json

    • Copie el contenido de su archivo mcp.json en esta configuración

Herramientas disponibles

Análisis de contratos

  • auditContract(address: "0x...") : Realizar una auditoría de seguridad en un contrato inteligente

Saldo y tokens

  • getEthBalance(address: "0x...") : Obtener el saldo de ETH

  • getTransactionCount(address: "0x...") : Obtener el recuento de transacciones (nonce)

  • getTokensBalance(address: "0x...", chain: "eth", excludeSpam: true) : Obtener todos los saldos de tokens

Rentabilidad

  • getWalletPnl(address: "0x...", chain: "eth") : Analizar las ganancias/pérdidas de la billetera

Análisis de tokens

  • getTokenInfo(address: "0x...", networkId: 1) : Obtiene información básica del token, incluido el nombre, el símbolo y el suministro

  • getTokenPriceHistory(address: "0x...", networkId: 1, days: 7, resolution: "1D") : Obtener datos históricos de precios

  • analyzeToken(address: "0x...", networkId: 1, days: 30) : Realiza un análisis completo de tokens, incluyendo volatilidad y patrones comerciales.

Servicios públicos

  • add(a: 1, b: 2) : Ejemplo de función de utilidad simple

Solución de problemas

Problemas comunes:

  • Variables de entorno no encontradas : asegúrese de que sus claves API estén configuradas correctamente en mcp.json

  • Errores del proveedor : Verifique que su ETH_RPC_URL sea válida y accesible

  • Errores de ruta : asegúrese de utilizar rutas absolutas completas con el escape adecuado en Windows ( \\ )

  • Problemas con la API de Codex : Verifique que su clave de API de Codex sea válida y tenga permiso para acceder a los datos del token

Desarrollo

Para agregar nuevas herramientas:

  1. Crear o modificar archivos en el directorio tools/

  2. Registra tus herramientas en main.js

  3. Reinicie Claude for Desktop para ver los cambios

Licencia

Este proyecto está licenciado bajo la licencia MIT.

Expresiones de gratitud

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