MCP Inspector 2.4、Web・CLI・TUIを単一パッケージに統合――MCP Appsのデプロイでは3つのローカルポートへの対応が必要

Model Context Protocol公式Inspectorの2.4.0パッケージが、npmの`latest`に追加された。現在のv2アーキテクチャでは、従来分かれていたWeb client、server、CLIパッケージを単一の`@modelcontextprotocol/inspector` tarballに集約し、同じ`mcp-inspector`実行ファイルからWeb、スクリプト化可能なCLI、またはInkベースのターミナルインターフェースを選択できる。3種類のフロントエンドは`InspectorClient`、接続ライフサイクル、状態ストレージ、OAuth実装を共有し、同じserverに対するインターフェースごとのプロトコル動作の差異が生じるリスクを低減する。

今回、エンジニアリングチームが注目すべきなのはインターフェースの刷新ではなく、デプロイ契約だ。Webサービスはデフォルトで6274番ポートを使用する。MCP Appsをテストする際、ブラウザは別のサンドボックスサービスへ直接アクセスし、そのデフォルトポートは6275番となる。AppのUI resourceが`_meta.ui.domain`を通じて安定した専用オリジンを要求する場合、Inspectorはさらに6278番ポートで独立したoriginを提供する。コンテナで6274番ポートしかマッピングしていなくても通常のtool検査は動作するが、Appsページが空白になる可能性がある。専用domainを宣言したAppで6278番ポートをマッピングしていない場合、バックエンドがブラウザから接続できないURLを正常に返してしまうことさえある。

セキュリティ境界も誤解されやすい。Inspectorはリクエストに応じてローカルプロセスを起動でき、トップページではAPI tokenがHTMLに埋め込まれるため、ブラウザを再読み込みした後も操作を継続できる。公式文書では、`Origin`ヘッダーのないブラウザ以外からのリクエストはオリジン許可リストの制約を受けず、その場合はtokenが主要な防御手段になると明記されている。しかし、トップページを読み取れる訪問者もそのtokenを取得できる。したがって、サービスを`0.0.0.0`にbindしたり、公開reverse proxy経由で公開したりする場合は、追加の認証、SSH tunnel、またはprivate networkが必要であり、カスタムtokenを完全なaccess controlとして扱ってはならない。

アップグレードする場合は、Node.jsの最低バージョンが22.19.0に引き上げられたこと、旧`-client`／`-server`／`-cli`サブパッケージが公開されなくなったこと、さらに`--config`、`--catalog`、環境変数のsemanticsが変更されたことにも注意が必要だ。公式は現時点で2.3から2.4への明確な機能レベルの変更一覧を提供していないため、デプロイ前には実際のtarball、移行文書、コンテナネットワークのテストを基準に確認するのが望ましい。