AI時短ラボ
検証· 約11

MCP Inspectorのv2が標準に──Web・CLI・TUIの3クライアントを1パッケージに統合、Node 22.19以上が必須に

MCPサーバーのデバッグツールMCP Inspectorのv2が、2026年7月28日付でデフォルトのリリースになった。旧来3つに分かれていたパッケージ(inspector-client/server/cli)を1つにまとめ、Web UI・CLI・TUIが共有ランタイム上で同じ挙動をするようになった一方、CLIフラグの意味が変わるなど破壊的変更も伴う。公式リリースノートを確認した。

MCP Inspectorのv2が標準に──Web・CLI・TUIの3クライアントを1パッケージに統合、Node 22.19以上が必須に
執筆・編集:
目次

MCPサーバー(Model Context Protocolでツールを提供するサーバー)を作っていると、「サーバーが実際にどんなツール・リソースを返しているか」を確認する場面がある。その確認用ツールが公式の「MCP Inspector」だ。バージョン2.0.0(2026年7月28日公開)のリリースノートに、v2がデフォルトのリリースになったと明記されている。

3クライアントが1つのランタイムを共有する

利用方法自体はシンプルで、次の3通りの起動方法がある。

npx @modelcontextprotocol/inspector          # web UI
npx @modelcontextprotocol/inspector --cli    # CLI
npx @modelcontextprotocol/inspector --tui    # TUI

設計面での変化は、リリースノートのこの一文に集約されている。

v2 ships as a single package with three clients — a Vite + React + Mantine web UI, a scriptable CLI, and an Ink-based TUI — over a shared @inspector/core runtime, so all three behave identically.

(v2は単一パッケージとして配布され、Vite+React+Mantine製のWeb UI、スクリプト可能なCLI、Ink製のTUIという3つのクライアントが、共有の@inspector/coreランタイムの上で動く。そのため3つとも同じ挙動をする)

v1時代はinspector-clientinspector-serverinspector-cliという別々のサブパッケージに分かれていたが、v2はこれを1パッケージにまとめている。3つのクライアントが同じコアランタイムを共有するということは、Web UIで確認した挙動とCLIで自動化した挙動がズレる、といった問題が起きにくくなる設計だと読み取れる。

v1からの移行で必要な変更

v1からアップグレードする際の破壊的変更も明記されている。

  • Node >= 22.19.0 is now required (was >= 22.7.5).
  • CLI flags changed substantially. In particular --config now means a read-only session file; --catalog is the writable server list.
  • The v1 sub-packages (inspector-client, inspector-server, inspector-cli) are deprecated and not part of v2 — v2 publishes a single package.

(Node.js 22.19.0以上が必須になった(従来は22.7.5以上)。CLIフラグが大幅に変わった。特に--configは「読み取り専用のセッションファイル」を指す意味に変わり、書き込み可能なサーバー一覧は--catalogになった。v1のサブパッケージ(inspector-clientinspector-serverinspector-cli)は非推奨で、v2には含まれない——v2は単一パッケージとして公開される)

--configの意味がv1とv2で入れ替わっている点は、既存のスクリプトやCIをそのまま流用すると動作が変わってしまう可能性がある注意点だ。v1はセキュリティ修正のみを受け取る保守モードとしてv1-latestタグの下で引き続き配布されている、ともリリースノートには書かれている。

--catalog--configの違いを、公式ドキュメント(docs/mcp-server-configuration.md)の表から抜粋すると次の通り。

