stlink-mcp

stlink-mcp

AI コーディングエージェントが ST-LINK 経由で STM32 ターゲットのプログラム、実行、状態確認を行える MCP サーバーです。すべての結果に、検証済み、未検証、失敗のいずれかと、その根拠が示されます。ボードのそばでローカルに動作し、インストール済みの STM32CubeCLT コマンドラインツールを操作します。プログラムを停止することなく、ELF と ST の SVD ファイルから名前を指定して変数やペリフェラルレジスターを読み取ります。要求がない限り、ファームウェアから見える状態を変えてしまう読み取りは拒否し、すべての結果に呼び出しによってターゲットが停止またはリセットされたかどうかを示します。このサーバーを接続すると、エージェントは編集、ビルド、書き込み、観察のループを自ら実行し、ボードで何が起きたかをあなたが伝えるのではなく、その結論を監督できます。

レポートが正確でなければならない理由

ファームウェアに取り組むエージェントの能力は、ボードについてツールが伝える情報の正確さに左右されます。ツールが誇張して報告したことに開発者が気づけるのは、ツールが伝えなかった情報を持っているからです。変化しなかった LED、前回のビルドと同じように見えるコンソールのテキスト、手元にあるボード。エージェントにはそのどれもありません。ツールが返すテキストが、エージェントにとってハードウェアの全情報です。そのため、実行していない処理を成功と報告するツールは、エージェントに誤った確信を与え、その誤りがコード、コミットメッセージ、ドキュメントに書き込まれます。そこで生じる損失は、処理の失敗そのものよりもはるかに大きくなります。

ST のコマンドラインツールは、実際以上のことを報告します。STM32N6 での例を 3 つ挙げます。

• STM32_Programmer_CLI -s <address> は「Start operation achieved successfully」と表示しましたが、プログラムカウンターはブート ROM から移動していませんでした。
• ST-LINK_gdbserver は「Failed to halt target」と表示しました。コアに問題はなく、サーバーが誤ったデバッグアクセスポートを使用していました。
• 実行中のターゲットに対する GDB のロードは正常に完了しましたが、何も変更されませんでした。そのため、前のプログラムが実行を続け、その出力が新しい実行の成功を示すように見えました。

これらのツールを操作するエージェントは、そのすべてを引き継ぎます。そこで、このサーバーでは次のルールを適用します。

ツールは、要求された処理が実際に行われたことを確認してから成功を報告します。

run_firmware は、GDB が終了コード 0 を返したからではなく、新しいイメージがコンソールに出力されたか、プログラムカウンターがそのイメージ内にあることを確認できた場合に成功を報告します。すべての結果には 3 つの状態のいずれかが付き、ok を手動で設定するツールはありません。

status	ok	意味
verified	true	確認済みで、verified_by に観察内容が記されています
unverified	false	成功した可能性は十分ありますが、確認されていません
failed	false	失敗しており、error に理由が記されています

unverified が意図的に ok ではないのは、実行を誰も確認していない以上、成功した可能性がどれほど高くても成功とは見なさないためです。unverified_because に未確認の内容が記されるので、失敗と取り違えることもありません。

エージェントが受け取るのは、フラットな JSON オブジェクトです。STM32F407 での実行例の値を使い、サーバーが返すフィールドを含めた run_firmware の結果は次のようになります。

{
  "probe_serial": "0670FF3433554B3043165632",
  "elf_path": "/home/you/blink/build/blink.elf",
  "interface": "swd",
  "interface_clock_khz": 4000,
  "console_port": "/dev/ttyACM0",
  "console_port_source": "the probe's own port",
  "load_address": "0x20000000",
  "load_address_provenance": "measured",
  "image_initial_sp": "0x20020000",
  "image_entry_point": "0x200001a5",
  "load_size_bytes": 6180,
  "target_was_reset": true,
  "console": "blink 0.3 starting\r\nLED on\r\n",
  "ok": true,
  "status": "verified",
  "verified_by": "console output from this board's own port"
}

ボードから何も出力されなかった場合、ok は false、status は unverified となり、イメージはロードされて起動したものの、キャプチャウィンドウ内に何も受信できなかったことが unverified_because に記されます。

どのように連携するか

エージェントは、これまでと同じようにファームウェアを編集してビルドします。このサーバーはボードにアクセスする役割を担います。ST のツールを操作し、その実行内容と確認済みの項目を示す結果を返します。

flowchart LR
    agent["AI coding agent"] -- "builds" --> project["Your firmware project"]
    agent -- "MCP tool calls" --> server["stlink-mcp"]
    server -- "result: verified, unverified or failed" --> agent
    server --> clt["STM32CubeCLT: STM32_Programmer_CLI, ST-LINK_gdbserver, GDB"]
    clt --> probe["ST-LINK probe"]
    probe -- "SWD or JTAG, SWO" --> board["STM32 board"]
    board -- "serial console, through the probe" --> server

対象ユーザー

お使いのボードに ST-LINK が搭載され、STM32CubeCLT がすでにインストールされていて、すべてのレポートでターゲット上で観測した内容を明示するエージェントが必要な場合にお使いください。これは、人ではなくエージェント向けに設計されたデバッグです。用意されているのは16個のツールです。可能な限りターゲットを停止せずに読み取り、指示された場合にのみ停止し、呼び出しによって停止またはリセットした場合はその旨を必ず報告します。対象外としているものは4つあり、それぞれ理由があります。

• ファームウェアのビルドはビルドシステムの役割であり、エージェントはすでにそれを実行します。
• シングルステップ実行は、人がコードを調べるためのものです。エージェントには、命令ごとに呼び出すよりも、指定した位置に到達するまで、または変数に書き込みが行われるまで実行する1回の呼び出しから、呼び出しスタック、レジスター、停止した理由を受け取るほうが有用です。
• メモリーへの書き込みは、エージェントに必要だと実際の利用を通じて確認されるまで対象外です。誤った書き込みはプログラムの動作を変えてしまい、その結果には何も示されないためです。
• RTT（SEGGERのReal Time Transfer。ファームウェアが書き込み、デバッガーが読み取るリングバッファー）は、STのツールではサポートされていません。sample_valuesはプログラムの実行中にすでに値を監視しています。RTTログの読み取りは、今後対応する可能性があります。

