MCP

Embedded Debugger MCP: debug embedded boards through a probe

For discovering a debug probe before halt or flash. You need a probe-rs compatible probe or a running OpenOCD, and the first try must not program flash.

Official source · embedded-debugger-mcp

Install

cargo build --release

Who it's for

If you want an agent to debug an embedded board instead of first configuring a full graphical debugger, this service matches. It is a Rust MCP server that can do probe discovery, target control, memory reads, breakpoints, flashing, RTT, and agent-oriented crash diagnosis through probe-rs or OpenOCD’s GDB Remote Serial Protocol. It also ships a small command line and a packaging workflow you can use before attaching an MCP client. It is not a chip manual and will not solder wires for you.

Official notes:

https://github.com/adancurusul/embedded-debugger-mcp

Main prerequisite: hardware work needs a compatible probe, or an already running openocd that exposes a GDB port, plus usable SWD/JTAG wiring. Official text names ST-Link, J-Link, DAPLink, Black Magic Probe, or a supported FTDI probe; ESP32 can use openocd-esp32. Without a probe, do not start flashing.

First try in 3 minutes

Use one official path: clone the repo, then do a Cargo release build.

Prerequisites: Rust / cargo installed. Hardware work also needs the probe or OpenOCD above. The first try is discovery only — do not program flash.

Clone first:

https://github.com/adancurusul/embedded-debugger-mcp.git

Install command:

cargo build --release

The binary is at target/release/embedded-debugger-mcp.

Where to configure: the MCP client sets the command to embedded-debugger-mcp serve. For compatibility, running the binary with no subcommand also serves MCP on stdio. The evidence does not say which client is required; do not add a roster.

Low-risk first call: probe discovery only. That enumerates local probes; it is not a halt and not a flash. If you will touch the target, confirm the wiring first. Diagnostic tools diagnose_fault and unwind_exception read the exception site and can still affect running firmware — do not use them on the first try.

Success signal: the release build finishes, the client can start serve, and discovery returns a probe inventory or a clearly empty set. If only Cargo fails, stop at the build; do not switch to flash.

Use cases

Case 1: do probe discovery and confirm whether an ST-Link, J-Link, or another compatible probe is seen. Official text puts probe discovery first in the tool set. What you can check is whether the inventory shows the probe you plugged in. The evidence does not write the exact discovery function name or parameters; do not invent the missing parts.

Case 2: after the target is already connected, use diagnose_fault or unwind_exception to inspect a crash. Official text writes these as crash diagnosis. This fits when the board is already stopped in an exception and you need the agent to read fault context. Memory access and RTT are in the same tool set, but this page does not expand read/write widths or buffer formats. Up to here you can only confirm the diagnosis names exist. flash programming and breakpoints are writes with side effects — do not use them as the first example.

Limits

Without a probe or without SWD/JTAG wiring, hardware work cannot proceed. The OpenOCD path needs a process already running and exposing a GDB port, for example ESP32 with openocd-esp32. Flashing, breakpoints, and halt change target state. That is not zero risk, and it is not “no hardware touch” or “no memory reads.”

Official text also mentions Cortex-M, RISC-V, and Xtensa, but this page has no chip inventory and no undo steps. This guide only covers the Cargo release build, stdio serve, discover-first then diagnose on demand. If another workflow is not spelled out on the same page, do not extrapolate.