項目 --catalog <path> --config <path>
Inspectorから書き込み可能か 可能(Inspector自身のサーバー一覧) 不可(そのまま読むだけで、書き込み・シード・移行は一切しない)
ファイルが無い場合 自動作成してシードする エラーになる
デフォルトのパス ~/.mcp-inspector/mcp.json(またはMCP_CATALOG_PATH 無し(必ず明示的に渡す必要がある)
Web UIで編集できるか できる できない(CRUD操作自体が隠される)
用途 自分用の作業中サーバー一覧 自分が書いたものではないファイルに対する読み取り専用セッション

同じドキュメントには、--serverフラグが「--cliのもとでのみサーバーを選択する。Webは無視する(--catalog/--configと併用時は警告、アドホックなターゲットでは無言で無視)。TUIはこのフラグ自体を定義しておらず、未知のオプションとして拒否する」という、クライアントごとの挙動差についての注記もあった。「3つとも同じ挙動をする」という設計目標がありつつも、フラグレベルでは完全に同一というわけではない、という実情が読み取れる。

その後の更新でも活発に開発が続いている

v2.0.0のリリースページ(curlで取得・確認)によると、リリース公開の記録は「cliffhall released this 28 Jul 07:18」、コミットハッシュ7aebf16はGitHubの検証済み署名(GPG鍵ID: B5690EEEBB952194)付き。本記事執筆時点でのリポジトリの星の数は10.8k、フォーク数は1.5kだった(この数字は閲覧時点のスナップショットであり、日々変動する)。

このv2.0.0公開後も開発は続いている。v2.4.0(2026年8月26日公開)のリリースノートを直接確認すると、末尾に「Full Changelog: 2.3.0...2.4.0」という記載があり、この「What's Changed」欄が対象にしているのはv2.0.0からではなく、直前のマイナーバージョンであるv2.3.0からv2.4.0までの差分であることが分かる。この範囲だけで32件のPRがマージされており、そのすべてが同じGitHubアカウント(cliffhall)名義だった。

32件のうち目立つものを挙げると、MCP Appsのフォーム型elicitation(ユーザーへの追加質問)をアプリ側でレンダリングする機能(PR #2083)、OSキーチェーンが無いホスト向けのファイルベース・インメモリのSecretStore(PR #2076)、秘密情報ファイルへのプロセス間ロック追加(PR #2088)に加えて、OAuth関連の細かい修正が目立つ。具体的には「refresh_tokenグラントをサーバーごとにオプトアウト可能にする」(PR #2114)、「トークンレスポンスにscopeが無い場合でも要求したスコープを保持する」(PR #2118)、「ローカルで判定できないtoken_expiredを返さないようにする」(PR #2105)などで、3クライアント共通で「移植性のないツールスキーマにフラグを立てる」機能(PR #2121)も追加されている。v2は7月末の公開から1ヶ月足らずの間に複数回アップデートされる、活発に開発が続くツールになっている。実際に手元のリポジトリのpackage.jsonを確認すると、この記事執筆時点でのバージョンは2.4.0、Node要件は>=22.19.0とリリースノートの記述通りだった。

日本語での言及はまだ限定的

Zenn検索APIで実測したところ、「MCP Inspector」に関連する記事は数件確認できたが、v2への移行に特化して--config/--catalogの意味変更やNode.jsバージョン要件まで踏み込んで書かれた記事は本記事の調査範囲では見当たらなかった。

実際にv1からv2へ移行する作業は行っていない

本記事はMCP Inspector 2.0.0・2.4.0のリリースノート、公式の設定ドキュメント(mcp-server-configuration.md)、リポジトリのpackage.jsonをそれぞれ2026年8月26日〜28日にcurlで取得した内容にもとづく。package.jsonmainブランチを指しているため、以後のリリースで値が変わる(2026年9月4日の再確認では2.5.0だった)。この記事を書いている自分の手元では、実際にv1のinspector-cliを使ったスクリプトを用意し、v2へ移行して--config/--catalogの挙動の違いを再現する検証は行っていない。Web・CLI・TUIの3クライアントが実際に「同一の挙動」であることを、複数のMCPサーバーに対して自分で突き合わせる検証も行っていない。開発が単一のGitHubアカウント名義で進んでいることは確認できたが、それが個人開発なのか、1人が窓口となって複数人のコミットを取りまとめているのかは、この記事の調査範囲では判別できなかった。

関連記事: MCP(Model Context Protocol)とは / MCPサーバーが接続できない時の対処法 / subagentとは

感想・指摘はコメント欄へ。

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事

止まらないAIエージェント「Headlong」──LaudeとMITが1万行未満のBashで作ったの記事画像
検証09.07読了16

止まらないAIエージェント「Headlong」──LaudeとMITが1万行未満のBashで作った

出典 ─ Headlong: a microharness for persistent agents
MCP Python SDK v2安定版──FastMCPがMCPServerに、サーバーはクライアントを呼べなくなった代わりに何が変わったかの記事画像
検証09.05読了11

MCP Python SDK v2安定版──FastMCPがMCPServerに、サーバーはクライアントを呼べなくなった代わりに何が変わったか

出典 ─ modelcontextprotocol/p
壊れたツール呼び出しを自動修復する──Unsloth Desktopの「Self-healing tool calling」を公式の実測データで読むの記事画像
検証09.04読了12

壊れたツール呼び出しを自動修復する──Unsloth Desktopの「Self-healing tool calling」を公式の実測データで読む

出典 ─ unslothai/unsloth v0.1
3つのharnessを1つに『融合』させようとする個人開発、着手から10時間の記録の記事画像
検証09.03読了13

3つのharnessを1つに『融合』させようとする個人開発、着手から10時間の記録

出典 ─ galaxycoils/darius(Git
Terminal-Bench開発元が作った評価基盤「Harbor」──Claude Code・OpenHands・Codex CLIを同じコマンドで数千並列評価するの記事画像
検証09.03読了13

Terminal-Bench開発元が作った評価基盤「Harbor」──Claude Code・OpenHands・Codex CLIを同じコマンドで数千並列評価する

出典 ─ laude-institute/harbor
MCPのフォーム確認、サーバーが提供する専用アプリでレンダリングできるように──4つの条件が揃わなければ自動で従来型に戻るの記事画像
検証09.03読了13

MCPのフォーム確認、サーバーが提供する専用アプリでレンダリングできるように──4つの条件が揃わなければ自動で従来型に戻る

出典 ─ modelcontextprotocol/i
データ漏洩を55の公理でコーディングエージェントに検問させるomds──GEPAでMLパイプラインのコードそのものを進化させる仕組みも同梱の記事画像
検証09.02読了15

データ漏洩を55の公理でコーディングエージェントに検問させるomds──GEPAでMLパイプラインのコードそのものを進化させる仕組みも同梱

出典 ─ spkc83/omds README(Git
PEFTライブラリに3つの新しいLoRA派生手法──HiRA・GLoRA・BEFTを1つずつ読むの記事画像
検証09.02読了14

PEFTライブラリに3つの新しいLoRA派生手法──HiRA・GLoRA・BEFTを1つずつ読む

出典 ─ huggingface/peft v0.20