Set target, build, flash, test is the cycle that eats an embedded day, and all four are here as tools with the ESP-IDF path selectable per call — which matters because embedded projects routinely pin different IDF versions. The project is upfront that it is a PoC and invites PRs for missing commands, so treat gaps as expected rather than as bugs.
An MCP server that consolidates ESP-IDF and related project commands so an LLM can drive an embedded workflow end to end. The project describes itself as a proof of concept for ESP-IDF workflows.
- Toolchain setup through ESP-IDF's own `install.sh` — `run_esp_idf_install`
- New project creation and target chip selection across esp32, esp32c3, esp32s3 and the rest — `create_esp_project`, `setup_project_esp_target`
- Incremental builds with build-time tracking, and support for custom `sdkconfig_defaults` files, several separated by semicolons — `build_esp_project`
- Serial port discovery and flashing to a connected device, with the port optional — `list_esp_serial_ports`, `flash_esp_project`
- Tests run with pytest-embedded support against a chosen target — `run_pytest`
- Per-project ESP-IDF versions: every tool takes an `idf_path` parameter, so different projects can use different installations without changing the environment
- Experimental automatic issue fixing based on build logs
Clone the repository — there is no published package — and point your client at it with `uv` or a Python interpreter, running `main.py` from the cloned directory. `IDF_PATH` is optional: set it to your ESP-IDF root and it becomes the default, or pass `idf_path` per call. ESP-IDF itself must be installed separately if you are not using the install tool; the project links Espressif's own getting-started guide. Flashing needs a physically connected ESP device.