Balances, ENS lookups, receipts and Multicall3 batching run against public RPC, so an agent can inspect chain state without ever holding a key. The moment you want transfer_native, write_contract or a signature, that same server needs a private key or mnemonic in its environment, and the tool list draws no line between the two halves at call time. ABI auto-fetch smooths over contracts you did not write, but it depends on ETHERSCAN_API_KEY and falls back to common functions when a contract is unverified.
An RPC and wallet client for EVM networks: chain and block reads, ERC20, ERC721 and ERC1155 balances, contract calls in both directions, and message signing.
- Network-level reads: chain id and current block, the list of supported networks, and base, standard and fast gas prices
- Balances for any address — native token, ERC20, and ERC1155 by token id — plus the allowance an owner has granted a spender
- ENS resolution in both directions, name to address and address back to name
- A transaction by hash with its receipt, confirmation status, gas used and logs, and a call that polls until the number of confirmations you set
- Contract interaction with the ABI fetched from a block explorer when you do not supply one: read-only calls, state-changing calls, and many reads batched into a single RPC request through Multicall3
- Transfers and approvals from the configured wallet — native token, ERC20, and the approval a DEX or lending protocol needs first
- Signatures from the configured wallet: an arbitrary message for SIWE-style authentication, or EIP-712 structured data for permits and meta-transactions
For the read half, a reachable network and nothing else. Transfers, approvals, write_contract and both signing tools need a wallet configured from a private key or mnemonic, and automatic ABI lookup needs ETHERSCAN_API_KEY.
One command — npx @mcpdotdirect/evm-mcp-server