安裝
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，以及先發現探針、後按需診斷；其它工作流若不在同一頁寫清，就不要外推。