J-Link MCP

jlink-mcp

AI にシリコンへ触れる手を与えましょう。
SEGGER J-Link プローブを通じて、LLM が組み込みデバイスをデバッグできる MCP サーバーです。

---

動作を見る

実際の nRF52840-DK に対する、実際の MCP ツール呼び出しです。自分で再現するには、npm run demo を実行してください。

ファームウェアがクラッシュしました。ツールを 1 回呼び出すだけです。

> diagnose_crash

## Crash Diagnosis

### CPU State
Core: PC=0x000000B8 SP=0x2003FFA8 R0=0x0000000A R1=0x000007FF R2=0x00000001 ...
Status: XPSR=0x21000003 CONTROL=0x00000000 PRIMASK=0x00000000 ...
Stack: MSP=0x2003FFA8 PSP=0x00000000

⚠ CPU is in exception handler (IPSR=0x00000003)

### Fault Registers
CFSR=0x01000000 HFSR=0x40000000 DFSR=0x00000000 MMFAR=0xe000edf8 BFAR=0xe000edf8

### Decoded Faults
## UsageFault (UFSR):
  - UNALIGNED: Unaligned memory access
## HardFault (HFSR):
  - FORCED: Forced HardFault (escalated from configurable fault)

### Exception Stack Frame
  R0    = 0x0000000A     R1  = 0x000007FF
  R12   = 0x00000000     LR  = 0x000001F5
  PC    = 0x00000254     xPSR = 0x21000000

→ Faulting instruction at PC=0x00000254

### Recent Errors/Warnings from RTT
  [WRN] sensor_drv: sample out of range, clamping seq=2

フォルトをデコードし、例外フレームを巻き戻して、フォルトを起こした命令を特定し、デバイス自身のログと照合します。CFSR のビット 24 の意味を調べるために、人がデータシートを読む必要はありません。すべて 1 回の呼び出しで完了します。

シリコンのことも把握しています

ターゲットの CMSIS-SVD ファイルを指定すると、周辺機器のレジスターが単なる 16 進数ではなくなります。

> read_peripheral FICR

FICR @ 0x10000000
INFO.PART @ 0x10000100 = 0x00052840  (read-only)
  [31:0]    PART             0x52840 → N52840
INFO.RAM @ 0x1000010C = 0x00000100  (read-only)
  [31:0]    RAM              0x100 → K256
INFO.FLASH @ 0x10000110 = 0x00000400  (read-only)
  [31:0]    FLASH            0x400 → K1024

0x400 は 1024 KB のフラッシュを意味しますが、それを知っている場合に限ります。ビット配置を LLM が推測することは、まさにこのツールが防ぐ失敗です。アドレスはベンダー自身の記述から取得し、意味はその列挙値から取得します。

どちらの実行例も、このプロジェクトのハードウェアテストスイートで nRF52840-DK を使って得られた出力そのままです。

これは何ですか？

jlink-mcp は、Model Context Protocol を使用して、SEGGER J-Link デバッグプローブ経由で AI アシスタント（Claude、Copilot など）を組み込みハードウェアに接続します。

J-Link コマンドを手動で入力する代わりに、AI アシスタントは次の操作を行えます。

• レジスターとメモリーを読み取ることで、デバイスの状態を把握します
• ファームウェアを書き込み、デバイスをリセットします
• RTT ログをストリーミングし、レベル／モジュール／正規表現で検索します
• ARM Cortex-M のフォルトレジスターを自動デコードして、クラッシュを診断します
• 実行を制御します — 停止、ステップ実行、再開、ブレークポイント
• GDB サーバーを起動して、完全なデバッグセッションを行います

OpenOCD（ST-Link、CMSIS-DAP、FTDI）および Black Magic Probe バックエンドにも対応しています。

インストール

SEGGER J-Link ソフトウェアが必要です — このサーバーが操作するソフトウェアです — ARM Cortex-M ターゲットに接続されたプローブと、Node 18 以降も必要です。他のバックエンドの場合は、代わりに OpenOCD または arm-none-eabi-gdb が必要です。

Claude Code — プラグインマーケットプレイスからインストールします。サーバーとともに embedded-debugging スキルも導入されるため、アシスタントがハードウェアについて推測するのを防げます。

/plugin marketplace add Klievan/jlink-mcp
/plugin install jlink-mcp

その他のエージェント — このリポジトリーを指定して、セットアップを依頼してください。

