はじめに
LLMにコーディングさせるためのノウハウも専用ツールも、ここ1年で一気に普及してきました。最近はCursor、Roo Code、Windsurf、あるいはDevinといったソフトが欠かせないプログラマも増えているのではないでしょうか。
ですが、人間だったらすぐ対処できるコード生成がLLMだとうまくできないことがあります。特に、デバッガがあれば人間ならすぐ解決できるような事柄であっても、LLMは元のコードにprint文を足してコードを汚しながら試行錯誤してしまいます。最悪の場合、それでも問題解決ができずに、コードの確認や修正を闇雲に繰り返すこともあります。
LLMがデバッガを操作するためのMCPサーバ
LLMが外部ツールと通信する規格としてMCPが考案され、Web検索やゲームエンジンの操作をLLMから受け付けられるMCPサーバがリリースされるようになりました。
さらに今年になり、Pythonデバッガの操作用のMCPサーバである、mcp-pdbが有志によって開発されました。
これがあれば、LLMがデバッガを操作しながらコード修正できるようになります。
ですが、このmcp-pdbはPython3.13以降でないとインストールできません。少し古いインタプリタを使っている環境では困りますね。
とりあえずPython3.10以降対応にしてみた
元のmcp-pdbのリポジトリをforkしてPython3.10以降対応1にしたものを、私個人のGitHubに置きました。
mcp-pdbのインストール方法
適当なフォルダで私の方のリポジトリをcloneしてください。本記事ではcloneしたフォルダがWindowsの C:\mcp_servers\mcp-pdb\
にできたものとします。
git clone https://github.com/kzkymn/mcp-pdb.git
次に、LLMにデバッグさせたいプログラムを動かすのに使っているPython環境にリポジトリの中身をインストールします。本記事では仮に当該環境のpython.exeがC:\path\of\some_venv\Scripts\python
にあるものとします。
cd C:\mcp_servers\mcp-pdb\
C:\path\of\some_venv\Scripts\python -m pip install -e .
各種ツールへの設定
たとえばRoo Codeの場合、デバッグさせたいプログラムのあるフォルダに.roo
という隠しフォルダを作り、その直下にmcp.json
を作成します。本記事で先に示したディレクトリ構成であれば、JSONファイルの中身は下記のようになります。
{
"mcpServers": {
"mcp-pdb": {
"command": "C:/path/of/some_venv/Scripts/mcp-pdb.exe",
"env": {
"PYTHONIOENCODING": "utf-8"
},
"alwaysAllow": [
"set_breakpoint",
"start_debug",
"send_pdb_command",
"end_debug",
"get_debug_status",
"restart_debug",
"clear_breakpoint",
""
],
"disabled": false
}
}
}
"mcp-pdb"
の"env"
に設定している環境変数のうち、"PYTHONIOENCODING": "utf-8"
の部分は日本語のWindows環境では必須です。UTF-8エンコーディングの.pyファイルをCP932で読み込んでしまい、それがデバッガのエラー終了につながることがあるためです。
もし、デバッガ実行時にだけ使いたい実行ファイルがある場合、事前にパスを通しておいたほうが良さそうです。上記のjsonで"env"
を設定する際に"PATH": "C:\\poppler\\Library\\bin;%PATH%"
という行を書いておけば読み込んでくれたケースもあったのですが、2025/6/23現在、Roo CodeからMCPが起動できなくなる場合があるとわかりました。そのため、先にパスを設定しておくのが無難d
上で書いたものはRoo Code用の設定ですが、MCPサーバの設定をJSONで書けるツールであれば、この例を各ツールの仕様に合わせて少し改変すれば問題なく利用できると思います。
LLMと連携させたときの動作
ここまでの手順を実施すればRoo Codeや場合によっては、他のLLMコーディング用ソフトを使っているときに、LLMからmcp-pdbを呼び出してデバッグができるようになっているはずです。
mcp-pdbを使うことで、この中身をLLMが理解できるか見ていきましょう。
私が趣味で作っているプログラムの中に、MicroSoft Document Intelligence(以下、DI)のOCR結果を利用するものがあります。OCRの結果は独自のオブジェクトに格納され、概要から詳細に至るまで様々な情報がこのオブジェクトのそれぞれのメンバ変数に含まれています。
この変数の中身をRoo Codeを通じてLLMが確認できるか見ていきます。
動作例
mcp-pdbのMCPサーバを有効にした状態でRoo Codeに「Document Intelligence (DI) の詳細な実行結果が格納されている変数をデバッガで特定してください。」という指示をしてみます。すると、内容確認するべき変数di_results
を特定してからmcp-pdbを呼び出し、必要な箇所にブレークポイントを設定します。
この後デバッガをステップ実行してdi_results
に値が代入されるところまで処理を進めます。
次に、di_results
のメンバ変数に入った値を一通り参照していきます。
参照した値をもとに、もともと聞かれていた「Document Intelligence (DI) の詳細な実行結果が格納されている変数」についての回答を生成します。
回答を見る限り、オブジェクトのメンバ変数に格納されたを値をLLMが参照できるという目標は達成できていそうです。
終わりに
本資料では、pdb-mcpを使うことでLLMが所望のPythonプログラムをデバッグ実行をできることまでを示しました。
ただしpdb-mcpを使うことによる最終目標は、デバッグ実行を通じて分かる情報をもとに、LLMがより効率的にコード生成や改修をできるようになることです。そちらについては改めて検証記事を書く予定です。
-
言っても大したことはしておらず、Python3.10以降なら動くことをコードで確認してからpyproject.tomlに記載するPythonバージョンの指定を、
>=3.13
から>=3.10
に変えただけです ↩