シングルステップ実行、自分で管理するブレークポイント、またはRTTが必要な場合は、stm32-gdb-mcpまたはembedded-debugger-mcpをお使いください。J-LinkまたはDAPLinkプローブ、STM32以外のターゲット、あるいはここで検証した範囲を超えるWindowsサポートが必要な場合は、embedded-debugger-mcpをお使いください。比較については関連プロジェクトをご覧ください。

ステータス

アルファ版です。3つのデバイスIDをハードウェア上で測定済みです。STM32F407の0x413、STM32H743の0x450、STM32N657の0x486です。残りの範囲は、実行時にお使いのSTM32CubeCLTインストール内にあるSTMicroelectronics独自のデバイスデータベースから初期化され（STM32CubeCLT 1.22.0では、さらに96個のデバイスID）、そこから得られたすべての値にはその旨が表示されます。このバージョンのデータベースで複数の独立したSRAMバンクが記載されているデバイスID（0x42B、0x42C、0x472、0x49A）は、推測で決めるのではなく拒否されます。board_stateには選択できないアドレスが表示され、ボードファイルを使えば解決できます。データベースに登録されていない部品でも、識別自体は行われます。run_firmwareを除くすべてのツールが動作します。flash_firmwareには.binファイルとそのaddressが必要です。

バージョンはSemantic Versioning 2.0.0に従い、gitタグから読み取られます。最後のタグより後のコミットを含むビルドでは、タグにコミット数を加えた値が報告されます。たとえば0.1.0+3です。GitHubの「Download ZIP」から取得したツリーには同じバージョンが含まれますが、タグもバージョン情報も含まないファイルの単純なコピーでは、0.0.0+unknownが報告されます。パブリックAPIは、以下の16個のツール、そのパラメーターと結果フィールド、およびstlink-mcpコマンドラインです。0.y.zでは、これらのいずれも変更される可能性があります。1.0の前に必要な作業はROADMAP.mdに、このファイルの主張の根拠となる測定結果はdocs/findings.mdに、変更点はCHANGELOG.mdに記載されています。問題の報告方法や、測定済みのボードを追加するための協力方法についてはCONTRIBUTING.mdをご覧ください。

要件

• STM32CubeCLT。STM32CubeProgrammer、GDB サーバー、Arm ツールチェーンが同梱されています。/opt/st、~/st、/usr/local/st の stm32cubeclt* ディレクトリ、macOS の /Applications/STMicroelectronics/STM32CubeCLT、およびインストーラーが配置する Windows の C:\ST から自動的に検出されます。それ以外の場所にある場合は、STLINK_MCP_CLT_ROOT にインストールディレクトリを設定してください。STM32CubeCLT が揃っていない場合は、STM32CubeIDE のインストール先にある同じ3つのツールが使用されます。検索場所は同じで、stm32cubeide* ディレクトリ、またはインストール先の STLINK_MCP_CLT_ROOT が示す場所です。その場合は --check がその旨を表示します。Linux で STM32CubeIDE 2.2.0 を使用してテスト済みです。SVD ファイルも含まれています。
• Python 3.11 以降。
• ST-LINK。ほとんどの開発ボードでは、ボード自体に搭載されています。ST の GDB サーバーは、プログラマーでは引き続き使用できる場合でも、サポート対象より古いプローブのファームウェアを拒否し、その場合 run_firmware がその旨を表示します。インストール先で GDB サーバーと同じ場所にある STLinkUpgrade.jar でファームウェアを更新できます。インストール先の Java ランタイムを使ってシェルから java -jar STLinkUpgrade.jar -sn <serial> -update を実行すると、ファームウェアが古い場合にのみ書き込みが行われます。
• Linux では、シリアルコンソールを使用するための dialout グループへの所属と、プローブ用の ST の udev ルールが必要です（STM32CubeCLT がこれらをインストールします）。

インストール

uv がインストールされていれば、PyPI のパッケージはインストール手順なしで実行できます。uvx [email protected] のように指定すると、バージョンを固定できます。MCP Registry を参照する MCP クライアントでは、io.github.dii/stlink-mcp として見つかります。

uvx stlink-mcp --check

コードを操作するには、リポジトリをクローンして、そこから実行します。

git clone https://github.com/dii/stlink-mcp
cd stlink-mcp
uv sync
uv run stlink-mcp --check

--check は、検出したツールチェーン、ベンダーデータベース、ボードファイルがあればそのファイル、および接続されたプローブを表示してから、サーバーを起動せずに終了します。プローブの表示方法は list_probes と同じで、プローブを停止もリセットもしません。

MCP クライアントから使用する

{
  "mcpServers": {
    "stlink": {
      "command": "uvx",
      "args": ["stlink-mcp"],
      "env": { "STLINK_MCP_CLT_ROOT": "/opt/st/stm32cubeclt_1.22.0" }
    }
  }
}

env ブロックに設定を記述します。変更する設定がある場合にのみ必要です。Claude Code では、同じ設定を次のように記述します。

claude mcp add stlink -e STLINK_MCP_CLT_ROOT=/opt/st/stm32cubeclt_1.22.0 -- uvx stlink-mcp

クローンしたリポジトリから実行する場合は、uvx stlink-mcp の代わりに uv --directory /path/to/stlink-mcp run stlink-mcp を使用します。

エージェントに使用方法を伝える

接続時に、サーバーは各クライアントに短いガイドを提供します。用途、結果の読み方、一般的な呼び出し順序について説明するものです。Claude Code は、ツールの説明が読み込まれていない場合でも、このガイドをエージェントに表示します。ガイドを引き継がないクライアントの場合は、同じ内容をプロジェクトの AGENTS.md、またはエージェントが指示を読み込むファイルに記述してください。

stlink-mcp drives STM32 boards through an ST-LINK probe with ST's STM32CubeCLT tools.

Every result has a status. verified: verified_by says what was observed. unverified: it may have worked, but nothing checked it, and unverified_because says why; this is not success. failed: error says why. Read the status before the values.

A usual session: `list_probes`, then `board_state` to identify the board. `run_firmware` loads an ELF linked for RAM and starts it; a build linked for flash, the default from STM32CubeIDE and CubeMX, goes `flash_firmware`, then `reset_target`, then `capture_console`. Without halting the program: `capture_console`, `capture_swo`, `sample_values`, `read_memory`, `read_fault_status`, `read_option_bytes` and `disassemble`. Halting it: `run_until`, `core_registers` and `locate_fault`. `reset_target` restarts it; `release_probe` when done.