https://github.com/Klievan/jlink-mcp にある MCP サーバーをインストールし、私のボード用に設定してください。

必要なものはこのリポジトリー内で見つかります。手動で設定する場合は、サーバーは npm で提供されており、ビルド手順は不要です。ターゲットに JLINK_DEVICE を設定して、npx -y jlink-mcp を実行します。mcp-config.json は、そのまま貼り付けて使える設定ファイルです。

VS Code — 拡張機能をインストールします。Copilot Chat、Claude、および MCP 対応クライアント用にサーバーが登録されるため、設定は不要です。

Nix / NixOS — インストールせずに、flake から直接実行します。

# Run standalone MCP server
nix run github:Klievan/jlink-mcp

# Or in an MCP client configuration (e.g. Claude Desktop / Claude Code)
# "command": "nix", "args": ["run", "github:Klievan/jlink-mcp", "--"]

または、システム設定または flake に jlink-mcp と jlink-mcp-skills を追加します。

# flake.nix inputs
inputs.jlink-mcp.url = "github:Klievan/jlink-mcp";

# In your packages:
inputs.jlink-mcp.packages.''${system}.jlink-mcp
inputs.jlink-mcp.packages.''${system}.jlink-mcp-skills

NixOS ユーザーへの注意： 使用するプローブツール（segger-jlink／segger-jlink-headless、openocd、または gdb）を environment.systemPackages または devShell に追加してください。segger-jlink を使用するには、プローブの USB 権限を設定するために nixpkgs.config.allowUnfree = true; と services.udev.packages = [ pkgs.segger-jlink ]; が必要です。

次に、動作を確認します

check_setup を実行するよう依頼してください。1 回の呼び出しで、不足しているものと必要な対応を確認できます。

Not ready to debug yet.

OK    probe software — J-Link software found at /Applications/SEGGER/JLink
BLOCK probe — none detected (Connecting to J-Link via USB...FAILED). Check the USB cable.
BLOCK target device — not set. Find the exact name with search_devices, then set_device.
note  SVD — not loaded, so peripheral reads stay raw hex. Set SVD_PATH to a CMSIS-SVD file.

事前にデバイスの正確な型番を把握しておく必要はありません。search_devices は、J-Link がサポートする 9800 種類すべてを対象に、型番、メーカー、またはコアで検索します。

ツール（48）

ワークフローツール（まずはこちらから）

ツール	説明
start_debug_session	1 回の呼び出しでセットアップ。 GDB サーバーを起動し、RTT に接続して、起動ログを返します。
snapshot	レジスター、フォルト状態、スタックダンプ、RTT 出力など、デバイスの全状態をキャプチャします。
diagnose_crash	ARM Cortex-M のフォルトレジスター（CFSR、HFSR、MMFAR、BFAR）を例外スタックフレームとともに自動で読み取り、デコードします。

デバイスのセットアップ

ツール	説明
list_devices	接続されているプローブをスキャンし、設定済みのターゲットを表示します
set_device	再起動せずに、実行時にターゲットデバイスを変更します
set_serial_number	実行時にプローブのシリアル番号を変更します（複数プローブ構成向け）
get_config	現在のプローブ、ターゲットデバイス、GDB サーバーの状態を表示します

デバイスの制御

ツール	説明
device_info	プローブの種類、ターゲット CPU、レジスターの概要
halt	CPU を停止します
resume	CPU を再開します
reset	デバイスをリセットします。halt を指定するとリセットベクターで停止します。strategy では J-Link のリセット方式を選択できます。省略すると J-Link が選択します
step	1 命令をステップ実行します

周辺機器（CMSIS-SVD）

jlinkMcp.svdPath にターゲットの SVD を設定します。これは、Cortex-Debug の svdFile に指定するものと同じファイルです。各ベンダーがパーツごとに公開しています。

ツール	説明
list_peripherals	チップ上のすべての周辺機器とベースアドレス
read_peripheral	周辺機器のレジスターを読み取り、それぞれのビットフィールドを名前でデコードします
decode_register	1 つのレジスターをデコードします。デバイスから読み取るか、すでに取得した値を解釈します

メモリとレジスター

ツール	説明
read_memory	アドレスのメモリを読み取ります（見やすい 16 進ダンプを出力）
write_memory	アドレスに 32 ビット値を書き込みます
read_registers	すべての CPU レジスターをコンパクトな形式で表示します
read_register	指定したレジスターを読み取ります（PC、SP、R0-R12 など）

