Esp MCP

What horw/esp-mcp MCP server does

The horw/esp-mcp MCP server brings common ESP-IDF operations into an MCP tool interface. It is intended for ESP32-series development workflows where an LLM or other MCP client needs to create projects, select a chip target, compile firmware, locate connected devices, flash firmware, or run tests.

The project is described as a proof of concept. Its current scope centers on commands commonly used during setup, build, and device programming rather than providing a complete interface to every ESP-IDF feature. Automatic issue fixing based on build logs is listed as experimental.

How it works

The server receives tool calls from a configured chatbot or agent and runs the corresponding local development commands. Examples include invoking ESP-IDF's project commands for building, target selection, and flashing, along with pytest for test execution. This means the host must have the relevant ESP-IDF installation, tools, project files, and device access available.

ESP-IDF location handling is flexible. A call can provide an idf_path value to select a particular framework installation, allowing different projects to use different ESP-IDF versions. When that parameter is omitted, the server can use the IDF_PATH environment variable if it is set.

Setup and configuration

The repository is intended to be cloned locally and then registered as an MCP server in the selected chatbot or agent. Because the example uses paths that must be replaced for each machine, the exact command depends on the local Python or uv installation and repository location.

IDF_PATH is optional. Set it to the root of an ESP-IDF installation when a default framework path is useful; individual tool calls can override it with idf_path. The host also needs the ESP-IDF dependencies and toolchain required by the requested operation. The server includes a tool for installing those dependencies through ESP-IDF's install.sh.

Tools and capabilities

The horw/esp-mcp MCP server currently includes tools for:

• Installing ESP-IDF dependencies and the toolchain.
• Creating a new ESP-IDF project.
• Selecting targets such as esp32, esp32c3, and esp32s3.
• Building projects with incremental build support.
• Listing serial ports available to ESP devices.
• Flashing built firmware, with an optional port selection.
• Running pytest with pytest-embedded support for ESP-IDF projects.

Build operations can accept multiple SDK configuration defaults in a semicolon-separated value, such as a base defaults file and a CI-specific defaults file. The project also records build time, which can help observe build performance.

Limitations and notes

This is a PoC, so coverage of ESP-IDF workflows is limited to the tools currently implemented in main.py. Flashing and testing depend on the host's ESP-IDF installation and, where applicable, a connected ESP device and accessible serial port.

Automatic build-issue remediation is experimental rather than a general guarantee of successful fixes. The project invites contributions for missing commands, while features such as monitoring and menuconfig remain future work.