# mcpdotdirect/evm-mcp-server: 22 MCP tools across 60+ EVM chains

> The EVM MCP Server exposes blockchain reads, token transfers and contract calls to LLM agents over the Model Context Protocol, with automatic ABI fetching and ENS resolution. It is a TypeScript project under the MIT licence, and its write path needs a funded key in the environment.

**mcpdotdirect/evm-mcp-server** — MCP server that provides LLMs with tools for interacting with EVM networks

- Repository: https://github.com/mcpdotdirect/evm-mcp-server
- Stars: 379 · Forks: 105
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/mcpdotdirect-evm-mcp-server

## What the EVM MCP Server actually solves

An LLM cannot call eth_getBalance. It has no socket, no JSON-RPC client and no notion of a chain ID. The usual workaround is to write a bespoke tool wrapper for every chain and every contract, then keep those wrappers in sync with the ABI. The EVM MCP Server removes most of that glue: it is a Model Context Protocol server that registers 22 tools and 10 prompts, and an MCP-capable client such as Claude Desktop or an agent framework can call them by name.

The audience is narrow but real. It is for engineers building agents that need to read or move value on EVM chains, and who would rather expose a standard tool surface than hand-roll one. It is not a wallet, not a custody product and not a block explorer. The README describes it as a server that provides blockchain services across 60+ EVM-compatible networks, 34 mainnets and 26 testnets, with a unified interface.

## How the tool surface is wired: viem, zod and automatic ABI fetching

The dependency list tells most of the architecture story. @modelcontextprotocol/sdk handles the protocol and tool registration, viem ^2.39.3 does the chain access, zod ^3.24.3 validates tool inputs, and express ^4.21.2 backs an optional HTTP transport. The package exposes two entry points: src/index.ts for the stdio server, and src/server/http-server.ts for an HTTP variant, built separately by the build:http script.

The interesting design choice is ABI handling. Rather than asking the caller to supply a contract ABI, the server fetches it from the Etherscan v2 API across the supported networks, then parses and validates it to discover functions. That is why the README can promise write access to any state-changing function without advance ABI knowledge. The trade-off is a hard dependency on a third-party explorer API for contract interaction, and the README lists the Etherscan API key as optional but needed for ABI fetching.

ENS resolution works the same way at the edge of every tool. Any parameter that takes an Ethereum address also accepts a name, and the server resolves it before the call. The README uses vitalik.eth and 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 as the illustration. For reads this is convenience. For writes it is a place where a typo becomes a transfer to a name you did not intend, and the server does not appear to add a confirmation step of its own.

## Installing the server and making a first read call

The README recommends Bun 1.0.0 or higher, with Node.js 20.0.0 or higher as the fallback. Clone the repository and install dependencies with either package manager.

```bash
git clone https://github.com/mcpdotdirect/evm-mcp-server.git
cd evm-mcp-server
bun install
```

The npm path is the same command with npm install. To start the stdio server during development, the package script runs the TypeScript entry point directly.

```bash
bun run dev
```

For a first real use, register the server with an MCP client and ask it for a balance. The repository ships an inspector script that loads the built server, which is the quickest way to see the tool list and call one tool by hand before an agent touches it.

```bash
bun run build
npx @modelcontextprotocol/inspector node build/index.js
```

In the inspector you should see the tool registry populated from the 22 tools, with chain and address parameters and the ENS-capable fields. Read-only calls need no wallet configuration. Write operations and ABI fetching do: the README requires either EVM_PRIVATE_KEY or EVM_MNEMONIC plus EVM_ACCOUNT_INDEX for HD derivation, and an Etherscan API key for ABI fetching.

```bash
export EVM_PRIVATE_KEY="0x..."
export EVM_ACCOUNT_INDEX="0"
```

If you prefer the mnemonic route, set EVM_MNEMONIC to a 12 or 24 word BIP-39 phrase instead and use EVM_ACCOUNT_INDEX to pick the account. The README presents the mnemonic as the recommended option for HD wallets. Do not put a mainnet key in a shell you share with other tooling.

## Where the server is the wrong tool

The wallet configuration is the sharpest limitation. The server signs with a private key or mnemonic read from the environment. There is no mention of a hardware wallet, an external signer, a policy engine or a spend limit anywhere in the README. If your threat model says the signing key must never sit in the same process as the agent, this server does not meet it, and no amount of prompt engineering fixes that.

Two smaller constraints matter in practice. ABI fetching depends on the Etherscan v2 API, so contract interaction degrades on chains or contracts that explorer does not index, and the API key requirement turns a local tool into something with an external rate-limited dependency. And the README does not document rollback, transaction replacement or a confirmation policy for writes, so an agent that submits a transfer has no documented path to cancel it. Treat write tools as irreversible and gate them at the client.