Give `probe_serial` on every call: without it each call first lists the probes, which takes a second or more and holds up every other board. Give addresses as "0x..." strings and files as absolute paths. `run_firmware` lets go of the probe once the program starts; with `keep_probe=True` a GDB server keeps holding it, and while it does, a core that locks up is reset, which clears its fault registers. `reset_target` and `flash_firmware` stop a holding server first and say so. A call that halts or resets the target says so. If the running program has closed the debug port, `board_state` can get back in by resetting the target, and `reset_target` cannot; on an STM32N6 running ST's start-up code, only a power cycle does. An unknown argument is refused, not ignored.

ツール

ツール	機能	検証方法
list_probes	接続されているプローブ、そのファームウェアとシリアルコンソールを一覧表示し、GDB サーバーが使用中のプローブを示します	プログラマー独自の一覧です。出力されたエラーは一覧とともに返されます。このユーザーが開けないプローブはエラーを出力し、項目は表示されないためです
board_state	ターゲット、プローブ、ファミリーを特定し、コアが実行中、スリープ中、停止中、またはロックアップ状態かどうかを、停止させずに示します	アクセスポート 0 と 1 を試します。elf_path で指定されたソースに、DHCSR から取得したコアの状態と、プログラムカウンターのサンプルを 5 つ記録します。通常の接続でコアにアクセスできない場合は、リセット経由で再接続し、その場合は target_was_reset で示します。GDB サーバーがプローブを使用中の場合、リセットは行いません
run_firmware	ターゲットをリセットし、ELF を RAM にロードして起動します	ロード後のコンソール出力、またはイメージ内のプログラムカウンターのサンプルです。実行前にプローブが取得した内容はカウントされません。GDB がロードを完了できなかった場合は failed になります。RAM 用にリンクされていないイメージは拒否します。プログラムの起動後、keep_probe が true でない限りプローブを解放します
flash_firmware	生のバイナリ（.bin）、ELF、または Intel HEX ファイルをフラッシュに書き込み、ボードから起動できるようにします	書き込んだ範囲をすべて読み戻します。読み戻した内容が完全に一致した場合のみ verified になります。イメージのサイズを超えて消去した範囲も示します。イメージは起動しません。フラッシュへの書き込みを参照してください
read_memory	ターゲットを停止またはリセットせずに、32 ビットワード、名前で指定した変数、または名前で指定した周辺機器レジスターを読み取ります	ワードそのものです。変数が verified になるのは、デコードに使った ELF をターゲットが実行している場合のみです。読み取り長が不足している場合、および読み取りによって状態が変化するレジスターは、read_effects_ok が指定されていない限り拒否します
sample_values	プログラムを停止せずに、変数、アドレス、またはレジスターを最大 8 件、最大 60 秒間、毎秒数回まとめてサンプリングします	値が変化しなかった場合は値そのものを返し、変化した場合は最初の値、最後の値、範囲、変化回数、最初に変化した時刻と、コアが実行中、停止中、またはその他の状態だったサンプル数を返します。until は、条件が成立した最初のサンプルで停止します。2 回のサンプルの間に値が変化して元に戻った場合、その変化は検出されません
core_registers	コアレジスターを読み取ります。読み取り時にはコアを停止します。ELF を指定した場合は、各フレームの引数とローカル変数を含むコールスタックも返します	レジスターそのものです。読み取り後にコアが実行中かどうかも示します。ELF を指定せず、実行中に到達できないコアがある場合は、リセット経由で到達し、その結果を示します。ELF を指定した場合は、リセットする代わりに処理を拒否するため、返されるコールスタックは常に実行中のプログラムのものです
run_until	関数、行、アドレスに到達するか、変数に書き込むまでターゲットを実行し、その位置でコアを停止状態に保ちます	停止時にチップのデバッグフォルトステータスレジスターがブレークポイントまたはウォッチポイントを示している場合のみ verified になります。制限時間が経過した場合は unverified です。ターゲットの停止を参照してください
read_fault_status	ターゲットを停止またはリセットせずに、Cortex-M のフォルトレジスターを読み取り、デコードします	生のレジスター値、平易な言葉での診断、およびハードウェアが記録している場合はフォルト発生アドレスを返します。例外ベクターを捕捉した GDB サーバーが使用中の場合、フォルトのない読み取りは unverified になります。そのようなレジスターを持たない Cortex-M0、M0+、M1、M23 コアでは拒否します
locate_fault	例外フレームから、フォルトが発生した命令を特定します。読み取り時にはコアを停止します	LR の EXC_RETURN が示すスタックから PC を取得します。ELF を指定した場合は、関数、行、命令も返します。取得したワードがフレームらしくない場合は unverified になります。リセットするとフォルトが失われるため、リセットは決して行いません
disassemble	ELF から、関数またはアドレス周辺のコードを逆アセンブルします	各命令と、そのソースファイルおよび行を返します。probe_serial を指定した場合は、ターゲットのコードも停止させずに読み取ります。そのコードが ELF と一致した場合のみ verified になります
read_option_bytes	ST のプログラマーが説明する形式でオプションバイトを読み取ります。読み出し保護、ブラウンアウトレベル、ユーザー設定、ブートアドレス、書き込み保護が対象です	読み取り専用です。このツールでオプションバイトを書き込むことはできません。プログラマーが認識しているオプションバイトを持たない部品（STM32N6 など）では、ST の理由とともに失敗します
capture_console	ボードのシリアル出力をキャプチャします	最初の /dev/ttyACM* ではなく、プローブのシリアルに対応するポートを読み取ります。何も受信しない場合は unverified になります。ターゲットに接続されていないポートも、無音のポートと同じ結果になるためです
capture_swo	SWO ピン経由で、ターゲットが ITM の刺激ポートに書き込んだ内容をキャプチャします	そのポートで受信したテキストです。何も受信しない場合は unverified になります。SWOを参照してください
reset_target	ターゲットをリセットし、再起動したことを確認します	リセットベクターで一時的に停止し、PC とベクターテーブルのリセットエントリーを比較してから、コアを再開します。先にプローブを使用中の GDB サーバーを停止し、その旨を示します。プログラムが閉じたデバッグポートを通過することはできません。その場合は board_state を使用できます
release_probe	プローブを使用中の GDB サーバーを停止します。これにより、run_until が停止状態に保っていたコアが再開します	使用中のものがなければ unverified になります。コアが再び実行中かどうかを示します

プローブを保持する

