Embedded Debugger MCP: Embedded-Boards über eine Sonde debuggen

Für wen

Wenn ihr das Debuggen eines Embedded-Boards einem Agent überlassen wollt, statt zuerst einen vollständigen grafischen Debugger zu konfigurieren, passt dieser Dienst. Es ist ein in Rust geschriebener MCP-Server, der über probe-rs oder OpenOCDs GDB Remote Serial Protocol Sondenentdeckung, Zielsteuerung, Speicherlesen, Breakpoints, Flashen, RTT und agentenorientierte Absturzdiagnose kann. Dazu gibt es eine kleine Kommandozeile und einen Pack-Workflow, noch ohne MCP-Client. Das ist kein Chip-Handbuch und lötet keine Leitungen.

Offizielle Hinweise:

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

Wichtigste Voraussetzung: Hardwarearbeit braucht eine kompatible Sonde oder ein bereits laufendes openocd mit GDB-Port plus nutzbare SWD/JTAG-Verdrahtung. Offiziell genannt: ST-Link, J-Link, DAPLink, Black Magic Probe oder eine unterstützte FTDI-Sonde; ESP32 kann openocd-esp32 nutzen. Ohne Sonde nicht flashen.

Erster Versuch in 3 Minuten

Nur den offiziell empfohlenen Weg: Repo klonen, dann Cargo-Release-Build.

Voraussetzungen: Rust / cargo installiert. Hardwarearbeit braucht zusätzlich die Sonde oder OpenOCD. Der erste Versuch ist nur Entdeckung — flash nicht programmieren.

Zuerst klonen:

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

Installationsbefehl:

cargo build --release

Die Binärdatei liegt unter target/release/embedded-debugger-mcp.

Konfiguration: Der MCP-Client setzt den Befehl auf embedded-debugger-mcp serve. Zur Kompatibilität liefert dasselbe Binary ohne Unterbefehl MCP auf stdio. Die Belege nennen keinen Pflicht-Client; keine Namensliste ergänzen.

Risikoarmer erster Aufruf: nur Sondenentdeckung. Das zählt lokale Sonden auf, ist kein Halt und kein Flash. Wer das Ziel berührt, prüft zuerst die Verdrahtung. Die Diagnosewerkzeuge diagnose_fault und unwind_exception lesen die Ausnahmestelle und können laufende Firmware trotzdem beeinflussen — beim ersten Versuch nicht nutzen.

Erfolgssignal: Der Release-Build endet, der Client startet serve, und die Entdeckung liefert ein Sondeninventar oder eine klar leere Menge. Scheitert nur Cargo, beim Build stehen bleiben, nicht auf flash wechseln.

Anwendungsfälle

Fall 1: Sondenentdeckung und prüfen, ob ST-Link, J-Link oder ein anderes kompatibles Gerät gesehen wird. Offiziell steht probe discovery zuerst im Werkzeugsatz. Prüfbar ist, ob das Inventar die gesteckte Sonde zeigt. Die Belege nennen weder den genauen Funktionsnamen noch Parameter; Fehlendes nicht erfinden.

Fall 2: Nach bestehender Zielverbindung diagnose_fault oder unwind_exception für einen Absturz. Offiziell heißt das crash diagnosis. Passt, wenn das Board schon in einer Ausnahme steht und der Agent den Fehlerkontext lesen soll. Speicherzugriff und RTT liegen im selben Satz, aber diese Seite entfaltet weder Zugriffsbreiten noch Pufferformate. Bis hier ist nur die Existenz der Diagnosenamen sicher. flash programming und breakpoints sind Schreibvorgänge mit Nebenwirkungen — nicht als erstes Beispiel.

Grenzen

Ohne Sonde oder ohne SWD/JTAG-Verdrahtung geht Hardwarearbeit nicht. Der OpenOCD-Weg braucht einen bereits laufenden Prozess mit GDB-Port, etwa ESP32 mit openocd-esp32. Flashen, Breakpoints und Halt ändern den Zielzustand. Das ist nicht risikofrei und nicht „ohne Hardware“ oder „ohne Speicherlesen“.

Offiziell werden auch Cortex-M, RISC-V und Xtensa genannt, aber diese Seite hat kein Chipinventar und keine Rücknahme. Diese Anleitung deckt nur Cargo-Release-Build, stdio serve sowie zuerst Entdeckung, dann Diagnose bei Bedarf. Andere Abläufe, die nicht auf derselben Seite stehen, nicht fortschreiben.