Show HN: Stm32-MCP – let AI build, flash, & communicate with hardware

MCP server that lets Claude Code build, flash, and communicate with STM32 hardware. stm32-mcp is pretty specific to how I tend to approach hardware development, but it is likely useful to others, too! It could be massaged to fit lots of workflows, but this is laser focused on mine (stlink-v3 mini, VCP on that header, STM32 microcontroller). You can do things like: me: hey who is plugged in right now? claude: two unnamed probes connected to two unnamed PCBs me: k ask them who they are and give them a nickname based on their response claude: got it, do you want to nickname the probes too? your boards are 'doorbell A' and 'synthesizer B' me: yep, I put paint marker on those probes. call doorbell's 'blue' and the synth's 'red' claude: done. what's next? me: give them both VCP commands so they can talk to each other, then have the doorbell ask the synth on a date claude: thinking... done, synth declined. plenty of fish in the sea, doorbell! MCP (Model Context Protocol) is an open standard that lets AI assistants like Claude use external tools. This server gives Claude the ability to compile your firmware, flash it to a board, talk to it over serial, and read memory via SWD. It is flexible and conversational. Warning This server gives an AI direct access to your compiler, debug probe, and serial ports. It can flash firmware, overwrite memory, and send arbitrary data to your hardware. This is powerful and useful, but it is not a sandbox. Know what's connected before you let it rip. - STM32CubeIDE installed at /Applications/STM32CubeIDE.app (macOS) or/opt/st/stm32cubeide_* (Linux) - Python 3.10+ - OpenOCD ( brew install open-ocd ) — for flash, memory read/write, and live monitoring - open-source stlink tools ( brew install stlink ) — for probe enumeration - ST-Link connected via USB (for flash/board info) - Serial port available (ST-Link VCP or USB-UART adapter) 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 -- /path/to/stm32-mcp/.venv/bin/python -m stm32_mcp.server Add to your project's .claude/settings.json or .claude.json : { "mcpServers": { "stm32": { "command": "/path/to/stm32-mcp/.venv/bin/python", "args": ["-m", "stm32_mcp.server"] } } } | Tool | Description | |---|---| stm32_build | Compile firmware using CubeIDE headless builder | stm32_flash | Flash .elf/.bin/.hex to board via ST-Link SWD | stm32_build_and_flash | Build + flash in one step (the 90% case) | stm32_board_info | Read ST-Link/MCU info (device ID, flash size, voltage) | | Tool | Description | |---|---| stm32_list_probes | Show all connected boards with nicknames and MCU IDs | stm32_set_nickname | Name a board (by MCU UID) or probe (by ST-Link SN) | Board nicknames follow the physical MCU (persist across probe swaps). Probe nicknames follow the ST-Link hardware. Use nicknames in any probe parameter across all tools. | Tool | Description | |---|---| serial_list_ports | List serial ports (marks ST-Link VCP ports with nicknames) | serial_connect | Open a serial connection | serial_send | Send data and read response | serial_read | Read buffered serial data | serial_disconnect | Close a serial connection | serial_sequence | Run multi-step send/delay sequences in one call | | Tool | Description | |---|---| stm32_read_memory | Read memory by address or variable name (from ELF symbols) | stm32_write_memory | Write memory by address or variable name | live_memory_start | Start continuous background memory monitoring via SWD | live_memory_read | Read recent entries from a live memory session | live_memory_stop | Stop a live memory session | serial_sequence runs multiple send and delay steps in a single tool call with real timing between steps — no tool-call overhead. This is critical for timing-sensitive hardware test sequences. [ { "send": "SIM_LEFT", "to": "/dev/cu.usbmodem11202" }, { "delay_ms": 500 }, { "send": "GET_BLINK_STATE", "to": "/dev/cu.usbmodem11402", "expect": "BLINK" }, { "send": "SET_BRAKE_ON", "to": "/dev/cu.usbmodem11402", "read_timeout": 1.0, "line_ending": "lf" } ] - Send step: {send, to, expect?, read_timeout?, line_ending?} —to is the port path fromserial_connect - Delay step: {delay_ms} — realtime.sleep() , not tool-call round-trips on_failure :"continue" (default) runs all steps regardless."stop" aborts on first failed assertion.filter_responses : Whentrue ,expect patterns match only> -prefixed VCP response lines (ignores debug noise). Step 1 [/dev/cu.usbmodem11202] SEND: SIM_LEFT Response: >OK:SIM_LEFT Step 2 DELAY: 500ms Step 3 [/dev/cu.usbmodem11402] SEND: GET_BLINK_STATE Response: >BLINK_STATE:BLINK Expect "BLINK": PASS Summary: 2/2 sends OK, 1/1 assertions PASS Monitor firmware variables in real time via SWD, without modifying firmware or using serial. OpenOCD runs as a persistent subprocess and polls variables over its built-in TCL socket. live_memory_start( variables='["blink", "ts"]', # symbol names from ELF elf_path="