stm32_buildLABSCO SUMMARY
The embedded loop — build, flash, read memory, talk over serial — driven from the conversation, on boards you can name.
Two details separate this from a wrapper around a command line. Nicknames bind to the physical MCU rather than the probe, so a name keeps meaning the same board after you move cables around. And serial_sequence exists because a model cannot time separate tool calls: sends, delays, expected responses and memory reads go into one call that runs with real timing. It is built around one specific bench — an ST-Link V3 mini with VCP on the header — and it gives the assistant unsandboxed access to the hardware attached to it.
What it is
A Python server that hands an assistant your STM32 toolchain: compile with CubeIDE's headless builder, flash over ST-Link SWD, open serial connections, and read or write memory by address or by variable name resolved from the ELF symbols.
What you get
- stm32_build compiles a project through the CubeIDE headless builder, stm32_flash writes an .elf, .bin or .hex over SWD, and stm32_build_and_flash covers both in the one step you usually want
- stm32_list_probes shows every connected board with its MCU ID, and stm32_set_nickname names a board by MCU UID or a probe by ST-Link serial number — board nicknames follow the physical chip across probe swaps, and any probe parameter accepts one
- stm32_board_info reads device ID, flash size and voltage straight off the ST-Link
- Serial work end to end: list the ports with ST-Link VCP ports marked by nickname, connect, send data and read the response, read what is buffered, disconnect
- serial_sequence puts several steps into one call — sends, delays in milliseconds, an expected response, webcam captures and SWD memory reads or writes — so timing happens inside a single tool call instead of across several the model cannot pace
- stm32_read_memory and stm32_write_memory take an address or a variable name looked up in the ELF symbols
- live_memory_start runs continuous background memory monitoring over SWD, live_memory_read returns the recent entries, and live_memory_stop ends the session
- The same code is available as CLI wrappers, and those builds queue behind an agent-driven build on the shared CubeIDE workspace lock rather than colliding with it
Requirements
Python 3.10 or newer, installed from the repository into a virtualenv — there is no published package. The real toolchain has to be present: STM32CubeIDE at /Applications/STM32CubeIDE.app on macOS or /opt/st/stm32cubeide_* on Linux, OpenOCD for flashing, memory access and live monitoring, the open-source stlink tools for probe enumeration, an ST-Link over USB, and a serial port. The author states plainly that this is not a sandbox: the assistant gets your compiler, debug probe and serial ports, and can flash firmware, overwrite memory and send arbitrary data to whatever is attached.
Setup effort
Build from source — git clone https://github.com/shieldyguy/stm32-mcp.git
USE CASES
01
Getting new firmware onto a board
One call compiles the project and flashes the result over SWD; the board info confirms which chip actually received it.
02
Working out what is plugged in right now
List the probes and boards with their MCU IDs, give them names that survive a cable swap, and see which serial ports belong to which.
03
Running a hardware test that depends on timing
serial_sequence schedules the sends, the millisecond delays, the expected replies and any memory reads as one executed sequence.
04
Watching a variable while the firmware runs
Start a background SWD monitor on the symbol, read the entries it has collected, and stop it when you have seen enough.
05
Poking at state without recompiling
Read or write memory by variable name rather than address, resolved from the ELF you just flashed.
06
Having two boards talk to each other
Open a connection to each, send from one and read on the other, all inside the same conversation.
17 tools
Listed in project docs. Your client may show a different list.
stm32_flashstm32_build_and_flashstm32_board_infostm32_list_probesstm32_set_nicknameserial_list_portsserial_connectserial_sendserial_readserial_disconnectserial_sequencestm32_read_memorystm32_write_memorylive_memory_startlive_memory_readlive_memory_stopBEFORE YOU INSTALL
What to know first
Tools you get
17 tools named in the project's documentation.
Requires
Python 3.10+
Where it runs
The documented client runs the server on your machine.
INSTALLATION
Connect your client
This one is built from source rather than installed with a single command.
Server setup
TERMINAL
git clone https://github.com/shieldyguy/stm32-mcp.git
cd stm32-mcp
python3 -m venv .venv
source .venv/bin/activate
pip install -e .
claude mcp add stm32 -- <YOUR_PATH_TO_STM32_MCP>/.venv/bin/python -m stm32_mcp.serverMCP Clients
Any MCP client
ANY MCP CLIENT · JSON
{
"mcpServers": {
"stm32": {
"command": "<YOUR_PATH_TO_STM32_MCP>/.venv/bin/python",
"args": [
"-m",
"stm32_mcp.server"
]
}
}
}