The multi-chain breadth is also a surface, not a guarantee. The README lists the networks and states that chain information includes blockNumber, chainId and RPCs, but it does not document which RPC endpoint each chain uses by default or how to override it. Verify that before pointing the server at a chain where the default endpoint is unreliable.

## Compared with calling viem directly or using a wallet SDK

The honest alternative for many teams is viem itself. viem ^2.39.3 is already the dependency doing the work here; a small internal module that wraps createPublicClient and createWalletClient gives you the same reads and writes with no MCP layer, no tool schema, and no prompt library. You keep full control of signing and you can put whatever policy you like in front of a write. What you lose is the agent-facing interface: an LLM cannot discover or call your internal function unless you expose it, which is exactly the work this project has already done for 22 tools and 10 prompts.

The other alternative is a wallet SDK or a hosted wallet API, which keeps key material outside your process. That is a different answer to the same problem, and it is the right one when custody is the deciding factor. The EVM MCP Server's advantage is that reads are cheap and broad, spanning 34 mainnets and 26 testnets through one tool registry, while a wallet SDK typically targets the chains its vendor supports. Choose on that axis rather than on feature checklists.

## Maintenance, upgrades and the MIT licence

The repository is not archived. The last push was on 2026-08-01, and the most recent releases listed are v2.0.4, v2.0.3 and v2.0.2. The package version in package.json is 2.0.4, matching the newest release tag. The project uses conventional commits and a changelog script, so release history is generated rather than written by hand, and the version:patch, version:minor and version:major scripts suggest a conventional semver cadence.

The upgrade cost sits in two places. The MCP SDK is pinned at ^1.22.0 and viem at ^2.39.3, both caret ranges, so a fresh install can pull newer minor versions than the ones the release was cut against; the peer dependency on typescript ^5.8.2 is the only other version constraint. Because the tool surface is the API, a minor bump that renames or reshapes a tool will break agent prompts that reference it by name, and the README does not document a deprecation policy for tools.

The licence is MIT, stated in the README badge and the LICENSE file. That permits commercial use and modification with the copyright notice retained. It says nothing about the legal status of the transactions your agent sends, and nothing here is legal advice.

## Conclusion

Adopt it if you want an agent to read balances, blocks, receipts and contract state across many EVM chains, or to prepare token transfers and contract writes under supervision, and you are comfortable running a local MCP server with a funded key. Do not adopt it if you need an OS-level signer, a hardware wallet, or a permissioning layer between the model and the chain; this server signs with whatever key you put in the environment. Before wiring it into anything real, verify the exact tool schema with the MCP inspector, confirm the default RPC for your target chain, and decide whether the private key or the mnemonic path fits your key-management rules.

## FAQ

### What is the mcpdotdirect/evm-mcp-server?

It is a Model Context Protocol server that gives LLM agents tools for interacting with EVM-compatible blockchains. The README describes 22 tools and 10 prompts across 60+ networks, covering blockchain reads, token transfers and smart contract calls.

### Which EVM networks does the server support?

The README lists 34 mainnets and 26 testnets, including Ethereum, Optimism, Arbitrum, Base, Polygon, Avalanche, BSC, zkSync Era, Linea, Celo, Gnosis, Fantom, Scroll, Mantle, Blast, Zora and their testnet counterparts. Chain information exposed to tools includes blockNumber, chainId and RPCs.

### Does the server need a private key to work?

Only for write operations and ABI fetching. Read-only calls work without wallet configuration, while writes require either EVM_PRIVATE_KEY or EVM_MNEMONIC with EVM_ACCOUNT_INDEX, and ABI fetching needs an Etherscan API key.

### Can I use ENS names instead of addresses?

Yes. The README states that every tool accepting an Ethereum address also supports ENS names and resolves them behind the scenes, giving vitalik.eth as an example in place of the hexadecimal address.

## Sources

- [Issues](https://github.com/mcpdotdirect/evm-mcp-server/issues)
- [License: MIT](https://github.com/mcpdotdirect/evm-mcp-server/blob/main/LICENSE)
- [mcpdotdirect/evm-mcp-server on GitHub](https://github.com/mcpdotdirect/evm-mcp-server)
- [README](https://github.com/mcpdotdirect/evm-mcp-server/blob/main/README.md)
- [Releases](https://github.com/mcpdotdirect/evm-mcp-server/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mcpdotdirect-evm-mcp-server