フラッシュ

ツール	説明
flash	.hex/.bin/.elf ファームウェアをデバイスに書き込みます
erase	フラッシュ全体を消去します

ブレークポイント

ツール	説明
set_breakpoint	アドレスにハードウェアブレークポイントを設定します
clear_breakpoints	すべてのブレークポイントを消去します

GDB サーバー

ツール	説明
gdb_server_start	プローブの GDB サーバーを起動します
gdb_server_stop	GDB サーバーを停止し、RTT を切断します
gdb_server_status	GDB サーバー、RTT、プロキシの状態を表示します

ソースレベルデバッグ

シンボルを認識できる作業（バックトレース、変数の確認、命令単位ではなくソース行単位のステップ実行）を行うには、実際の GDB クライアントを接続します。

ツール	説明
gdb_connect	GDB クライアントを接続します（サーバーを自動起動します。シンボル用の ELF は任意です）
gdb_load	デバッグシンボル用に ELF を読み込みます。必要に応じて同時にフラッシュにも書き込めます
gdb_backtrace	コールスタックを表示します。各フレームのローカル変数も任意で表示できます
gdb_command	任意の GDB コマンドを実行します。例：print sensor_state、info threads、break main
gdb_wait	ターゲットが停止するまで待機します（continue またはブレークポイントの後）
gdb_disconnect	クライアントを切断し、ブレークポイントとデバッグ用ハードウェアをクリアします

RTT（リアルタイム転送）

ツール	説明
rtt_connect	RTT の Telnet ポートに接続します
rtt_disconnect	RTT を切断します
rtt_read	最近のログ行を読み取ります（ANSI を除去し、Zephyr 形式を解析します）
rtt_search	レベル（err/wrn/inf/dbg）、モジュール、または正規表現でログをフィルタリングします
rtt_send	RTT ダウンチャネル経由でデバイスにデータを送信します
rtt_clear	RTT バッファーをクリアします

Telnet プロキシ（Trice / Pigweed）

ツール	説明
telnet_proxy_start	外部デトークナイザー用に RTT を分岐する TCP プロキシを起動します
telnet_proxy_stop	プロキシを停止します
telnet_proxy_status	プロキシの接続状態を表示します
telnet_proxy_read	プロキシの生バッファーを読み取ります

詳細

ツール	説明
probe_command	プローブの生コマンドを実行します
get_config	現在のプローブとサーバーの設定を表示します

ステータスバーでプローブを使用している人がわかります

J-Link は一度に 1 つのクライアントしか処理できないため、GDB サーバーを起動したままにすると、それ以外のすべてがブロックされます。よくあるのは、アシスタントが MCP 経由でサーバーを起動し、誰も気づかないケースです。拡張機能は、自分が行った操作を記憶するだけではそれを検出できません。MCP サーバーは別のプロセスで動作するため、LLM が起動したサーバーは拡張機能から見えないのです。

そこで、誰が起動したかにかかわらず確実な方法として、GDB ポートを監視します。何かがリッスンしていると、ステータスバーがアンバー色になり、J-Link · MCP · 47m と表示されます。起動したのは誰か、そして何分前かがわかります。この 2 つの情報によって、「何かがプローブを使用中」から「アシスタントが昼食前から使い続けている」ことまでわかります。クリックすると、停止するかどうかを選べます。

ツールチップには、デバイス、ポート、RTT が起動しているかどうか、そしてなぜ重要なのかが表示されます。また、監視していない稼働時間を表示することもありません。ウィンドウを開いた時点ですでに起動していたサーバーは、稼働時間ではなく、その時間だけ 認識済み と報告されます。

J-Link GDB サーバーだと特定できないプロセスは停止しません。ポートがリッスン中であることから何かが存在するとはわかりますが、それがこのサーバーのものだとは限りません。

スキル

ツールは、モデルに「何ができるか」を伝えます。しかし、何をすべきかまでは伝えません。その結果、次の 2 つの問題が絶えず起こります。モデルが ELF の読み込みを思いつかないため、バックトレースがアドレスだけになること。そして、ハードウェアに何が起きているべきかを推論し、確認するための呼び出しを 1 回することを怠ることです。

