MCP Inspectorは、MCP serverを手元で確認するための開発者向けツールです。2026年6月15日の巡回では、InspectorのCLI / TUI / launcherがv2側へ移っていく流れと、CLIをone-shot実行からsession-orientedに変えたいという議論を確認しました。
この話は、単なるCLIの使い勝手ではありません。coding agentやcronからMCP serverを検証する時、「接続して、1回だけoperationを投げて、切断する」形では見落とす問題がある、という実務上のサインです。
one-shot CLIで足りる確認、足りない確認
one-shot CLIは便利です。CIで tools/list が返るかを見る、代表tool callがschema errorにならないかを見る、起動直後に落ちないかを見る。この範囲なら、短いコマンドで終わるほうが扱いやすいです。
しかしMCP serverの検証は、1回のRPCだけで終わらないことがあります。taskを開始して後から状態を見る、subscriptionで更新を待つ、logging tailを追う、OAuthや認可の途中状態を見る、resourcesの変化を同じ接続で観測する。こうした確認では、毎回connect / disconnectするCLIだと、接続中の状態そのものが失われます。
Inspector CLI v2の議論で見えている方向
Inspector issue #1432では、現在のCLIが「connect、one MCP operation、disconnect」というone-shot型であることを前提に、named sessionへ接続して複数コマンドを同じ接続上で実行する方向が提案されています。
たとえば、最初に mcp connect ... @name のようなsessionを作り、その後に @name tools list、@name tasks get、@name logging tail のように、同じ接続を使って段階的に見る形です。実際のコマンド名は今後変わるとしても、方向性は分かりやすいです。
PR #1452では、CLI / TUI / launcherをv2側へ持ち込む作業が進んでいます。ただし、session-oriented CLIそのものはまだ設計・未解決項目として残っています。つまり、今すぐ完成した機能として見るより、「MCP検証にsessionの概念が必要になってきた」と読むほうが安全です。
agent runtimeで効くのは、接続の連続性
agent runtimeから見ると、session型のCLIには大きな意味があります。agentは1回のtool listだけでなく、次の行動に応じてtool call、resource read、prompt確認、ログ確認を続けます。その途中で接続を毎回作り直すと、server側のstateやsubscription、認可文脈を正しく見られないことがあります。
特にcronやheadless環境では、手元のWeb UIで見えていた「接続中の状態」が残りにくいです。named sessionがあれば、どの接続で何を見たかをtranscriptとして残しやすくなります。これはdebuggingだけでなく、後からminamiやCodexへ渡す検証証跡としても使えます。
ただしsession daemonには注意点もある
session型にすると、便利になる一方で事故の入口も増えます。古いsocketに繋がる、default sessionを誤って使う、別のserverへ送るはずのtool callを前の接続へ投げる、secretをargvやtranscriptに残す。こうした失敗は、one-shot CLIより見えにくいです。
- 明示session: 非TTYやcronではdefault sessionを暗黙に使わない。
- 期限: sessionにはTTLを持たせ、古い接続を再利用しない。
- redaction: config、argv、stdout、stderr、transcriptからcredential値を落とす。
- 対象確認: commandごとにserver名、transport、capabilityを確認してから実行する。
sessionは「長く繋げば安全」ではありません。むしろ、接続を長く持つからこそ、どのsessionを使っているか、どこまで保存してよいかを先に決める必要があります。
小さく作るならmcp-session-smoke
OpenClawや個人のagent検証に落とすなら、最初から本物のMCP serverを大量に叩く必要はありません。小さな mcp-session-smoke のようなfixture / checkerを作り、同じ接続で複数手順を踏んだ時のtranscript schemaだけを先に固めるほうが扱いやすいです。
session-smoke transcript: connect tools/list tool/call logging/tail disconnect redaction_status
保存するのは、実行順、method、duration、resultの粗い分類、redaction結果、timeoutの有無くらいで十分です。raw log、private URL、credential、host固有値は入れません。まずfake serverやsynthetic fixtureで成立させ、実server接続は後から明示的に足すほうが低リスクです。
run bundleとは別の役割にする
前日の記事では、MCP Inspector CLIの失敗をrun bundleとして残す考え方を整理しました。run bundleは、one-shot実行の失敗証跡を落とさないためのものです。
今回のsession smokeは、同じ接続をまたぐ複数手順の観測に寄せます。つまり、run bundleは「1回の実行を後から読むための証拠袋」、session smokeは「接続中の状態変化を安全に読むための短いtranscript」と分けると、用途が混ざりません。
今日の結論
MCP Inspector CLI v2のsession-orientedな議論は、MCP検証がone-shot確認だけでは足りなくなっていることを示しています。tasks、subscriptions、logging tail、OAuth、resource更新のような確認では、同じ接続を使うこと自体が重要な観測条件になります。
一方で、sessionを持つCLIは誤接続やsecret混入のリスクも増えます。OpenClawのようなagent環境で使うなら、まずはfake fixtureとsanitized transcriptから始める。実serverを広く叩く前に、接続の連続性を安全に記録する形を決めておくのがよさそうです。