run_firmware は GDB サーバー経由で読み込み、プログラムの開始後にプローブを解放します。SWD ピンを別の用途に使ったり、デバッグポートが必要とするクロックを停止したり、デバッグを無効にしてスリープしたりしてデバッグポートを閉じるプログラムには、その後 board_state がリセット経由で再接続し、プログラムを再起動してアクセスします。reset_target ではアクセスできません。

run_firmware(keep_probe=True) は代わりに GDB サーバーがプローブを保持するようにし、run_until はコアが停止している間、プローブを保持します。サーバーがプローブを保持している間、読み取りツールは ST の共有モードで、サーバーと並行してコアにアクセスします。locate_fault と core_registers は、各ツールの行に記載されているとおり、読み取りのためにコアを停止します。reset_target と flash_firmware は、プローブのリセットやフラッシュ書き込みを並行して行うと GDB セッションが壊れるため、先にサーバーを停止し、そのことを released_probe_first で示します。release_probe はプローブを解放します。プローブを保持することには、次の 2 つの代償があります。また、デバッグポートを閉じる動作を防ぐことはできません。

• フォールトハンドラー内でフォールトを起こして停止したコアは、プローブを保持するサーバーによってリセットされ、リセットベクターで停止します。このときフォールトレジスターはクリアされます。このように停止したコアを検出した結果には、その旨が示されます。
• 共有モードには ST の stlink-server が必要です。これは STM32CubeCLT によって PATH にインストールされます。これがない場合、サーバーはプローブを独占するため、プローブを指定した read_memory、sample_values、read_fault_status、locate_fault、read_option_bytes、capture_swo、disassemble は、release_probe が呼び出されるまで拒否されます。共有モードでサーバーがプローブを保持している間にプログラムがデバッグポートを閉じ、プローブが応答しなくなった事例があります。動作しない場合を参照してください。

ST の stlink-server は、GDB サーバーとプログラマーが 1 つのプローブを共有できるようにするデーモンです。このサーバーが必要とするのは、GDB サーバーがプローブを保持している間だけです。それ以外のときは、このデーモンが妨げになります。プローブを開いたまま保持していると、プログラマーからアクセスできません。そのため Linux では、マシン上で ST-LINK GDB サーバーが実行されていない場合、サーバーは次にプログラマーを呼び出す前に stlink-server を停止し、--check も同様に停止します。他のシステムではこの処理を行いません。サーバーは、利用者がエージェントであることから、プローブを使うのは自分だけだと想定しています。IDE のデバッガーがプローブを共有することには対応していません。

RAM からイメージを実行する

開発中は run_firmware を使います。フラッシュへの書き込みより高速で、デバッガーが RAM に配置するイメージはブート ROM を経由しないため、起動に署名付きイメージが必要なパーツでも署名は不要です。読み込みの前に、ターゲットは毎回リセットされます。イメージは RAM 用にリンクされている必要があります。ベクターテーブルは board_state が報告する vector_table_addr に配置し、読み込むすべてのセクションは 0x20000000 から 0x3FFFFFFF の範囲内になければなりません。デフォルトのフラッシュ用ビルドは、何も読み込まれる前に拒否されます。GDB の読み込みでは、イメージに記録されたアドレスに各セグメントが書き込まれるためです。このツールは、そのベクターテーブルからスタックポインターとプログラムカウンターを設定しますが、VTOR は設定しません。そのため、割り込みを使うイメージでは、スタートアップコード内で VTOR が独自のテーブルを指すようにする必要があります。

フラッシュへの書き込み

flash_firmware は、指定した address、またはそのベースアドレスが measured の場合はパーツのフラッシュベースアドレスに .bin を書き込みます（アドレスの取得元を参照）。ELF ファイルまたは Intel HEX ファイルはファイル内のアドレスに書き込まれ、すべてのバイトが、測定されたベースアドレスと接続時に報告されたフラッシュサイズで定まるパーツのフラッシュ範囲内にある必要があります。このようなファイルに対して address を指定すると拒否されます。ELF ファイルまたは HEX ファイルは、測定されたベースアドレスに書き込まれます。また、ST のデータベースまたはボードファイルのベースアドレスが、すべての STM32 の内部フラッシュが始まるメインフラッシュ範囲 0x08000000～0x0800FFFF 内にある場合も書き込まれます。ベースアドレスがない場合、推定値の場合、範囲外の場合、パーツのフラッシュが外部ローダーの背後にある場合（STM32N6）、または接続時にフラッシュサイズが報告されない場合は拒否されます。拒否時には、address を指定して .bin を書き込むよう案内されます。接続後の ELF または HEX の結果には、拒否または書き込みのいずれの場合も、flash_base_provenance と flash_range_checked が含まれます。これらはベースアドレスの出所と、ファイルの各領域の検証対象となった範囲を示すため、エージェントは、誰も測定していないベースアドレスに基づいて書き込みが行われたかどうかを確認できます。S-record ファイルは拒否されます。

消去はセクター単位で行われるため、触れる各 128 KB ブロック内のイメージ外のバイトは、書き込みの前後に読み取られ、消去されたバイトがあれば結果に示されます。フラッシュのセクターが 128 KB より大きいパーツでは、消去の一部が検証対象外の範囲に及ぶ場合があります。書き込みが途中で失敗した場合は、フラッシュがすでに変更されている可能性があることが示されます。このツールはイメージを起動したり署名したりしません。パーツのブート ROM がイメージを起動するために必要な手順が記録されている場合は、next_step に示されます。

STM32N6

STM32N6 には内部フラッシュがありません。ブート ROM がボードの外部フラッシュから RAM にイメージをコピーして実行します。

• フラッシュから起動するには（BOOT1 が Low）、イメージに ST のヘッダーが必要です。セキュアブートヒューズが切れていないパーツでは、キーのないヘッダーで問題ありません：STM32_SigningTool_CLI -bin image.bin -nk -t fsbl -hv 2.3 -align -o image-boot.bin を実行し、その後 image-boot.bin を書き込みます。

• ブート ROM はフラッシュ起動時にデバッグポートを閉じたままにします。デバッガーがフラッシュから起動したイメージにアクセスするには、開発ビルドに限り、イメージが起動時に毎回、最初の処理としてデバッグポートを開く必要があります。ST の HAL_BSEC_ConfigDebug と HAL_BSEC_UnlockDebug は、BSEC_DBGCR に 0xB451B400 を、BSEC_AP_UNLOCK に 0xB4 を書き込みます。リセット後、イメージが再びポートを開き、プローブが再接続されます。

