Which integrations are available for this server?

Provides tools for Ethereum blockchain analysis, including smart contract auditing, wallet balance checking, transaction history analysis, and token tracking. Connects to GitHub for repository access, allowing users to clone and utilize the Ethereum tools repository. Leverages Node.js runtime environment for executing Ethereum analysis tools and blockchain interactions. Utilizes Web3.js for blockchain interaction, enabling functions like balance checks, transaction counts, and smart contract analysis.

How do I use ethereum-tools?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ethereum-tools audit contract 0x742d35Cc6634C0532925a3b844Bc9e90F1A902A5" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

en es ja ko zh

ethereum-tools

by 0xGval

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Ethereum Tools for Claude MCP

A comprehensive toolkit for Ethereum blockchain analysis directly within Claude AI using Model Context Protocol (MCP).

Features

Smart Contract Audit: Analyze contracts for security issues, verify source code, and detect token standards
Wallet Analysis: Check ETH balances, token holdings, and transaction history
Profitability Tracking: Calculate wallet profit/loss across tokens and trades
Blockchain Data: Fetch and analyze on-chain data with simple commands
Token Analysis: Get comprehensive token details, price history, and trading patterns
Twitter Search: Find tweets by keywords, usernames, dates, or complex search criteria with natural language processing

Related MCP server: Base MCP Server

Installation

Prerequisites

Node.js v16+
Claude for Desktop
Free API keys:
- Etherscan - For contract verification and analysis
- Moralis - For wallet profitability and token balances
- Codex - For token price history and advanced analytics
- RapidAPI - For Twitter search functionality
- (Optional) RPC provider like Infura or use free public endpoints

Setup Steps

Clone this repository:

git clone https://github.com/0xGval/evm-tools-mcp
cd evm-tools-mcp

Install dependencies:
```
npm install
```

Create your configuration:

Copy mcp.json.example to mcp.json
Edit mcp.json to include your API keys and correct file paths

{
  "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",
        "RAPIDAPI_KEY": "your_rapidapi_key"
      }
    }
  }
}

Configure Claude for Desktop:
- On Windows: Create/edit %APPDATA%\Claude\claude_desktop_config.json
- Copy the contents of your mcp.json file into this configuration

Available Tools

Contract Analysis

auditContract(address: "0x..."): Perform security audit on a smart contract

Balance & Tokens

getEthBalance(address: "0x..."): Get ETH balance
getTransactionCount(address: "0x..."): Get transaction count (nonce)
getTokensBalance(address: "0x...", chain: "eth", excludeSpam: true): Get all token balances

Profitability

getWalletPnl(address: "0x...", chain: "eth"): Analyze wallet profit/loss

Token Analysis

getTokenInfo(address: "0x...", networkId: 1): Get basic token information including name, symbol, and supply
getTokenPriceHistory(address: "0x...", networkId: 1, days: 7, resolution: "1D"): Get historical price data
analyzeToken(address: "0x...", networkId: 1, days: 30): Perform comprehensive token analysis including volatility and trading patterns

Twitter Search

searchTwitter(query: "ethereum", section: "top", limit: 5): Intelligent Twitter search with natural language processing
- Automatically formats natural language queries into proper Twitter syntax
- Understands user queries like "Find tweets by _gval about hyperliquid"
- Supports advanced Twitter search operators: from:username, has:links, etc.
- Optional parameters: min_likes, min_retweets, min_replies, start_date, end_date, language
twitterSearchHelp(topic: "general"): Get help with Twitter search syntax
- Available topics: "general", "user", "date"
- Provides examples and explanations of Twitter search operators

Utilities

add(a: 1, b: 2): Simple utility function example

Troubleshooting

Common issues:

Environment variables not found: Make sure your API keys are correctly set in mcp.json
Provider errors: Check that your ETH_RPC_URL is valid and accessible
Path errors: Ensure you're using full absolute paths with proper escaping in Windows (\\)
Codex API issues: Verify your Codex API key is valid and has permission to access token data
Twitter search errors: Make sure your RapidAPI key has access to the Twitter154 API

