代理開發工具
MCP Inspector 2.4 將 Web、CLI 與 TUI 統一封裝，部署 MCP Apps 須處理三個本機埠
官方 MCP Inspector 最新套件以單一執行檔提供瀏覽器、命令列及終端介面，並共用協定與 OAuth 狀態核心。新版部署文件同時揭露 Apps 沙箱與專用來源需要額外監聽埠，遠端暴露時不能只依賴內建 token。
Model Context Protocol 官方 Inspector 的 2.4.0 套件已進入 npm `latest`。目前的 v2 架構把原先分散的 Web client、server、CLI 套件收斂為單一 `@modelcontextprotocol/inspector` tarball，並由同一個 `mcp-inspector` 執行檔選擇 Web、可編寫腳本的 CLI 或 Ink 終端介面。三種前端共用 `InspectorClient`、連線生命週期、狀態儲存與 OAuth 實作，降低不同介面對同一伺服器產生協定行為差異的風險。
這次值得工程團隊注意的不是介面改版，而是部署合約。Web 服務預設使用 6274；測試 MCP Apps 時，瀏覽器會直接存取另一個沙箱服務，預設為 6275。若 App 的 UI resource 透過 `_meta.ui.domain` 要求穩定、專用來源，Inspector 還會在 6278 提供獨立 origin。容器只映射 6274 時，一般工具檢查仍可運作，但 Apps 頁面可能空白；宣告專用 domain 的 App 若未映射 6278，後端甚至可能成功回傳一個瀏覽器無法連線的網址。
安全邊界也容易被誤判。Inspector 可按請求啟動本機程序，且首頁會把 API token 注入 HTML，讓瀏覽器重新整理後仍可操作。官方文件明確指出，缺少 `Origin` 標頭的非瀏覽器請求不受來源允許清單約束，此時 token 是主要防線；但能讀取首頁的訪客也能取得該 token。因此，把服務綁至 `0.0.0.0` 或公開反向代理，必須另加身分驗證、SSH tunnel 或私有網路，不能把自訂 token 當成完整存取控制。
升級者還須留意 Node.js 最低版本提高至 22.19.0、舊 `-client`／`-server`／`-cli` 子套件不再發布，以及 `--config`、`--catalog` 和環境變數語義改變。官方目前未提供清楚的 2.3 至 2.4 功能級變更清單，部署前宜以實際 tarball、遷移文件及容器網路測試為準。