embedded-debugger

# Embedded Debugger Use the local `embedded-debugger-mcp` binary as the source of truth. Prefer CLI checks first, then MCP tools when an MCP client is available. ## Entry Decision 1. If the user has an MCP client configured, start or verify the server: `embedded-debugger-mcp serve` 2. If the user wants no MCP install, use CLI-first mode: `embedded-debugger-mcp doctor`, `embedded-debugger-mcp probes list`, and `embedded-debugger-mcp skill print-prompt`. 3. If hardware access is required, confirm the probe and target are connected before destructive actions such as flash erase or program. ## CLI Workflow Run these in order and report the exact outcome: ```bash embedded-debugger-mcp doctor embedded-debugger-mcp probes list embedded-debugger-mcp config show ``` Use JSON for automation: ```bash embedded-debugger-mcp doctor --json embedded-debugger-mcp probes list --json ``` ## Backends One tool set runs over two interchangeable engines, chosen at `connect`: - `backend: "probe-rs"` (default) — native probe-rs; supports flash and RTT. - `backend: "openocd"` (experimental) — talks to an already-running `openocd` over its GDB port via `openocd_address` (default `127.0.0.1:3333`). Use for chips probe-rs does not cover well (e.g. Xtensa ESP32 via openocd-esp32). Memory access and halt/run/step/reset are validated on real ESP32-S3; flash and RTT are not available on this backend. Register reads currently use ARM gdb register numbers, so PC/SP are wrong on...