代理開發工具
MCP Inspector 2.4 Unifies Web, CLI, and TUI in One Package; Deploying MCP Apps Requires Three Local Ports
The latest official MCP Inspector package provides browser, command-line, and terminal interfaces through a single executable, sharing a common protocol and OAuth state core. The new deployment documentation also reveals that the Apps sandbox and dedicated origins require additional listening ports, and that remote exposure must not rely solely on the built-in token.
The official Model Context Protocol Inspector 2.4.0 package has moved to npm `latest`. The current v2 architecture consolidates the previously separate Web client, server, and CLI packages into a single `@modelcontextprotocol/inspector` tarball. One `mcp-inspector` executable selects among the Web interface, scriptable CLI, and Ink-based terminal interface. All three frontends share `InspectorClient`, the connection lifecycle, state storage, and OAuth implementation, reducing the risk that different interfaces will exhibit inconsistent protocol behavior against the same server.
What engineering teams should pay attention to in this release is not the interface redesign, but the deployment contract. The Web service uses port 6274 by default. When testing MCP Apps, the browser directly accesses a separate sandbox service, which defaults to port 6275. If an App’s UI resource requests a stable, dedicated origin through `_meta.ui.domain`, Inspector also serves that independent origin on port 6278. If a container exposes only port 6274, ordinary tool inspection will still work, but Apps pages may appear blank. If port 6278 is not exposed for an App that declares a dedicated domain, the backend may even successfully return a URL that the browser cannot reach.
The security boundary can also be easily misunderstood. Inspector can launch local processes on demand, and its home page injects the API token into the HTML so the browser remains operational after a refresh. The official documentation explicitly states that non-browser requests without an `Origin` header are not constrained by the origin allowlist, making the token the primary defense in that case. However, any visitor who can read the home page can also obtain that token. Consequently, binding the service to `0.0.0.0` or placing it behind a public reverse proxy requires additional authentication, an SSH tunnel, or a private network. A custom token must not be treated as complete access control.
Teams upgrading should also note that the minimum Node.js version has increased to 22.19.0, the legacy `-client`, `-server`, and `-cli` subpackages are no longer published, and the semantics of `--config`, `--catalog`, and environment variables have changed. The official project currently provides no clear feature-level changelog from 2.3 to 2.4. Before deployment, teams should therefore rely on the actual tarball, the migration documentation, and container networking tests.