evm-recon-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_chainsA | List built-in EVM chains with their chain IDs and explorers. Any other network works by passing rpc_url. |
| get_bytecodeA | Fetch a contract's deployed runtime bytecode via eth_getCode. Returns size and hex. Empty result means the address is an EOA or has no code. |
| disassembleA | Disassemble bytecode into opcodes with program counters. Supply either an on-chain address or a raw hex string. Crucially, this also validates statically-resolvable jump targets: a PUSH followed immediately by JUMP/JUMPI whose target is not a JUMPDEST will halt exceptionally at runtime (revert, all gas consumed). Those are reported separately as |
| read_storageA | Read a raw storage slot via eth_getStorageAt. Returns the 32-byte word plus uint and address interpretations. |
| compute_storage_slotB | Derive storage slots. kind=mapping: keccak256(pad32(key).pad32(slot)). kind=nested_mapping: applied left to right. kind=array: keccak256(pad32(slot))+index. kind=keccak_words: keccak256 over concatenated 32-byte words, which is what hand-written assembly does when it MSTOREs values and hashes the region. kind=keccak_utf8 / keccak_hex: plain hashing. |
| decode_calldataA | Split calldata into a 4-byte selector and 32-byte words, flag word values that look like addresses, and name the function when the selector is a well-known one. |
| function_selectorA | Compute 4-byte selectors from canonical signatures, e.g. transfer(address,uint256). |
| eth_callA | Simulate a call with eth_call and report whether it returned or reverted. Nothing is broadcast and no key is used. Useful for probing which calldata and value combinations a contract accepts. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct recon activity: chains, bytecode, disassembly, storage slots, slot derivation, calldata decoding, selector computation, and call simulation. No two tools overlap in purpose; even the selector-related tools (decode_calldata and function_selector) serve clearly different functions.
Most tools follow a verb_noun pattern (list_chains, get_bytecode, read_storage, compute_storage_slot, decode_calldata). Minor deviations exist with disassemble (bare verb) and function_selector (noun form), but these are still readable and do not introduce confusion.
8 tools is well-scoped for EVM reconnaissance. Each tool earns its place and covers a distinct layer of contract analysis without redundancy or sprawl.
The set covers the core recon workflow: fetch bytecode, disassemble/validate, inspect storage, derive slots, decode calldata, compute selectors, and simulate calls. Minor gaps exist (e.g., no balance/transaction fetching), but they are outside the apparent specialization of smart-contract reconnaissance.