• 開発用起動（BOOT1 が High）で外部フラッシュに書き込みます。フラッシュから起動した後は ST のフラッシュローダーがコアを停止させ、電源の入れ直しでしかボードを復帰できないため、flash_firmware は最初にブートピンを読み取り、フラッシュ起動時には拒否します。board_state は読み取ったブートモードを報告します。

• ST の FSBL テンプレートからビルドしたイメージは、プローブが保持されているかどうかにかかわらず、起動時にデバッグアクセスポート 1 を閉じます。電源を入れ直すまで再び開きません。原因は ST の system_stm32n6xx_fsbl.c の末尾にある次の 1 行で、SystemInit の終了時に SYSCFG クロックをオフにします。

  RCC->APB4ENCR2 = RCC_APB4ENCR2_SYSCFGENC;   /* deactivate SYSCFG clock */
  

  この書き込みを削除すると、実行のたびにポートが維持されます。

複数のボード

list_probes 以外のすべてのツールには probe_serial が必要です。複数のボードが接続されている場合、指定しないとエラーになります。推測は行われません。プローブの順序は再接続するたびに変わるため、ファームウェアを誤ったボードに書き込むと、成功したように見える失敗になります。

list_probes は、どのシリアルポートがどのプローブに対応するかを報告します。この対応関係は順番によるものではないため、順序に基づいてプローブを /dev/ttyACM* と組み合わせると誤った結果になります。Linux では、probe_serial を指定したツールは /dev/serial/by-id から該当するポートを見つけます。ここでは udev が各ポートに対応するプローブ名を付けています。各ボードは、それぞれ固有のポートで独自の GDB サーバーを使用します。

異なるプローブへの呼び出しは同時に実行され、同じプローブへの呼び出しは互いに待機します。プローブの一覧表示が必要な呼び出し（list_probes、または probe_serial のない呼び出し）は、どのプローブも使用されていない状態になるまで待機し、単独で実行されます。また、プローブが使用中の間は一覧表示に時間がかかります。そのため、すべての呼び出しでプローブを指定してください。

誰が何を要求したか

ツールを呼び出すたびに、サーバーの stderr に1行書き込まれます。MCP クライアントはこれをログに保持します。記録されるのは、クライアントが宣言した名前とバージョン、どの接続とリクエスト経由か、ツール、プローブ、判定です。GDB サーバーがプローブを保持しているために呼び出しが拒否された場合、held_by には、そのプローブを保持しているクライアントの実行が示され、release_probe には、誰のものだったかが示されます。認証はありません。呼び出し元は記録されますが、確認はされません。

SWD または JTAG

接続するツールはすべて interface を受け取ります。値は swd（デフォルト）または jtag です。ただし、SWD のみで動作する capture_swo と、解放するサーバーのインターフェースを使用する release_probe は除きます。結果にはインターフェースと、プログラマーが接続した場合は使用したクロックが報告されます。すべてのプローブが JTAG に対応しているわけではありません。たとえば NUCLEO-H743ZI2 自身の STLINK-V3E は JTAG に対応しておらず、JTAG 接続に対して、ターゲットが接続されていないかのように応答するため、結果のヒントで最初にそのことを示します。一方から他方へのフォールバックはありません。ツールは指定されたインターフェースで接続し、あるインターフェース用に保持された GDB サーバーを別のインターフェースで再利用することもありません。

アドレスの代わりに名前を使う

read_memory は、symbol とターゲットで実行中の elf_path を指定して、名前で変数を読み取ります。デコードには ELF 自身の型が使われ、整数、浮動小数点数、列挙型、ビットフィールド、配列、構造体、共用体、ポインターに対応します。同じ呼び出しで ELF のコードの先頭とターゲットのメモリも比較するため、ターゲットがその ELF を実行している場合に限り、結果は verified になります。ファイルスコープの static と関数スコープの static など、名前が複数の変数に一致する場合は、両方を示して拒否されます。レジスターまたはスタック上にあるローカル変数は固定アドレスを持たないものとして拒否されます。

register に PERIPHERAL.REGISTER（たとえば RCC.CR）を指定すると、ST の STM32CubeCLT インストールに含まれる SVD ファイルから、周辺機器レジスターを名前で読み取り、その値と各フィールドを返します。ファイルは、指定されていれば svd から、そうでなければプローブが報告するボード名から、それもなければデバイス名に含まれるパーツ名から取得されます。複数のファイルが該当する場合は、すべてのファイルでレジスターの記述が同じ場合に限り、そのレジスターが使用されます。NVIC などのコアレジスターは ST のコアファイルに含まれており、たとえば svd="Core/Cortex-M7" のように svd で指定します。

プログラムは実行中か、どこで実行中か

board_state はコアのデバッグステータスレジスターを読み取り、コアを停止させずにプログラムカウンターを5回サンプリングします。そして、コアが実行中、スリープ中、停止中、またはロックアップ中のどれかと、実行位置を報告します。ELF が指定されている場合は、関数名と行番号も示します。サンプラーが動作するのはデバッグトレースユニットが有効な場合だけです。GDB セッションでは有効になりますが、リセットすると無効になります。そのため、リセット直後は何も返さず、その理由を示します。停止ビットもロックアップビットも設定されておらず、2回の読み取りの間に命令も実行されなかったコアは、推測せずに not seen running と報告されます。

run_firmware は同じサンプリングを使用します。何も出力しないイメージやコンソールのないボードでも、すべてのサンプルが読み込んだばかりのイメージ内にある場合は verified になります。サンプリングできるのはプローブを共有するサーバーの隣だけなので、stlink-server がない場合は keep_probe=False が必要で、そのことが結果に示されます。

識別処理とすべてのメモリ読み取りでは、コアの CPUID レジスターも読み取ります。このレジスターの最上位バイトは、すべての Cortex-M パーツで 0x41 です。デバッグ機能が無効なままスリープしているコアでは、エラーなしで、どのアドレスからも同じワードが読み返されることがあります。そのような読み取りはデータとして返されず、その理由とともに失敗します。

読み取りによって状態が変化する場合

一部のレジスタは読み取ると状態が変化します。UARTの受信レジスタを読み取ると文字が取り出され、ファームウェアから見えなくなります。ADCのデータレジスタを読み取ると「変換完了」がクリアされます。RTCのサブ秒レジスタを読み取ると、日付レジスタが読み取られるまで時刻と日付が保持されます。STのSVDファイルにはこのためのフィールドがありますが、ほとんど使われていません。