Development

To add new tools:

Create or modify files in the tools/ directory
Register your tools in main.js
Restart Claude for Desktop to see changes

License

This project is licensed under the MIT License.

Acknowledgements

Model Context Protocol (MCP) by Anthropic
Web3.js
Moralis
Etherscan
Codex
RapidAPI Twitter154

Available Tools

11 tools

addD

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes
`b`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyzeTokenD

ParametersJSON Schema

Name	Required	Description
`address`	Yes
`networkId`	No	Network ID (1 for Ethereum, 101 for Solana)
`days`	No	Number of days to analyze

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

auditContractD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes
`chain`	No		eth

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getEthBalanceD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getTokenInfoD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes
`networkId`	No	Network ID (1 for Ethereum, 101 for Solana)

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getTokenPriceHistoryD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes
`networkId`	No	Network ID (1 for Ethereum, 101 for Solana)
`days`	No	Number of days of history
`resolution`	No	Time resolution (e.g. 1D, 1H, 60)	1D

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getTokensBalanceD

ParametersJSON Schema

Name	Required	Default
`address`	Yes
`chain`	No	eth
`excludeSpam`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getTransactionCountD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

getWalletPnlD

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes
`chain`	No		eth

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

searchTwitterD

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`section`	No	latest
`limit`	No
`min_retweets`	No
`min_likes`	No
`min_replies`	No
`start_date`	No
`end_date`	No
`language`	No

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

twitterSearchHelpD

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No		general

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.6/5.0

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

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

ProfitSpot MCP — The DeFi Brain for AI Agents
io.github.omniologynow-rgb
Claude-ready DeFi MCP — risk-scored yields, profit sims & whale tracking across 86 blockchains
Finance Blockchain Web3 & Decentralized Tech
2
AiPayGent — Claude AI Tools
io.github.djautomd-lab
Claude-powered AI tools: research, write, code, analyze, translate, debate, pitch, score, and more.
Developer Tools App Automation
2
Nansen A
io.github.nansen-ai
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
382
Nansen A
io.github.hurcanNansen
Blockchain analytics API for AI agents. Smart Money signals, wallet profiling, token analytics.
Blockchain Web3 & Decentralized Tech Finance
382

Related MCP Servers

Veri5ight MCP Server
Blockchain Web3 & Decentralized Tech
5ajaki
A
license
B
quality
D
maintenance
Enables Claude to interact with Ethereum nodes, allowing users to check ENS token balances, view smart contract code, and decode transactions through natural language.
Updated 2 years ago (2025-01-31 04:17 UTC)
5
1
MIT
Base MCP Serverofficial
Blockchain Web3 & Decentralized Tech Cryptocurrency
base
A
license
Not graded
quality
F
maintenance
Provides onchain tools for Claude AI to interact with the Base blockchain and Coinbase API, enabling wallet management, fund transfers, and smart contract deployment.
Updated 4 months ago (2026-05-13 20:07 UTC)
13
350
MIT
MCP Crypto Wallet EVM
Blockchain Web3 & Decentralized Tech Cryptocurrency
dcSpark
A
license
B
quality
D
maintenance
Provides Claude with access to Ethereum and EVM-compatible blockchain operations, enabling wallet management, transaction handling, contract interactions, and blockchain queries through natural language.
Updated a year ago (2025-03-26 03:12 UTC)
4
35
61
10
MIT
Contract Inspector MCP
Blockchain Code Execution Web3 & Decentralized Tech
ACaiSec
F
license
B
quality
D
maintenance
A 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.
Updated a year ago (2025-06-30 09:55 UTC)
2
3

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/0xGval/evm-mcp-tools'

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

Ethereum Tools for Claude MCP

Features

Installation

Prerequisites

Setup Steps

Available Tools

Contract Analysis

Balance & Tokens

Profitability

Token Analysis

Twitter Search

Utilities

Troubleshooting

Development

License

Acknowledgements

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Base MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API