安装
cargo build --release适合谁
如果你要把嵌入式板子的调试交给智能体，而不是先配一套完整的图形调试器，这个服务对得上。它是 Rust 写的 MCP 服务器，可通过 probe-rs 或 OpenOCD 的 GDB Remote Serial Protocol 做探针发现、目标控制、读内存、断点、刷写、RTT 和面向智能体的崩溃诊断。它也带一个小命令行和打包工作流，可以先不接 MCP 客户端。它不是芯片手册，也不会替你焊线。
官方说明在：
https://github.com/adancurusul/embedded-debugger-mcp
最重要的前提是：要做硬件操作，必须有兼容探针，或已有暴露 GDB 端口的 openocd，再加上可用的 SWD/JTAG 接线。官方点名 ST-Link、J-Link、DAPLink、Black Magic Probe 或受支持的 FTDI 探针；ESP32 可用 openocd-esp32。没有探针不要开始刷写。
3 分钟完成第一次尝试
只走官方推荐的一条路：克隆仓库后用 Cargo 发布构建。
先决条件：已安装 Rust / cargo。硬件操作另需上述探针或 OpenOCD。第一次只做发现，不要编程 flash。
先克隆：
https://github.com/adancurusul/embedded-debugger-mcp.git
安装命令：
cargo build --release
二进制在 target/release/embedded-debugger-mcp。
配置位置：MCP 客户端把命令设为 embedded-debugger-mcp serve。为了兼容，不带子命令直接运行该二进制，也会在 stdio 上提供 MCP。证据没有写出必须使用哪一个客户端，不要补名单。
低风险第一次调用：只做探针发现。这是枚举本机探针，不是停核，也不是刷写。若要碰目标，先确认接线无误。诊断工具 diagnose_fault 与 unwind_exception 会读取异常现场，仍可能影响正在跑的固件，第一次不要用。
成功信号：发布构建结束，客户端能拉起 serve，并且发现流程返回探针列表或明确的空列表。若只有 Cargo 失败，停在构建，不要改成 flash。
使用案例
案例一：做探针发现，确认 ST-Link、J-Link 或其它兼容器是否被看见。官方把 probe discovery 列为工具集的第一项。你能核对的是：列表是否出现你插上的探针。证据没有写发现工具的精确函数名和参数，缺的部分不要自造。
案例二：在已经连上目标后，用 diagnose_fault 或 unwind_exception 看崩溃。官方把这两项写成 crash diagnosis。适合板子已经停在异常、你需要智能体读故障上下文的时候。内存访问和 RTT 也在同一工具集里，但这一页没有展开读写宽度和缓冲格式。走到这里为止，只能确认诊断名字存在；flash programming 与 breakpoints 是有副作用的写入，不要当第一次例子。
使用边界
没有探针或没有 SWD/JTAG 接线，硬件操作做不了。OpenOCD 路径需要进程已在跑并露出 GDB 端口，例如 ESP32 用 openocd-esp32。刷写、断点和停核都会改变目标状态，不是零风险，更不能理解成不碰硬件或不读内存。
官方还提到 Cortex-M、RISC-V 与 Xtensa，但没有在这一页给出芯片清单和撤销步骤。本说明只覆盖 Cargo 发布构建、stdio serve，以及先发现探针、后按需诊断；其它工作流若不在同一页写清，就不要外推。