そのため、read_memory はパーツごとではなくペリフェラルブロックごとに独自のリストを保持します。STは同じブロックを複数の製品で再利用しているためです。対象はUART、SPI、I2C、ADCのデータレジスタと、RTCの時刻レジスタです。各項目には、その根拠が measured（指定したパーツで測定済み）か assumed（推定）かが記され、ST独自のマークも使用されます。リストにあるレジスタを名前またはアドレスで読み取ろうとすると、呼び出しで read_effects_ok が渡されていない限り、読み取り前に拒否されます。渡されていれば読み取りが行われ、結果に読み取りによる影響が記されます。ペリフェラル範囲内のその他の読み取りでは、対象となったレジスタ名と、影響が確認されていないことが示されます。これは、影響がないという意味ではありません。最初の検索時にSTのマークのインデックスが作成されます。これには数秒かかり、その後はユーザーのキャッシュディレクトリに保存されます。sample_values にも同じリストが適用されます。また、GDBはウォッチポイントを設定する際に監視対象のアドレスを読み取るため、run_until はリストにあるレジスタの監視を拒否します。

ターゲットの停止

run_until は、プログラムが location、関数、file.c:line、または 0x アドレスに到達するか、watch、変数、またはアドレスに書き込むまで、最大 seconds 秒間実行します。停止した位置でコアを停止状態にし、コールスタック、各フレームの引数とローカル変数、レジスタを返します。関数のインライン化されたコピーでも停止します。ターゲットが実行するELFが必要であり、ブレークポイントが説明対象ではないコードに書き込まれるのを防ぐため、別のプログラムを指定すると拒否されます。実行中のプログラムから開始します。プログラムの早い段階で停止するには、run_firmware で読み込んだ直後に run_until を呼び出してください。

停止が verified となるのは、チップ自身の情報で確認できた場合に限られます。GDBサーバーは停止のたびにデバッグフォルトステータスレジスタを読み取って記録します。その値がブレークポイントまたはウォッチポイントを示し、ブレークポイントの場合はコアがその位置にあるとき、停止は検証済みとなります。ウォッチポイントは書き込み時ではなく、その数命令後に停止するため、結果には停止前の命令が示され、書き込みが停止より前に行われたことが記されます。ウォッチ対象は、アドレスがサイズに合わせてアラインメントされた状態で、アドレスの1、2、または4バイトです。それ以外は拒否されます。制限時間に達した場合は unverified となり、コアはその時点の位置で停止します。パーツのブレークポイントユニットが対応できないアドレスへのハードウェアブレークポイントは拒否されます。RAM内ではGDBがソフトウェアブレークポイントを使用します。

コアが停止していても、チップのほかの部分は停止しません。タイマー、DMA、USB、ウォッチドッグは動作を続けるため、そのことはすべての結果に記されます。run_until を再度呼び出すと停止位置から実行を続けます。ELFを指定した core_registers はその位置のコールスタックを読み取り、release_probe はコアを再開し、動作しているかどうかを示します。run_until は、run_firmware が起動したものも含め、プローブを保持しているGDBサーバーを使用します。保持しているサーバーがない場合にのみ、自身で起動します。そのため、停止してもプローブは解放されません。

SWO

capture_swo は、プローブのSWOピンを通じて、ファームウェアがCortex-MのITM（デバッグユニット独自のprintfチャネル）に書き込んだ内容を読み取ります。これにより、シリアルコンソールのないボードでも実行を確認できます。run_firmware で読み込んでからキャプチャしてください。ファームウェアが書き込みを行うときにコアが動作するクロックである core_clock_hz が必要です。SWOレートはこの値から算出されますが、この値を把握しているのはファームウェアだけです。値が間違っていると、何も出力されないか、判読できないテキストになります。SWOピンはJTAGのTDOであるため、SWDでのみ動作します。

キャプチャはターゲットを変更するため、結果にもそのことが記されます。ITMを有効にし、SWOピンの接続先をアプリケーションからトレースユニットに切り替えます。測定対象となったSTM32F407では、この設定は reset_target 後も保持され、電源を入れ直すまでクリアされませんでした。

設定

設定は環境変数です。MCP クライアントの env ブロックで設定します（MCP クライアントから使用するを参照）。

変数	意味
STLINK_MCP_BOARDS	このプロジェクトが特性評価していないボードを記述する TOML ファイルです。ファイルが存在する場合は、デフォルトで ~/.config/stlink-mcp/boards.toml が使われます
STLINK_MCP_NO_VENDOR_SEED	何らかの値を設定すると、ST のデバイスデータベースから初期値を取得せず、測定値とユーザーが指定したデータだけで動作します
STLINK_MCP_CLT_ROOT	STM32CubeCLT のインストールディレクトリです
STLINK_MCP_CONSOLE	プローブ自身のコンソールではないボードのシリアルコンソールを、プローブごとに指定します。たとえば USB シリアルアダプターの場合は SERIAL=/dev/ttyUSB0 とします。複数指定する場合はカンマで区切ります。プローブリストのマッピングより優先されます。デバイスパスだけを指定した場合、プローブが 1 台だけ接続されている間のみ使用されます
STLINK_MCP_CONSOLE_BAUD	コンソールのボーレートです。デフォルトは 115200 です
STLINK_MCP_GDB_PORT	最初の GDB サーバーポートです。デフォルトは 61234 です。各プローブのサーバーはこのポートと次のポートを使い、次のプローブのサーバーはさらに 4 つ大きいポートから始まります

使用できない設定がある場合、不正なボードファイルと同様に、起動時に 1 行のメッセージを表示してサーバーを停止します。

アドレスの取得元

このツールが使用するすべてのアドレスには出所があり、board_state は値とともにその出所を報告します。

出所	意味
measured	誰かがこの部品で実行し、動作を確認しています
vendor-db	STMicroelectronics のデバイスデータベースから読み取った値です
user-stated	このサーバーの実行者がボードファイルに入力した値です
assumed	誰も測定しておらず、出典にも記載されていない範囲のデフォルト値です

