ESP32 Simulator

esp32sim-mcp

Your agent writes ESP32 firmware, boots it and tests it. No board, no account.

A real Claude Code session, recorded live (only the idle tail is trimmed): it edits ESP-IDF's hello_world , builds it in Docker because ESP-IDF isn't installed, and checks the console in the emulator.

---

Coding agents are good at writing embedded C. They are blind when it comes to running it: without a board on the desk, "it compiles" is where the feedback loop ends.

esp32sim-mcp closes that loop. It gives Claude Code, Codex, Cursor or any MCP client a set of tools that boot the firmware the agent just built inside esp32sim, a local instruction-level ESP32 emulator, and hand back what the chip printed, whether it crashed, and what was on the display. The agent reads the result, fixes the code and tries again, the way you would with a board on the bench.

• 🔌 No hardware, no cloud. Everything runs on your machine. No account, no token, no board.
• 🧬 Real boot chain. Espressif's mask ROM, the ESP-IDF bootloader and your unmodified app, on ESP32-S3, C3, C6 and the classic ESP32.
• 📡 More than a console. Virtual WiFi access point with DHCP, DNS and NAT, buttons, rotary encoder, GPIO, UART input, touch, and display screenshots.
• 🧪 Assertions, not vibes. sim_expect returns pass/fail and the exact line that is missing, so the agent knows what to fix.
• ⚡ Fast. Emulation usually runs ahead of real time: on Apple silicon, 8 emulated seconds of a WiFi station joining a network take about 0.6 s.
• 🤖 Comes with a skill. init installs an agent skill that teaches the write → build → simulate → fix loop, including building in Docker when ESP-IDF is not installed.

Quickstart

npx -y esp32sim-mcp setup                      # emulator + mask ROMs, pinned and SHA-256 verified

cd your-esp-idf-project npx -y esp32sim-mcp init # registers the MCP server and the skill for your agents

Then ask your agent for something you can see on the serial console:

*Add a counter that prints once a second, build it, and check in the simulator that it reaches 5.*

Requirements: Node.js 22+, and ESP-IDF or Docker to build firmware. Prebuilt emulator binaries cover macOS (Apple silicon) and Linux (x64, arm64); see other platforms.

What the agent sees

From a real session, the agent calls:

{

"tool": "sim_expect", "projectDir": ".", "chip": "s3", "board": "none", "maxSeconds": 10, "patterns": ["Hello world!", "Counter: 1", "Counter: 2", "Counter: 3", "Counter: 4", "Counter: 5"] }

and gets back:

### Expect Test: ✅ PASSED

Matched 6 / 6 patterns.

• ✅ Matched (line 54): Hello world!
• ✅ Matched (line 55): Counter: 1 ...
• ✅ Matched (line 65): Counter: 5

Full UART Logs:

ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x1 (POWERON),boot:0xf (SPI_FAST_FLASH_BOOT) ...

When something goes wrong, it gets the panic instead (Guru Meditation Error, stack overflow, failed assert, heap corruption) with the log leading up to it, and the missing pattern spelled out.

Tools

All tools take a projectDir (the ESP-IDF build is found through build/flasher_args.json) or explicit appBin/bootloaderBin/ptableBin paths, plus chip, board and wifi (e.g. ssid=demo,psk=secret). Both UART0 and the USB-Serial/JTAG console are captured, so output shows up whichever one the project logs to.

How it works

flowchart LR

A["Coding agent (Claude Code, Codex, Cursor)"] -- "edits code, runs idf.py build (local or Docker)" --> B["ESP-IDF build/"] A -- "MCP: sim_expect, sim_run, ..." --> C["esp32sim-mcp"] C -- "flasher_args.json" --> B C -- "spawns" --> D["esp32sim emulator mask ROM → bootloader → app"] D -- "UART / USB-JTAG, panics, display, virtual WiFi" --> C C -- "pass/fail, logs, PNG" --> A

esp32sim-mcp is a thin, tested layer: it finds the build, translates tool calls into esp32sim's command line, separates and de-duplicates the two consoles, detects panics, and shapes the result for an agent. The emulation itself is esp32sim's work.

Use it in CI

The same checks run without an agent, with exit code 0 on pass and 1 on fail. A GitHub Actions job that builds your firmware and asserts its boot log:

jobs:

firmware: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v5
• uses: actions/setup-node@v5 with: node-version: 22
• name: Build run: docker run --rm -v "$PWD:/project" -w /project espressif/idf:v5.5.4 idf.py set-target esp32s3 build
• name: Install the emulator run: npx -y esp32sim-mcp setup
• name: Boot and check the console run: npx -y esp32sim-mcp expect --max-seconds 10 --pattern "app_main" "Counter: 5"

This is what this repository's own CI does with examples/hello-esp32, including a scripted button press.

All CLI commands

esp32sim-mcp setup                 # install emulator + ROMs (or: install-emulator, fetch-roms)

esp32sim-mcp init [--global] [--agent claude-code|codex|cursor|claude-desktop] [--dry-run] esp32sim-mcp run [-p dir] [--chip s3] [--board none] [--max-seconds 5] [--wifi ssid=x,psk=y] esp32sim-mcp expect --pattern "a" "b" [--unordered] [--script actions.txt] [...run options] esp32sim-mcp list [--chip c6] esp32sim-mcp doctor esp32sim-mcp serve # the MCP server (what agents launch)

Supported chips and boards

Use none for stock ESP-IDF projects. The virtual WiFi access point works on all four chips.

Agent setup

init detects the agents you have and configures each one. It runs in your firmware project by default; --global writes user-level settings instead.

Existing entries are kept, reruns are no-ops, and a config file that does not parse is left untouched.

Claude Code plugin. Instead of init, install the server and skill together as a plugin, for every project:

/plugin install esp32sim --marketplace stramanu/esp32sim-mcp

MCP registry. The server is published to the official MCP registry as io.github.stramanu/esp32sim-mcp. For any other MCP client:

{

"mcpServers": { "esp32sim": { "command": "npx", "args": ["-y", "esp32sim-mcp", "serve"] } } }

Other platforms

setup installs prebuilt binaries on macOS arm64 and Linux x64/arm64. They are built from source by this repository's emulator workflow with signed build provenance (gh attestation verify -R stramanu/esp32sim-mcp). Elsewhere, build esp32sim with Cargo (rustup), pinned to the commit this release is tested against:

cargo install --locked --git https://github.com/mikroverk/esp32sim --rev f535f3b42293a76ab64c231a0425f35857ab6cf1 esp32sim

npx esp32sim-mcp fetch-roms

ESP32SIM_PATH points at an emulator binary elsewhere and ESP32SIM_ROM_DIR at another ROM directory; ROMs inside an ESP-IDF install are found automatically.

How it compares

esparagus is the natural next step: simulate first with esp32sim-mcp, then confirm on a real board.

Limitations

• An emulator is not silicon. Peripherals esp32sim does not model, RF timing and Bluetooth are out of reach here; confirm on hardware before you ship.
• The agent builds the firmware itself (idf.py, locally or in Docker); the MCP server does not compile.
• Windows is untested.

Contributing

Issues and pull requests are welcome. See CONTRIBUTING.md for the development setup and how the end-to-end tests run against the real emulator, and CHANGELOG.md for what changed.

Credits

• esp32sim by Joakim Eriksson, Alice and Mattia Fiumara: the emulator that does the real work (MIT).
• Espressif: ESP-IDF and the mask ROM ELFs (Apache-2.0).
• Model Context Protocol.

License

MIT © Emanuele Strazzullo