MCP Inspector CLIで、ユーザー確認待ちを再現できるfixtureにする

MCP server を作る時、Inspector の画面で tool や resource を試すだけなら、最初の動作確認はかなり楽です。ただ、agent runtime や CLI/TUI へ組み込む段階になると、別の問題が出ます。ユーザー入力待ち、URL elicitation、外部ブラウザでの完了待ちのような状態は、あとから同じ手順で再現しにくいのです。

2026年6月5日の調査では、modelcontextprotocol/inspector の CLI mode と、2026年6月4日に出た Inspector 0.22.0 を確認しました。0.22.0 では URL-mode elicitation support が入り、MCP server 開発は「UIで見る」だけでなく「CLIで再現する」方向にも寄っています。

UI確認だけだと、詰まった状態を共有しづらい

Inspector の UI は、server の tool 一覧、resources、prompts、呼び出し結果を見る入口として便利です。一方で、問題が「返り値が違う」ではなく「途中でユーザー確認待ちになった」「外部URLを開いたあと進まない」「task/status が loop している」に近づくと、スクリーンショットや口頭説明だけでは弱くなります。

実際、公開 issue でも URL elicitation を open した瞬間に accept した扱いにするのではなく、明示的な complete / cancel を持たせたいという議論があります。別の issue では、input_required が status/list loop になり、どの層の状態遷移が詰まっているのか見えにくい報告もあります。

こういう問題は、単に「MCP server が落ちた」より厄介です。server、client、Inspector、外部ブラウザ、ユーザー操作の境界にまたがるからです。だからこそ、再現用の fixture を小さく残す価値があります。

Inspector CLIをpreflightの入口にする

Inspector の README では、CLI mode から tools/list、tools/call、resources/list、prompts/list のような操作を scriptable に叩けることが示されています。これは、MCP server を coding agent に足す前の preflight と相性がよいです。

• server が起動できるか
• tool / resource / prompt の一覧が取れるか
• 代表的な tool call が成功するか
• 入力不足時に、期待した input_required へ落ちるか
• URL elicitation の accept / cancel / completion 待ちを区別できるか

ここまでを人間の手順書だけにしておくと、時間が経つほど失われます。CLI で叩いた入力、期待した状態、実際の戻り値を fixture 化しておけば、あとで client を差し替えた時にも同じ問題を見直せます。

fixtureに残すなら、値より状態を見る

注意したいのは、fixture は本物の認証情報や実環境URLを残す場所ではないことです。MCP の elicitation まわりでは、password、API key、access token、payment credentials のような機密値を client や LLM context に入れない設計が大事です。再現用 fixture も同じで、値ではなく状態遷移を残すべきです。

• 残す: request 種別、期待状態、accept / decline / cancel の分岐、completion notification の有無
• 残す: target が外部URL型か、form型か、serverがどの理由を表示したか
• 残さない: 実 token、cookie、API key、private URL、実ユーザーID、実host名
• 残さない: production の raw log、credential を含む設定、個人や組織を相関できる identifier

この線引きを守ると、fixture はデバッグのための安全な共通語になります。問題が再現した時も、「どの credential を入れたか」ではなく「どの状態から戻れなくなったか」を話せます。

最小構成はJSONと短いMarkdownでよい

大きな framework を作らなくても、最初の形はかなり小さくできます。たとえば mcp-elicitation-replay-fixtures のような private prototype なら、次の3つだけで十分です。

• fixtures/*.json: 入力不足、URL elicitation、cancel、timeout などの合成シナリオ
• scripts/replay-inspector-cli.sh: Inspector CLI で代表操作を再実行する薄い wrapper
• EXPECTED.md: 各 scenario で期待する状態遷移と、失敗時に見る観点

重要なのは、fixture を「正しい出力のスナップショット」だけにしないことです。ユーザー確認待ちは、成功結果よりも中間状態が大事です。waiting_for_user、opened_external_url、completion_received、cancelled のように、実装ごとの名前は違っても、観察したい状態を明示しておくと読み直しやすくなります。

coding agentへ渡す前に見るチェック

MCP server を coding agent に渡す前のチェックとしては、次のような順番が扱いやすいです。

1. Inspector CLI で server 起動と tools/list を確認する
2. 副作用の小さい tool call を1つだけ実行する
3. 入力不足時の状態が、error ではなく user action 待ちとして見えるか確認する
4. URL elicitation では、accept と complete を同一視していないか見る
5. cancel / timeout / unknown completion ID を fixture に入れる

この確認をしておくと、agent 側で失敗した時に「agent が悪い」「MCP server が悪い」とすぐ決めつけずに済みます。起動、schema、tool call、ユーザー確認待ち、外部完了通知のどこで崩れたかを分けて追えます。

まとめ

MCP Inspector の CLI mode と URL-mode elicitation support は、MCP server 開発を少し運用品質へ寄せる合図に見えます。UI で動くことを確認するだけでなく、CLI で再現できる fixture を残す。特に input_required や URL elicitation のようなユーザー確認待ちは、値ではなく状態遷移として保存する。

この小さな習慣があるだけで、MCP server を coding agent や自動化環境に入れる前の不安はかなり減ります。便利な server を増やすほど、確認待ちを再現できる材料も一緒に残しておくべきです。