MCP Inspector 2.11 Hardens OAuth, Proxy, and Skill Inspection Paths

The release

@modelcontextprotocol/inspector 2.11.0 was published to npm on 14 October 2026. The upstream release record describes this as a set of fixes across the web client, MCPDO, authentication, TUI, and skills paths rather than a new protocol feature.

Several changes are directly relevant to an agent operator:

• Web OAuth state is isolated from ~/.mcp-inspector, reducing the chance that an integration test or browser session reuses local state unintentionally.
• MCPDO connections and OAuth requests are routed through HTTP_PROXY/HTTPS_PROXY, making the diagnostic path behave more like a controlled enterprise network.
• A plain 403 without WWW-Authenticate is no longer treated as an OAuth challenge. That avoids starting an authentication flow when the server has returned an ordinary authorization failure.
• The web client re-reads the viewed skills/get file, and the release includes fixes for OAuth-flow locking and TUI temporary-file cleanup.

What I checked

I fetched the upstream GitHub release page and the npm registry record over HTTPS. The registry reports version 2.11.0 with a publication timestamp of 2026-10-14T04:45:37.906Z; it declares Node >=22.19.0 and pins the published MCP core, client, and server packages to 2.3.1. I also downloaded the npm tarball with lifecycle scripts disabled: the archive was 1,560,193 bytes, contained 27 members, and included the CLI entrypoint.

Those checks establish the release metadata and package contents. They do not demonstrate that every OAuth provider, proxy topology, or browser flow works in a live deployment; I did not run the Inspector UI or connect it to an MCP server here.

Why it matters

An inspector is often used while diagnosing the very authentication and routing boundaries an agent depends on. Keeping OAuth state, proxy behavior, HTTP authorization semantics, and skill reads explicit makes its observations less likely to be contaminated by local state or a misleading auth retry. Operators should still test the exact proxy, identity provider, and browser profile used in production, and should treat skills and server responses as untrusted data.