evm-mcp-server: 22 MCP Tools for 60+ EVM Chains, With a Private Key in the Environment
MCP server that provides LLMs with tools for interacting with EVM networks
At a glance
- What is it?
- mcpdotdirect/evm-mcp-server puts chain reads, token transfers and contract writes behind an MCP interface that any compliant agent can call. The interesting part is not the tool count, it is that write access is gated by a single environment variable and ABI lookup routes through one explorer API.
- Who is it for?
- Adopt it if you want an agent to read state across many EVM chains and you are willing to keep EVM_PRIVATE_KEY out of the agent's environment until you have decided the write tools are acceptable. Do not adopt it if you need transaction simulation before signing, hardware-wallet signing, or a deployment model that does not involve a process holding a raw key.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: an agent that can read a chain but cannot touch it
An LLM asked to check a wallet balance has no way to do it. It can produce a plausible number, and that number is worthless. The usual workaround is to hand the model a shell and hope it writes correct cast or curl invocations against an RPC endpoint. That works until it does not, and the failure is silent: a malformed address, the wrong chain, a stale block number.
ev-mcp-server replaces that improvisation with a fixed tool surface. The README describes 22 tools and 10 prompts covering balances, blocks, transactions and receipts, ERC20, ERC721 and ERC1155 operations, contract reads and writes, event logs, gas estimation, and message signing including EIP-712 and SIWE. The intended user is someone building an agent that needs blockchain facts as inputs, not someone writing a trading bot. The distinction matters because the tool set is shaped around discrete, describable operations rather than a general-purpose scripting escape hatch.
How the tools are wired: MCP in front, viem behind, Etherscan v2 for ABIs
The server is a TypeScript process that speaks the Model Context Protocol over stdio, the transport most desktop MCP clients expect. The README pins MCP 1.22.0 or higher and viem 2.39.3 or higher, so chain access goes through viem's client abstraction rather than hand-rolled JSON-RPC. Each tool is a declared function with a schema, which is what lets a client present the tool list to a model instead of the model guessing at an interface.
Two mechanisms are worth calling out. First, ENS resolution is applied to every address parameter, so a tool call can pass vitalik.eth and the server resolves it before the chain call. That is a small convenience with a real consequence: the model does not need to hold a 42-character hex string in context, which is where transcription errors come from.
Second, ABI fetching. Contract read and write tools do not require the caller to supply an ABI. The server fetches it from the Etherscan v2 API, which the README says covers all 60+ supported networks, then parses it to discover functions. This is the piece that makes contract interaction usable from a model, because an agent cannot be expected to carry an ABI in its prompt. It also creates a hard dependency: if the explorer has not verified the contract, or the API key is missing or rate-limited, the write path degrades. The README lists the Etherscan API key as optional, which is true for reads against known ABIs but misleading for the automatic-fetch feature that is the server's main selling point.
Getting it running: Bun, one environment variable, and a config block
The README gives the install path directly. Clone the repository, then either bun install or npm install. Bun 1.0.0 or higher is listed as recommended, Node.js 20.0.0 or higher as the fallback. The repository also has a Development section, so the source layout is meant to be built rather than only consumed.
Wallet configuration is the part that determines what the server can do. Write operations require either EVM_PRIVATE_KEY, set as a hex string with or without the 0x prefix, or EVM_MNEMONIC with a 12 or 24 word BIP-39 phrase. The mnemonic path adds EVM_ACCOUNT_INDEX for HD derivation, defaulting to 0. The README labels the mnemonic option as recommended for HD wallets. ABI fetching is the other configuration surface, driven by an Etherscan API key.
The README's configuration section also references a Server Configuration subsection, but the supplied material is truncated before it, so I cannot describe the exact client-side JSON. What is clear from the MCP framing is that the server is launched as a subprocess and the environment variables must be present in that subprocess's environment, not in your shell profile. If you set EVM_PRIVATE_KEY in a shell you use for other things, every process you launch inherits it.
The write path is the risk model, and the README does not resolve it
Read tools are harmless. Write tools are not, and the server exposes native transfers, ERC20 transfers and approvals, ERC721 and ERC1155 transfers, and arbitrary state-changing contract calls. All of them are reachable by whatever model your client connects, using a key that sits in the process environment.
The README has a Security Considerations section, but the supplied text does not include its contents, so I cannot say what mitigations it proposes. What can be said from the configuration alone is that there is no described confirmation step between a tool call and a broadcast. Some MCP clients prompt the user before each tool invocation, and that prompt is the only gate. If your client auto-approves tools, the model can move funds.
The practical consequence: the default posture should be read-only. Set no wallet variables, run the server, and the write tools either fail or are absent. Add EVM_PRIVATE_KEY only in an environment you are willing to lose, and prefer EVM_MNEMONIC with a dedicated EVM_ACCOUNT_INDEX so the derived account is separate from anything holding real value. The README's own recommendation of mnemonics over raw keys points the same direction, though the reason it gives is HD wallet support rather than key isolation.
Where it breaks: unverified contracts, explorer coverage, and chain drift
Automatic ABI fetching is the feature most likely to fail in practice, and it fails in a specific way. The server queries Etherscan v2 for the contract's ABI. A contract deployed last week and not yet verified returns nothing, and the write tool has no ABI to call. A proxy contract returns the proxy ABI, not the implementation's, so the function you want may not appear in the discovered set. The README notes ABI parsing and validation with function discovery, which suggests the server surfaces what it found, but a model given an incomplete function list will pick from what is there.
The 60+ network claim also deserves scrutiny. The README lists 34 mainnets and 26 testnets by name, and the count in the badge is a rounded claim. The list includes chains with thin explorer coverage, and Etherscan v2's reach across all of them is a dependency the README asserts rather than demonstrates. On a chain where the explorer integration is weak, contract interaction tools are effectively read-only.
A quieter issue: chain data changes. RPC endpoints get deprecated, testnets get sunset, and the supported-network list is maintained by hand in a repository whose last push is dated 2026-08-01. Nothing in the material describes an automated check that the listed RPCs still respond.
Compared with pointing an agent at a wallet SDK directly
The obvious alternative is skipping MCP and giving the agent a typed SDK such as viem or ethers, plus a small set of wrapper functions you write yourself. The difference is where the interface is defined. With an SDK, the model either writes code that you execute, or you hand-build a function-calling schema for each operation. With evm-mcp-server, that schema already exists and follows a protocol your client already understands.
The trade-off is control. A hand-written wrapper can enforce a spend limit, require a simulation before broadcast, or restrict which contracts are callable. evm-mcp-server gives you a general contract-write tool with automatic ABI discovery, which is the opposite of a restrictive interface. If your requirement is that the agent can only call three specific functions on one contract, this server is the wrong shape: you will spend more effort constraining it than writing the wrapper.
The other alternative is a chain-specific MCP server. Those exist for individual networks and tend to expose fewer chains with more depth per chain. evm-mcp-server's bet is breadth: one process, one configuration, 60+ networks, uniform tools. That bet pays off when your agent needs to compare state across chains. It costs you when you need chain-specific behaviour that a uniform interface cannot express.
Maintenance: MIT licence, three releases in one day, and what that pattern implies
The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice retained. That is permissive and imposes no copyleft obligation on your own code. It also means no warranty, and the Security Considerations section is the only place the project can address the fact that it handles private keys. Nothing in the licence protects you from a key-handling bug. This is not legal advice; if you are deploying this in a regulated context, the licence text and your own obligations are separate questions.
The release history is more informative than the licence. v2.0.2, v2.0.3 and v2.0.4 were all published on 2025-11-26, within roughly four minutes of each other. That is a patch-and-republish sequence, not a planned cadence. It suggests active maintenance, and it also suggests that releases are cut quickly. For a server that signs transactions, pinning a version and reading the diff between releases is a reasonable precaution. The repository's last push is dated 2026-08-01, later than the most recent release, so there is work on main that is not in a tagged version.
Upgrade cost is low in the abstract: it is a TypeScript process you install with Bun or npm, and the version pins are on MCP and viem rather than on the server itself. The real cost is re-verifying the tool list after each upgrade, because the tool surface is the contract your agent depends on. A tool renamed or removed between v2.0.3 and v2.0.4 would break prompts silently.
Editorial conclusion
Adopt it if you want an agent to read state across many EVM chains and you are willing to keep EVM_PRIVATE_KEY out of the agent's environment until you have decided the write tools are acceptable. Do not adopt it if you need transaction simulation before signing, hardware-wallet signing, or a deployment model that does not involve a process holding a raw key. Before trusting it, run it against a testnet such as Sepolia with a throwaway mnemonic, confirm which of the 22 tools appear in your client's tool list, and check whether ABI fetching works for your target contracts with and without ETHERSCAN_API_KEY set.
Community notes