ethereum-tools
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:
Pasos de configuración
Clonar este repositorio:
git clone https://github.com/giovannialbero1992/ethereum-tools-mcp cd ethereum-tools-mcpInstalar dependencias:
npm installCrea tu configuración:
Copiar
mcp.json.exampleamcp.jsonEdite
mcp.jsonpara 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" } } } }Configurar Claude para escritorio:
En Windows: crear/editar
%APPDATA%\Claude\claude_desktop_config.jsonCopie el contenido de su archivo
mcp.jsonen 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 ETHgetTransactionCount(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 suministrogetTokenPriceHistory(address: "0x...", networkId: 1, days: 7, resolution: "1D"): Obtener datos históricos de preciosanalyzeToken(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.jsonErrores 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:
Crear o modificar archivos en el directorio
tools/Registra tus herramientas en
main.jsReinicie Claude for Desktop para ver los cambios
Licencia
Este proyecto está licenciado bajo la licencia MIT.
Expresiones de gratitud
Available Tools
11 toolsaddD
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| networkId | No | Network ID (1 for Ethereum, 101 for Solana) | |
| days | No | Number of days to analyze |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| networkId | No | Network ID (1 for Ethereum, 101 for Solana) |
TDQS
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.
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.
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.
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.
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.
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
| 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
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth | |
| excludeSpam | No |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ||
| chain | No | eth |
TDQS
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.
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.
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.
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.
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.
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
| 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
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | general |
TDQS
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.
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.
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.
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.
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.
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
Scored across 11 tools
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 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.
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.
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
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
- AlicenseBqualityDmaintenanceEnables Claude to interact with Ethereum nodes, allowing users to check ENS token balances, view smart contract code, and decode transactions through natural language.51MIT

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-