値が動作することが確認されているのは measured のみで、このラベルによって動作が変わります。flash_firmware は、測定済みでないベースアドレスから .bin のアドレスを選ぶことを拒否します。書き込みは永続化され、その後の読み戻しで確認できるのは何が書き込まれたかであり、正しい場所に書き込まれたかではないためです。ELF または HEX ファイルには独自のアドレスが含まれるため、この場合、ベースアドレスは拒否するかどうかの判定にのみ使われ、測定されていない場合はメインフラッシュの範囲内に限定されます（フラッシュへの書き込みを参照）。run_firmware は vendor-db のアドレスへのロードを許可します。誤ったアドレスを使ってもリセットで元に戻せるためです。ただし、結果にはそのアドレスが未測定であることが引き続き表示されます。測定済みのエントリは、初期値として取得したエントリより常に優先されます。データベースではベクターテーブルのアドレスが RAM ベースアドレスとして報告されることがあり、アクセスポートの情報も含まれていません。そのため、初期値を取得した部品ではポート 0 が assumed としてマークされ、board_state が警告を表示します。

vendor-db の値は実行時に、使用している STM32CubeCLT のインストール先にある STM32CubeProgrammer デバイスデータベースから読み取られます。このデータベースは ST のライセンス（SLA0048）の適用対象です。このプロジェクトには、これらのファイルも、それらから派生したテーブルも含まれていません。

独自のボードを記述する

プログラマーが表示するデバイス ID ごとにテーブルを 1 つ含む TOML ファイルを作成し、~/.config/stlink-mcp/boards.toml に保存するか、STLINK_MCP_BOARDS が指す場所に保存します。

["0x419"]
name = "STM32F429 on a NUCLEO-F429ZI"
access_port = 0
ram_load_base = 0x20000000
vector_table_addr = 0x20000000
flash_base = 0x08000000
notes = "addresses from the reference manual, not yet run on the board"

このファイルはサーバーが何かを受け付ける前に読み込まれ、使用できないファイルがあるとサーバーは停止します。このファイルのエントリーは、そのデバイス ID の組み込みテーブルより優先されます。

同じファイルで、組み込みリストが対応していないパーツやペリフェラルについて、読み取りによって状態が変化するレジスターを追加することもできます。

[[read_effects]]
block = "USART"         # the SVD file's groupName, a regular expression
registers = ["RDR"]     # names without the peripheral's prefix
effect = "takes the received character and clears RXNE"

このファイル内のすべての値は user-stated であり、値を measured としてマークする方法はありません。このラベルがあることで、flash_firmware はベースアドレスから .bin のアドレスを選択できます。また、設定ファイルのタイプミスによって取り消し不可能な書き込みが許可されることを防げます。指定された flash_base は、ELF と HEX の書き込みでは、0x08000000 から 0x0800FFFF までのメインフラッシュ領域にある場合にのみ使用されます。このプロジェクトで確認した STM32 には、この領域に RAM、オプションバイト、OTP を保持するものはありません（F405/F407 および H742/H743 ファミリーのリファレンスマニュアルで確認済みです。L0 と L1 は 0x08080000 にデータ EEPROM を保持するため、誤ったベースアドレスから到達できる場合があります）。そのため、タイプミスによって RAM や書き換えできないメモリに書き込まれることはなく、結果にはベースアドレスがユーザー指定であることが示されます。指定されたベースアドレスを使って .bin を書き込むには、address を渡してください。測定済みのファミリーを組み込みテーブルに追加する方法については、CONTRIBUTING.md を参照してください。

問題が発生した場合

まず、インストール時に使用したコマンドに応じて、uvx または uv run を先頭に付けて stlink-mcp --check を実行してください。検出されたものと検出されなかったものが表示されます。

• STM32CubeCLT のインストールが見つかりません。 STM32CubeProgrammer/bin を含むディレクトリを STLINK_MCP_CLT_ROOT に設定してください。
• ST-LINK プローブが見つかりません。 Linux ではプローブに ST の udev ルールが必要です。これは STM32CubeCLT によってインストールされます。インストール後、プローブをいったん抜いてから差し直してください。プログラマーが一覧表示できるのに読み取れないプローブは、通常 USB の問題です。この場合、list_probes にその旨が表示されます。
• シリアルポートを開けません。 Linux ではユーザーが dialout グループに属している必要があります。新しいグループメンバーシップが有効になるのは、次回のログイン時です。
• コアに接続できませんでした。 結果の hint に、考えられる原因が示されます。IDE や、以前のセッションで残された GDB サーバーなど、別のプロセスがプローブを占有している可能性があります。ポートごとに ss -ltnp で確認してください。
• シリアル番号が見つからない、またはファームウェアが古いです。 STM32CubeProgrammer は古すぎる ST-LINK ファームウェアを拒否します。STM32CubeCLT のインストールに含まれる STLinkUpgrade で更新してください（プローブを選択し、Open in update mode を選び、Upgrade をクリックします）。
• run_firmware がイメージを拒否します。 イメージは RAM 用にリンクされている必要があります。RAM からのイメージの実行を参照してください。
• flash_firmware が ELF または HEX ファイルを拒否します。 拒否理由にはベースアドレスの出所と理由が示されます。ベースアドレスがない、仮定されたベースアドレスである、ボードファイルのベースアドレスがメインフラッシュ領域外にある、外部ローダーがある、または接続時にフラッシュサイズを取得できなかった、のいずれかです。フラッシュへの書き込みを参照してください。address を指定した .bin は常に動作します。
• フラッシュから起動した STM32N6 に接続できません。 イメージがデバッグポートを自ら開くか、ボードが開発用ブートモードになっている必要があります。STM32N6を参照してください。
• プローブがすべての接続に対して DEV_TCP_CMD_ERR を返します。 プローブ自体が応答不能になっています。サーバーがプローブを占有している間にプログラムがデバッグポートを閉じた後、STLINK-V3 でこの状態が発生したことがあります。USB 電源を切ってください。プローブを抜くか、ハブが対応していれば uhubctl でハブのポートをいったんオフにしてからオンにします。デバッグライン上に複数のプローブがあるボードでは、すべての電源を同時に切ってください。
• 他のツールでプローブが占有されていると表示されます。 GDB サーバーがプローブを占有しており、stlink-server がインストールされていないため、他から接続できません。STM32CubeCLT の stlink-server をインストールするか、release_probe を呼び出してください。ST の標準スタートアップコードを使った STM32N6 など、デバッグポートを閉じるプログラムの実行後は、次回の実行前にボードの電源を入れ直す必要がある場合があります。

制限事項

