\n<\/p>\n
npx pio-mcp dashboard<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
That’s the install. Open a terminal anywhere \u2014 your laptop, a fresh VM, a coworker’s machine \u2014 type one line, and you get a React dashboard wired to PlatformIO Core. From there an LLM can compile firmware, flash it to a real board, and stream serial back to the same browser tab.<\/p>\n
platformio-mcp v2.0.0 shipped to npm. Here’s why and how.<\/p>\n
The gap<\/p>\n
LLMs are stupidly good at writing firmware. Hand Claude a datasheet and it’ll spit out C++ that compiles. Hand it the FreeRTOS docs and it’ll wire up a queue without breaking a sweat.<\/p>\n
The next step always falls apart.<\/p>\n
“Great, now flash it to the ESP32 sitting on my desk.”<\/p>\n
You get back a markdown wall of “first install pyenv, then bootstrap a venv, then pip install platformio, then check your USB-C cable supports data, then make sure the right udev rule is in place on Linux, then…” It’s a setup-doc generator. The agent has read every PlatformIO tutorial ever written. It still can’t push bytes to flash memory because it has no hands.<\/p>\n
MCP is the hands. The agent calls a tool, the tool runs on your machine, the result comes back. PlatformIO Core is already a CLI that knows how to talk to ~1,000 boards across 30+ platforms (ESP32-S3, RP2040, STM32H7, nRF52840, ATmega328P, Teensy 4.1, SAMD21, ATtiny85, and so on). I exposed it through MCP. That’s the whole product.<\/p>\n
What v2.0.0 actually does<\/p>\n
Nine MCP tools. Each one is a thin wrapper around a pio subcommand:<\/p>\n
list_boards \u2192 pio boards
\ninit_project \u2192 pio project init
\nbuild_project \u2192 pio run (background mode + status polling)
\nupload_firmware \u2192 pio run –target upload (optional start_monitor)
\nlist_devices \u2192 pio device list
\nserial_monitor \u2192 pio device monitor (non-blocking, streamed)
\nsearch_libraries \u2192 pio pkg search
\ninstall_library \u2192 pio pkg install
\nlist_libraries \u2192 pio pkg list
\nget_dashboard_url \u2192 returns localhost URL with bound auth token<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Plus init_project, the unsung hero. PlatformIO project scaffolding is the thing agents got wrong every single time before this \u2014 they’d hand-write a platformio.ini with three subtle bugs in the board_build section. The MCP tool just shells out to pio project init and the bugs vanish.<\/p>\n
The demo that closes the deal<\/p>\n
Real prompt, real ESP32, real flash:<\/p>\n
> Initialize a new Arduino project for an ESP32 Dev Board in \/tmp\/esp32-blink.
\n Build it, flash it, and start the serial monitor.<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The agent’s tool calls, in order:<\/p>\n
list_boards { filter: “esp32” } \u2192 esp32dev
\ninit_project { board: “esp32dev”, framework: “arduino”,
\n projectDir: “\/tmp\/esp32-blink” }
\nbuild_project { projectDir: “\/tmp\/esp32-blink” } \u2192 SUCCESS
\nupload_firmware { projectDir: “\/tmp\/esp32-blink”,
\n start_monitor: true } \u2192 flashed<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
End-to-end on a clean machine: ~90 seconds. Most of that is the PlatformIO toolchain pulling esptool and the Espressif SDK on first run. Subsequent flashes are sub-10s.<\/p>\n
Install in one command<\/p>\n
We make it easy to integrate PIO MCP into your choice of coding agent. v2.0.0 ships a one-shot installer:<\/p>\n
npx platformio-mcp install –cline # Cline (VS Code extension or CLI)
\nnpx platformio-mcp install –claude # Claude Desktop
\nnpx platformio-mcp install –vscode # VS Code native MCP support
\nnpx platformio-mcp install –antigravity # Google Antigravity<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Each installer:<\/p>\n
Resolves the host’s config path per OS. macOS goes to ~\/Library\/Application Support, Windows reads %APPDATA%, Linux falls back to ~\/.config. There’s a 9-line appDataDir() helper that does the dispatch.
\nReads the existing config if one’s already there.
\nIf the JSON is corrupted, copies it to .bak before rewriting. I learned this the hard way.
\nIdempotently merges an mcpServers.platformio block. Re-running the installer is a no-op.
\nPrints the path it touched so you can grep for it later.<\/p>\n
For any other MCP host, this is the manual config block:<\/p>\n
{
\n “mcpServers”: {
\n “platformio”: {
\n “command”: “npx”,
\n “args”: (“-y”, “platformio-mcp”, “–open-dashboard-on-start”)
\n }
\n }
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The dashboard<\/p>\n
The dashboard is the part nobody asks for and everybody uses once they have it.<\/p>\n
Reason: build output is the worst possible thing to feed back to an LLM. A clean pio run for an ESP32 project is 40+ kilobytes of toolchain noise \u2014 arm-none-eabi-gcc flags, linker incantations, every single .o file. Pour that into the agent’s context and you’ve spent a third of your token budget on text the agent doesn’t need.<\/p>\n
So the MCP tools return short, structured summaries to the LLM. The full output streams over Socket.io to a React dashboard the human can watch:<\/p>\n
A per-process random UUID is injected as PORTAL_AUTH_TOKEN at boot. Every HTTP request and every Socket.io connection requires it. The dashboard URL looks like http:\/\/localhost:8080?token= and that token isn’t in any config file or env var the LLM has access to. If you launch the dashboard, only you (and the agent that spawned it) can hit the API.<\/p>\n
The auto-launch is gated behind –open-dashboard-on-start (or the PIO_MCP_OPEN_DASH_ON_START=true env var). Browser launch goes through the open package, so the same call works on macOS, Linux, and Windows. The previous version had a hardcoded exec(‘open …’) that only fired on macOS \u2014 patched in v2.0.0.<\/p>\n
Things I’m proud of that nobody will notice<\/p>\n
The tarball is 499 kB. 114 files. build\/ + web\/dist\/ + scripts\/installers\/ + LICENSE + README. No node_modules, no tests, no web\/src\/. The minified UI bundle is 921 kB \/ 291 kB gzip on its own; everything else is rounding error.<\/p>\n
prepublishOnly runs the full TypeScript build, the Vite UI build, and a smoke check that asserts build\/index.js, web\/dist\/index.html, and scripts\/installers\/index.js exist before npm allows the publish to proceed. Hard to ship a broken artifact.
\nWorkspace state is mediated through proper-lockfile. Two agent processes can’t race each other on the same project. If you’ve ever had two MCP servers fight over the same serial port, you know why this matters.
\nThe pio-mcp alias package is 842 bytes. Three files: a 283-byte bin.js that does import(“platformio-mcp”), a package.json with one dependency, a README. Same binary, shorter to type.
\nThe default npx platformio-mcp (no subcommand) still boots the MCP stdio server. Existing configs that point at build\/index.js keep working unchanged. v2 is additive.<\/p>\n
Get started in five seconds<\/p>\n
# Open the dashboard right now. No clone, no build, no install.
\nnpx pio-mcp dashboard<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
# Wire it into your AI agent of choice.
\nnpx platformio-mcp install –cline
\nnpx platformio-mcp install –claude
\nnpx platformio-mcp install –vscode
\nnpx platformio-mcp install –antigravity<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Repo: github.com\/jl-codes\/platformio-mcpnpm: platformio-mcp \u00b7 pio-mcpRelease notes: v2.0.0<\/p>\n
I’m @forkbombETH on X. Issues and PRs welcome on GitHub. If you build something cool with this, lmk.<\/p>\n
npx pio-mcp dashboard<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
A huge warm thank you to Matt Mcneill for being an amazing collaborator and pushing for the features that make v2 amazing!<\/p>\n