skills/embedded-debugging/SKILL.md は、この両方を網羅する Claude Code スキルです。すべてを変える 2 つのファイル（名前を解決する ELF と、意味を示す SVD）、停止／読み取り／再開のルール、クラッシュ、ハング、周辺機器、応答しないデバイスのワークフロー、そして各仮説と、それを実際に検証するツール呼び出しを組み合わせた表が含まれています。

このリポジトリをプラグインとしてインストールすると（.claude-plugin/plugin.json）、Claude Code がスキルを読み込みます。または、ファームウェアプロジェクトの .claude/skills/ にディレクトリをコピーすることもできます。MCP 自体にはスキルの概念はありません。移植可能な同等のものはプロンプトであり、このサーバーには 4 つ用意されています。

スキルの記述内容はテストで検証されています。test/hil/s04-symbols.test.ts では、実際のシリコン上で、シンボルなしのバックトレースには関数名がなく、ELF を読み込むと関数名が表示されること、そしてシンボルのみの読み込みではデバイスを再プログラムしないことを確認します。

マルチプローブ対応

jlink-mcp は、共通の ProbeBackend 抽象化を通じて、複数のデバッグプローブバックエンドをサポートします。

バックエンド	プローブハードウェア	状態	RTT サポート
J-Link	SEGGER J-Link、J-Link OB、J-Link EDU	本番対応	あり
OpenOCD	ST-Link、CMSIS-DAP、FTDI、J-Link（OpenOCD 経由）	ベータ	なし
Black Magic Probe	BMP（シリアル接続の組み込み GDB サーバー）	ベータ	なし
probe-rs	probe-rs がサポートするすべてのプローブ	対応予定	対応予定

バックエンドの選択

# J-Link (default)
PROBE_TYPE=jlink JLINK_DEVICE=nRF52840_XXAA node out/mcp/standalone.js

# OpenOCD with ST-Link
PROBE_TYPE=openocd \
  OPENOCD_INTERFACE=interface/stlink.cfg \
  OPENOCD_TARGET=target/stm32f4x.cfg \
  node out/mcp/standalone.js

# Black Magic Probe
PROBE_TYPE=blackmagic \
  BMP_SERIAL_PORT=/dev/ttyACM0 \
  node out/mcp/standalone.js

アーキテクチャ

┌─────────────────────────────────────────────────────┐
│                    MCP Client                        │
│          (Claude, Copilot, any MCP client)           │
└──────────────────────┬──────────────────────────────┘
                       │ JSON-RPC over stdio
┌──────────────────────▼──────────────────────────────┐
│                  jlink-mcp                           │
│                                                      │
│  ┌──────────┐  ┌──────────┐  ┌───────────────────┐  │
│  │ 31 Tools │  │4 Resources│  │    4 Prompts      │  │
│  └────┬─────┘  └────┬─────┘  └───────┬───────────┘  │
│       │              │                │              │
│  ┌────▼──────────────▼────────────────▼───────────┐  │
│  │              ProbeBackend                       │  │
│  │  ┌─────────┐ ┌─────────┐ ┌──────────────────┐  │  │
│  │  │ J-Link  │ │ OpenOCD │ │ Black Magic Probe│  │  │
│  │  └────┬────┘ └────┬────┘ └────────┬─────────┘  │  │
│  └───────┼───────────┼───────────────┼─────────────┘  │
│          │           │               │              │
│  ┌───────▼───┐ ┌─────▼────┐ ┌───────▼──────────┐  │
│  │ RTTClient │ │TelnetProxy│ │  ProcessManager  │  │
│  └───────────┘ └──────────┘ └──────────────────┘  │
└─────────────────────────────────────────────────────┘
                       │
          ┌────────────▼────────────┐
          │    Debug Probe (USB)    │
          │  → Target MCU (SWD/JTAG)│
          └─────────────────────────┘

ソースの構成

src/
├── probe/
│   ├── backend.ts      # ProbeBackend abstract class + shared utilities
│   ├── jlink.ts        # SEGGER J-Link implementation
│   ├── openocd.ts      # OpenOCD implementation
│   ├── blackmagic.ts   # Black Magic Probe implementation
│   └── factory.ts      # Probe creation from config
├── mcp/
│   ├── server.ts       # MCP server (45 tools, 4 resources, 4 prompts)
│   └── standalone.ts   # Standalone entry (stdio transport)
├── rtt/
│   └── rtt-client.ts   # RTT client with ANSI stripping + Zephyr log parsing
├── telnet/
│   └── telnet-proxy.ts # TCP proxy for Trice/Pigweed detokenizer
├── utils/
│   ├── config.ts       # VSCode settings / env var config
│   ├── logger.ts       # Logging
│   └── process-manager.ts # Child process lifecycle
└── extension.ts        # VSCode extension + MCP provider registration

