Embedded Debugger MCP: agents on a debug probe

When firmware lands in a HardFault, the routine is to open the IDE, halt the core, decode CFSR by hand and hunt addresses in a map file. Embedded Debugger MCP lets an agent do that through the debug probe itself: halt the core, read registers and memory, map the crash backtrace to source lines, and hand the evidence to the model. It’s written in Rust on the official MCP Rust SDK and had about 200 stars as of 2026-10-06.

What it does

• Probes and target control: list_probes finds attached probes, connect opens a session on a chip, and halt, run, step and reset control the core.
• Memory and breakpoints: read_memory, write_memory, and hardware breakpoints with set_breakpoint and clear_breakpoint.
• Flashing: flash_program takes ELF, HEX or BIN, and run_firmware erases, programs, resets and attaches RTT in one step.
• RTT: read and write SEGGER RTT channels for firmware logs or commands.
• Crash diagnosis: diagnose_fault reads Cortex-M fault registers (CFSR, HFSR, MMFAR, BFAR and more) plus PC, SP and LR in one call; unwind_exception returns a DWARF backtrace with file and line per frame.

Who it’s for

• Firmware engineers on STM32, nRF and other Cortex-M parts who want Claude Code to flash, read logs and investigate crashes after each change.
• RISC-V and ESP32 developers, who can connect through the OpenOCD backend.

Setup

Needs a stable Rust toolchain and a probe-rs compatible probe (ST-Link, J-Link, DAPLink and others). Build from source:

git clone https://github.com/adancurusul/embedded-debugger-mcp.git
cd embedded-debugger-mcp
cargo build --release

Then point your client at the binary:

{
  "mcpServers": {
    "embedded-debugger": {
      "command": "/path/to/embedded-debugger-mcp/target/release/embedded-debugger-mcp",
      "args": ["serve"],
      "env": { "RUST_LOG": "info" }
    }
  }
}

Our take

Embedded MCP servers are scarce, and this one is solid: every tool maps to a real probe operation, crash diagnosis reports evidence rather than asserting a root cause, and a doctor command checks the setup before any client is involved. It changes hardware state directly, but the defaults are cautious: flash erase and memory writes stay off until you enable them in the config, and firmware paths can be limited to an allowlist. The OpenOCD backend is experimental, PC and SP read wrong on Xtensa chips like the ESP32, and fault diagnosis is Cortex-M only. The releases page has no prebuilt binaries yet, so you compile it yourself. MIT licensed.