MCP Inspector ignores resourceMetadataUrl from WWW-Authenticate during OAuth
When an MCP server returns 401 with a resource metadata URL in the WWW-Authenticate header, MCP Inspector still fetches /.well-known/oauth-protected-resource from the server origin instead of the URL the server provided. This is a blocker when testing servers that host multiple resources on one host. Is this supported, and is there a fix?
Originally asked on GitHub: https://github.com/modelcontextprotocol/inspector/issues/576
4 answers
Status: closed as NOT_PLANNED, and the feature is not fully working yet. The root cause is explained, a partial fix is merged, and the remaining piece is still being worked on.
The report (Inspector, typescript-sdk 13.0.1, June 2025) concerns RFC 9728 protected-resource metadata discovery: when a server returns 401 with a resource_metadata URL in the WWW-Authenticate header, the client should hit that URL and only fall back to constructing /.well-known/oauth-protected-resource. Inspector's auth call and the guided OAuth flow both omitted resourceMetadataUrl, so the default well-known path was always used.
Two blockers were identified by maintainers:
-
The WWW-Authenticate header from the server never reached the client through the Inspector proxy — the 401 arrived as a 200. A maintainer's PR #402 tried to pass the header through but stalled with merge conflicts. This was later fixed by PR #924 (merged 2026-01-19), which passes authProvider to the transport constructors so the SDK can extract resource_metadata URLs from 401 responses.
-
Still missing: the resourceMetadataUrl is lost across the OAuth redirect back to Inspector. Two candidate fixes are named in the thread: typescript-sdk PR #1350 (persist the URL across redirects) and Inspector PR #632 (store the resource in session storage). A maintainer said the work should stay open until this step is resolved.
The thread offers no config workaround. Commenters also noted Claude Desktop/Code and Cursor do not implement resourceMetadataUrl either.
Did this work for you?-
What @shays10 tried on GitHub (Outcome unclear)
The reporter built an MCP server that returns 401 with a resource_metadata URL in the WWW-Authenticate header, expecting Inspector to fetch that URL instead of the default /.well-known/oauth-protected-resource. The thread records the expected behavior, not a tested result.
Source: https://github.com/modelcontextprotocol/inspector/issues/576 (opens external site)
Did this work for you?What @cliffhall tried on GitHub (Didn't work)
A maintainer worked on PR #402 to get the WWW-Authenticate header back to the client through the proxy, but the 401 was reaching the client as a 200 and the PR stalled on conflicts.
Did this work for you?What @olaservo tried on GitHub (Partly worked)
A maintainer merged PR #924, which passes authProvider to transport constructors so the SDK can extract resource_metadata from 401 responses. Persisting the URL across the OAuth redirect is still unresolved, with SDK PR #1350 and Inspector PR #632 proposed.
Did this work for you?
Related questions
- MCP Inspector 0.10.2 sends null for unset optional params (error -32602)?
- Why does npx @modelcontextprotocol/inspector fail with 'mcp-inspector: command not found' after 0.10.0?
- How do I increase MCP Inspector's 10-second request timeout?
- MCP Inspector crashes with 'Controller is already closed' on fastmcp Streamable HTTP
- Why does the MCP Inspector Docker container refuse connections on localhost:6274, and how do I fix it?