インストール
cargo build --release向いている人
組込みボードのデバッグを、先に一式の GUI デバッガを組む代わりにエージェントへ渡したい人に合う。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 に変えてはいけない。
利用ケース
ケース1：プローブ発見をし、ST-Link、J-Link、その他互換器が見えるか確認する。公式は probe discovery をツール集の先頭に置く。確認できるのは、刺したプローブが一覧に出るか。根拠は発見ツールの正確な関数名と引数を書いていない。欠けた部分を作ってはいけない。
ケース2：ターゲット接続後に 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、先にプローブ発見・必要なら診断だけ。他ワークフローが同じページに無ければ外へ広げてはいけない。