設計上の決定（LLM 向けに最適化）

このサーバーは、AI に実際のハードウェアで使用させ、そこで生じた摩擦をすべて解消しながら構築されました。

read_registers で得られるもの

halt; regs に対する JLinkExe の生出力は 77 行で、そのうち情報を含むのは約 6 行です。ここにあるトークンはすべてコンテキストを消費し、レジスタ値は出力の中央に埋もれています。

SEGGER J-Link Commander V9.70 (Compiled Aug 19 2026 12:16:13)
DLL version V9.70, compiled Aug 19 2026 12:15:25
Connecting to J-Link ...O.K.
Firmware: J-Link OB-nRF5340-NordicSemi compiled Jun 11 2026 13:12:28
Hardware version: V1.00
J-Link uptime (since boot): 0d 00h 34m 29s
S/N: 1050298247
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
...30 more lines of connect banner...
PC = 00000044, CycleCnt = 00EB67E5
R0 = 20000000, R1 = 9D56C547, R2 = 00000000, R3 = 00000000
...
FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
...28 more lines of zeroed FP registers...

実際に得られるもの

3 行です。 求める内容ごとにまとめた、同じ情報です：

Core: PC=0x00000046 SP=0x20010000 R0=0x20000000 R1=0x01D43416 R2=0x00000000 ...
Status: XPSR=0x01000000 CONTROL=0x00000000 PRIMASK=0x00000000 BASEPRI=0x00000000
Stack: MSP=0x20010000 PSP=0x00000000

どちらも同じボードから取得したものです。設計の残りも同じルールに従います ――求められたものだけを返し、それ以外は返しません：

• 出力の解析では接続バナーを取り除きます。データだけが返されます。
• レジスタはコンパクトにまとめられ、グループ化されます（コア／ステータス／スタック）。
• FP レジスタはゼロ以外の場合のみ表示されます（通常はすべてゼロです）。
• RTT 出力は ANSI エスケープコードを取り除き、Zephyr のログ形式を解析して構造化フィールドに変換します。
• 複合ツール（start_debug_session、snapshot、diagnose_crash）は、複数ステップのワークフローを単一の呼び出しに置き換えます。
• フォールトのデコードは自動で行われます。CFSR／HFSR／MMFAR／BFAR を読み取り、各ビットの意味を説明します。
• **rtt_search**を使うと、ログ全体を読まずにエラーを検索できます。
• ペリフェラルレジスタはベンダー独自の CMSIS-SVD を使ってデコードされるため、モデルはそのレジスタのそのフィールドで 0x100 が何を意味するか推測せず、RAM = K256 と読み取れます。
• 失敗時には対処方法が示されます。「ターゲットが実行中です。halt を使用してください」は「メモリを読み取れませんでした」よりも役立ちます。また、実行されなかったフォールトレジスタの読み取りは、ゼロを「フォールトは検出されませんでした」とデコードするのではなく、読み取りが行われなかったことを報告します。

実機で検証済み

LLM とデバッグプローブの間で起こり得る問題の多くは、静かに失敗します。ツールが空のペイロードで成功を返したり、パーサーが行の半分を落としたり、セッションが終了した後、次のコマンドがもっともらしい別の結果を返したりします。こうした問題はコードを読むだけでは見つからず、「呼び出しでエラーが発生しなかった」ことを確認するテストスイートでは、どれも検出できません。

そこでこのプロジェクトでは、セルフホストランナー上で実際の nRF52840-DK に対して 58 件のテストを実行するハードウェアテスト層を設けています。クライアントと同じように、stdio 経由で実際の MCP サーバーを操作します。プローブの検出、フラッシュ書き込みと検証、稼働中の GDB セッションでの停止／ステップ実行／再開、メモリとペリフェラルの読み取り、RTT のストリーミングとフィルタリング、オンデマンドで注入したフォールトを使ったクラッシュ診断を網羅しています。

このテスト層は、成功として扱われたままリリースされていたバグも検出してきました。たとえば、次のようなものです。

