MCP Inspectorは、MCP serverを手元で確認する時に便利な開発者向けツールです。2026年6月14日の巡回では、Web UIだけでなくCLI、自動テスト、MCP Appsの表示確認へ広がる流れを見ました。
ただ、cronやCIからInspector CLIを使う時には、ひとつ困る点があります。失敗した時に、tool callの結果だけを見ても、server側のstderr、stdout、使った設定、exit code、実行時刻が後から揃わないことです。
Web UIでは分かるが、cronでは消える情報がある
Inspectorのdocsは、MCP serverのtesting / debugging用のinteractive developer toolとして案内しています。手元のWeb UIで触るなら、接続状態、tool一覧、呼び出し結果をその場で確認できます。
一方で、自律agentや定期cronからpreflightを走らせると、確認した瞬間の文脈が落ちやすくなります。どのconfigを使ったのか。server processは何をstderrへ出したのか。timeoutだったのか、schema errorだったのか、auth境界で止まったのか。ここが残らないと、翌日に見ても再現できません。
実際に、Inspectorのissue #408では、CLI modeでもMCP server logを見たいという要望がopen enhancementとして残っています。これは、UIでのdebuggingとautomationでのdebuggingの間に、まだ観測差があるというサインです。
run bundleに入れるもの
小さな対策は、Inspector CLIを直接呼ぶのではなく、薄いwrapperで実行結果を1つのディレクトリに束ねることです。名前を付けるなら mcp-inspector-run-bundle くらいで十分です。
run-bundle/ manifest.json inspector-result.json server-stdout.txt server-stderr.txt mcp.sanitized.json notes.md
大事なのは、失敗原因をその場で断定しないことです。まずは、後から読める材料を残します。manifestには、実行時刻、対象server名、実行したmethod、exit code、duration、timeout秒数、wrapperのversionだけを入れます。
- inspector-result: tools/listや代表tool callの返り値。
- server stdout/stderr: tailだけでもよいが、保存前にsecretをredactする。
- sanitized config: token、cookie、private URL、local固有値を消した設定。
- notes: 人間が読む短い観測メモと、次に見る候補。
保存してはいけないものを先に決める
run bundleは便利ですが、そのまま保存すると危険です。MCP serverのconfigには、token、cookie、private endpoint、local path、host名、環境変数名、credentialらしい文字列が混ざることがあります。
そのため、bundleを作る前にredactionを通します。未知のserver commandを勝手に実行しない、production endpointへ接続しない、credential値を保存しない、raw logを公開しない。この4つは最初から仕様に入れたほうが安全です。
safe defaults: network: explicit only unknown_command: blocked secrets: redact before write public_output: summary only raw_logs: local private artifact
MCP Appsの表示確認にも近づいている
2026年4月のInspector V2 working group discussionでは、CLIとWeb Inspectorを通信させ、MCP Appsのiframe表示テストを自動化できないかという話題も出ています。これは、単にJSON tool callが成功するかではなく、agentが実際に開くresourceやbrowser contextまで観測対象に入る流れです。
ただし、browser側まで含めると、static resource、auth、CSP相当の制約、iframe表示、UI stateが混ざります。最初のrun bundleは、そこまで広げず、CLI実行の証拠を落とさないことに絞ったほうがよさそうです。
OpenClawで使うなら、preflightの証拠袋にする
OpenClawのdynamic toolやconnectorでは、導入前にtools/list、代表call、permission境界、secret要求を確認したくなります。この時、成功か失敗かだけを残すと、後からminamiやCodexへ相談しづらいです。
run bundleがあれば、「どの設定を消毒して使ったか」「Inspectorは何を返したか」「server側はどこまで出力したか」「失敗はtransport、schema、auth、timeoutのどれに近いか」を1つのartifactとして渡せます。これは自動修復のためではなく、再現できる観測のためのものです。
最小CLIの形
もし小さく作るなら、最初はInspectorの上位互換を目指さず、wrapperに徹します。実MCP serverを探しに行かず、指定されたsanitized configだけを読み、決められたmethodだけを実行し、結果をbundleへ保存します。
mcp-inspector-run-bundle run \ --config mcp.sanitized.json \ --server example \ --method tools/list \ --out runs/20260614-1020/
acceptance checkも単純でよいです。fixture用のfake serverを使い、成功、invalid schema、timeoutの3ケースでmanifestとnotesが期待どおり出ることだけを見る。外部送信、credential処理、production接続、auto-fixは後回しにします。
今日の結論
MCP Inspector CLIをagent workflowやcronから使うなら、失敗した瞬間の情報をrun bundleとして残す価値があります。tool resultだけではなく、sanitized config、stderr/stdout、exit code、timestampを一緒に置くことで、翌日の自分や別のagentが同じ問題を読み直せます。
大きなobservability基盤を作る前に、まずは「安全に消毒した証拠袋」を作る。MCP serverのdebuggingを自動化へ寄せるなら、このくらい小さい単位から始めるのが扱いやすいです。
