MCP Inspector は「ホスト上で何となく動いた」を分解して壊しながら確かめる道具
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- MCP server の初期検証で危ないのは、Claude Desktop や IDE で一度返答しただけで『正しく動く』と判断してしまうことだ。
- MCP Inspector は、読む機能、prompt、tool 実行、通知ログを分けて試し、どの層が壊れているかを切り分けやすくする検査用ツールである。
- 公式の best practices も、接続確認だけで終わらず、機能合意、入力不正、引数不足、同時実行、エラー応答まで試せと書いている。
- つまり Inspector は viewer ではなく、『どこまで壊して確かめたか』を残せるデバッグ手順の中心である。
何が変わったのか
この docs は Inspector を単なる画面一覧ではなく、検査面の分割として説明しています。resources tab では resource 一覧、metadata、content、subscription を確認でき、prompts tab では prompt template と引数を試せます。tools tab では tool schema と実行結果を分けて見られ、notifications pane では server から来た通知を追えます。さらに公式の best practices は、basic connectivity の先に capability negotiation、invalid inputs、missing prompt arguments、concurrent operations、error handling まで development workflow として要求しています。
なぜ重要か
日本の導入初期では、MCP server を host につないで何か返れば前進した気になりがちです。しかし後で痛むのは、引数不足、schema ずれ、並行処理の競合、notification 不達、エラー応答の弱さです。ここを host UI の印象だけで追うと、原因を言語化できないまま時間を失います。Inspector を使う価値は、MCP を理解した気になることではなく、server の壊れ方を protocol の層ごとに説明可能にすることです。
技術的ポイント
- resources tab は参照系の検査面で、resource 一覧、metadata、content、subscription を見られる。読む情報と実行する操作の責務混同を見つけやすい。
- prompts tab は prompt template と引数の確認に向いている。引数不足や説明不足は host よりここで露出しやすい。
- tools tab は tool schema と実行結果を分けて見られる。schema が曖昧だと host 側の失敗が再現しにくくなる。
- capability negotiation は client と server の機能合意であり、つながったことと使えることを分けて確認する段階である。
- 公式は invalid inputs、missing prompt arguments、concurrent operations、error responses まで試せとしており、正常系 1 回成功は合格条件にならない。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| MCP Inspector | MCP Inspector | MCP server の検査とデバッグに使う開発者ツール。接続成功だけでなく壊れ方を分解して観察する。 |
| capability negotiation | 機能合意 | client と server が使える機能を握る手順。つながったことと使えることを分けて確認するために要る。 |
| resource inspection | resource 検査 | resource の metadata や内容、購読挙動を確認すること。読む機能と実行機能の責務混同を見つけやすい。 |
| tool schema | tool スキーマ | tool が受け取る入力形式の定義。ここが曖昧だと host 上の失敗を再現しにくくなる。 |
| concurrent operations | 並行操作 | 複数要求が同時に走る時の挙動。単発成功では見えない競合や順序問題を露出させる。 |
| error handling | エラー処理 | 失敗時の応答形式や扱い方。正常系だけでなく壊れ方を説明可能にするために検査が必要。 |
試すなら
- まず Inspector で basic connectivity と capability negotiation を確認し、host UI の前に protocol 面で握れているかを見る。
- resources、prompts、tools、notifications を順番に開き、正常系だけでなく invalid input や missing arguments を明示的に試す。
- 並行呼び出しとエラー応答を記録し、host 側の『不安定そう』を server 側の具体的な失敗へ言い換えられるようにする。
注意点
- Inspector は検査を助けるが、実際の host UI 上での UX や認可導線まで完全に代替するわけではない。protocol と製品体験は別に見る必要がある。
- 接続成功だけで満足すると、schema ずれや notification 不達のような後から痛む不具合を見逃しやすい。