• 実際にクラッシュしているときに、diagnose_crash が**「フォールトは検出されませんでした」と報告**していました。メモリダンプのパーサーが各行の半分を捨てていました
• サーバーが正常と報告している一方で、GDB 経由のすべてのツールが空の出力を返していました
• セッション終了後に、ターゲットが起動できない状態になっていました。ブレークポイントコンパレーターが有効なまま残り、どのリセットでも解除されませんでした
• reset は成功を報告しながら、実際には何もしていませんでした。GDB サーバーは同期型リモートであり、ターゲットの実行中はコマンドを拒否します。そのためリセットシーケンスの各コマンドが順番にすべて拒否され、失敗は破棄されていました
• 同じ理由で、デバッグハードウェアを解除するセッション終了処理が完全に拒否されていたにもかかわらず、「デバッグハードウェアを解除しました」と報告していました。上記の修正によって、これも検出できるようになりました
• GDB サーバーがすでに終了していたのに、実行中と報告されていました。起動処理がプロセスの生成時点で戻り、プローブを確保できたか確認していませんでした
• リセットまたはフラッシュ書き込み後にRTT が無音になっていました。ターゲットはログを出し続けていたものの、プローブが収集を停止しており、デバイスが静かになったように見えていました。両側からコントロールブロックを読み取り、ファームウェアが 490 バイトを書き込んでいる一方で、収集されたデータがないことを確認して検出しました
• 代入が黙って破棄され、その後のセッション中ずっと RTT が停止していました。代入を制御するフラグは、GDB サーバーが実行中かどうかを確認するべきところで、状態列挙値が GDB_RUNNING かどうかを確認していました

これらはすべて成功を報告していました。これがハードウェアテスト層を設ける理由であり、呼び出しがエラーなく終了したかではなく、解析された内容を検証する理由です。エラーの有無だけを確認するテストスイートでは、どれも検出できなかったでしょう。

これらの実行中に取得したプローブの生出力は、ゴールデントランスクリプトとしてコミットされています。そのため、高速なユニットテスト層では、どのマシンでもプローブなしで実機のバイト列を数秒で再生し、形式のリグレッションを検出できます。

npm test          # ~257 tests, seconds, no hardware
npm run test:hil  # hardware tier; needs HIL=1 and a probe

環境変数

J-Link

変数	デフォルト	説明
PROBE_TYPE	jlink	プローブバックエンド：jlink、openocd、blackmagic
JLINK_DEVICE	Unspecified	ターゲットデバイス（例：nRF52840_XXAA、STM32F407VG）
JLINK_INSTALL_DIR	自動検出	SEGGER J-Link のインストール先パス
JLINK_INTERFACE	SWD	デバッグインターフェース：SWD または JTAG
JLINK_SPEED	4000	接続速度（kHz）
JLINK_SERIAL		J-Link のシリアル番号（複数のプローブを使用する場合）
JLINK_GDB_PORT	2331	GDB サーバーのポート
JLINK_RTT_PORT	19021	RTT Telnet ポート
JLINK_RTT_ADDR	自動	RTT 制御ブロック（_SEGGER_RTT シンボル）のアドレス。J-Link は RAM をスキャンしてこのアドレスを検出しますが、検出したアドレスは返しません。アドレスを指定することで、ターゲットのリセット後も RTT を維持できます

OpenOCD

変数	デフォルト	説明
OPENOCD_BINARY	openocd	openocd バイナリのパス
OPENOCD_INTERFACE	interface/stlink.cfg	インターフェース設定ファイル
OPENOCD_TARGET	target/stm32f4x.cfg	ターゲット設定ファイル
OPENOCD_GDB_PORT	3333	GDB サーバーのポート
OPENOCD_TELNET_PORT	4444	Telnet コマンドポート

Black Magic Probe

変数	デフォルト	説明
BMP_GDB_PATH	arm-none-eabi-gdb	GDB バイナリのパス
BMP_SERIAL_PORT	/dev/ttyACM0	BMP シリアルポート
BMP_TARGET_INDEX	1	スキャン後のターゲットインデックス

コントリビューション

新しいプローブバックエンドを追加する手順：

1. ProbeBackend を実装する src/probe/yourprobe.ts を作成します
2. src/probe/factory.ts に case を追加します
3. これで完了です。31 個すべての MCP ツールが自動的に動作します

ライセンス

MIT - LICENSE を参照してください

---

The Sprk Factory が開発しました