• ファームウェアはビルドしません。それはビルドシステムの役割です。
• イメージには署名しません。署名には、プログラマーではなくプロジェクトに属するキーやオプションが必要だからです。
• サポート対象は、STM32CubeCLT を使った ST-LINK のみです。2つ目のバックエンドを追加するための抽象化レイヤーはありません。OpenOCD を追加するには、まず抽象化レイヤーを導入する必要があります。
• Fedora Linux 44、STM32CubeCLT 1.22.0、Python 3.12 で実行し、NUCLEO-N657X0-Q、NUCLEO-H743ZI2、STM32H753I-EVAL2 ボードに搭載された ST-LINK V3 プローブ、および STM32H743 の JTAG コネクターとカスタム STM32F407 ボードで ST-LINK/V2 プローブを使用して実行しています。ほかの Linux ディストリビューションでも動作するはずですが、実行していません。macOS では試していません。Windows 11 では NUCLEO-N657X0-Q を1台使って実行しており、このボードのチェックはすべて通過しました。そこで実行できなかった唯一のチェックは、ST の共有デーモンが起動したままかどうかを確認するもので、サーバーが管理するのは Linux 上のみです。SWO、JTAG、フラッシュへの書き込み、およびほかのボードは Windows で実行していません。
• ST-LINK/V2-1 は試していません。いずれかのプローブで解析の問題が発生した場合は、取得した STM32_Programmer_CLI -l の出力が有用なバグ報告になります。
• STMicroelectronics とは提携していません。

関連プロジェクト

STM32 ボードを操作するほかの MCP サーバーもあり、このサーバーより多くの機能を備えたものもいくつかあります。ビルド、ステップ実行、メモリーへの書き込み、RTT、ほかのプローブやチップへの対応などです。このサーバーが新たに加えるのは、結果から何をチェックしたかが分かる点です。以下のプロジェクトは、最終確認日である 2026年10月7日にソースコードを確認しました。これらでは、コマンドが返ったこと、またはベンダーツール独自のバナーが表示されたことを成功としています。

• phryniszak/stmcp は、ツールの面で最も近いプロジェクトです。同じ STM32CubeCLT ツールを使う MCP サーバーで、GDB セッションを中心に構築されており、実行、一時停止、リセット、ステップ実行、ブレークポイント、メモリとレジスターの読み書き、フォルトレジスターのデコード済みダンプ、式の評価に対応しています。README に記載されているとおり、読み取りは GDB 経由で行われるため、コアが一時停止します。実行はコマンドの戻りをもって完了とみなされ、リセット後のプログラムカウンターは確認されません。同じタスクでの比較： 3 枚のボードでのベンチタスク 7 件（クラッシュ、フォルトハンドラー内のフォルト、ハング、何も出力しないイメージ、ファームウェアを妨げずに読み取る ADC の結果、デバッグポートを閉じるプログラム、起動を確認するためのフラッシュ書き込み）を、同じ 4 つの AI エージェント（Claude モデル 2 つ、Gemini モデル 2 つ）で実行しました。各エージェントとタスクにつき 1 回ずつ、合計 28 回です。stmcp：正解 10 件、一部正解 10 件、不正解 5 件、回答なし 3 件。stlink-mcp：正解 23 件、一部正解 4 件、不正解なし、回答なし 1 件。ツールが確認を行わない場合、stmcp のエージェントは支援を受けられませんでした。2 つのエージェントは、アクセスポート 1 にある STM32N6 のコアに到達できませんでした。1 つはプログラマーの「Start operation achieved successfully」をボードが実行中だと受け取り、ほかのエージェントは ELF のエントリーポイントをプログラムの実行位置として受け取りました。このプロジェクトの作者がタスクを設定し、評価も行っており、ブラインド評価ではありません。そのため、あくまで参考としてご覧ください。詳細は docs/findings.md にあります。
• Zeraissh/stm32-gdb-mcp は、目的の面で最も近いプロジェクトです。STM32 に特化し、エージェント向けに作られており、GDB と OpenOCD、ST-LINK または J-Link を介して、ブレークポイント、ステップ実行、FreeRTOS の認識、フォルトの再構成、RTT および SWO のログ記録、次の手順の提案を含む、デコード済みの構造化された結果を提供します。README に記載されているとおり、読み取りにはコアの一時停止が必要です。
• Adancurusul/embedded-debugger-mcp（Rust。内部で probe-rs または OpenOCD を使用）は、ブレークポイント、ステップ実行、RTT、オプションの読み戻し比較に対応したフラッシュ書き込み、ST-LINK、J-Link、DAPLink およびその他の probe-rs プローブ、複数のアーキテクチャをサポートし、原因を断定せずにレジスターを報告するフォルトツールを備えています。成功を示す文言は、バックエンドの呼び出しが戻ったことを表します。run はその後に何も観測されていなくても「resumed execution successfully」と報告し、reset は失敗する可能性のあるスナップショットからプログラムカウンターを出力し、失敗時にはゼロを表示します。また run_firmware は RTT が接続されているかどうかにかかわらず、「Firmware is now running on target」で終了します。ファイルの参照先は docs/findings.md にあります。
• shieldyguy/stm32-mcp は STM32CubeIDE のヘッドレスビルダーでビルドし、OpenOCD 経由でフラッシュ書き込みとメモリ読み取りを行います。さらに、シリアル関連のツール一式、シンボルによるメモリ書き込み、メモリのライブ監視を追加しています。独自の結果行を報告します。OpenOCD 自身のバナーに基づいて「Flash: OK」と「Verify: OK」を出力し、確認を行わずにリセット要求があれば常に「Reset: OK」と出力します。
• Helistana/mcp-stm32cubeide-server は、フォルトのデコード機能を備え、同じ CubeIDE のループを実行します。ドキュメントは中国語です。
• BlaineMoon30/STM32-DEBUG-MCP は Windows 専用で、OpenOCD と GDB、または STM32_Programmer_CLI を介してビルド、フラッシュ書き込み、デバッグを行い、このプロジェクトと同様に、プログラマーのホットプラグ接続を通じて実行中のボードを読み取ります。
• Klievan/jlink-mcp は Cortex-M 用の SEGGER J-Link プローブを対象としており、このプロジェクトが独自のテストを用意した理由を裏付けています。実機で、失敗した呼び出しが成功と報告されていたため、呼び出しが戻ったかどうかではなく、戻された内容をテストで確認します。

このプロジェクトにない機能が必要な場合は、ほかのプロジェクトをお選びください（対象ユーザー）。各プロジェクトの確認日は 2026 年 10 月 7 日以前であり、その後変更されている可能性があります。

ライセンス

MIT。LICENSE をご覧ください。