Why does MCP Inspector ignore authorization_servers and request the wrong .well-known OAuth paths?
Using MCP Inspector 0.16.2 with http-streamable transport, connecting to an MCP server that responds 401 with a Bearer WWW-Authenticate header causes the Inspector to request /.well-known/oauth-protected-resource/mcp and /.well-known/oauth-authorization-server/mcp, and to ignore the authorization_servers listed in the protected-resource metadata. The reporter asks whether this is a spec misunderstanding or missing implementation.
Originally asked on GitHub: https://github.com/modelcontextprotocol/inspector/issues/675
5 answers
Status: closed as NOT_PLANNED; the thread does not record a fix. Reproductions were reported on Inspector 0.16.2, 0.16.5, and 0.16.7, and maintainers requested example requests/responses or a reproducible repo before investigating further.
What the thread establishes:
- The Inspector first requests /.well-known/oauth-protected-resource/mcp, fails, then correctly fetches /.well-known/oauth-protected-resource (200) which lists authorization_servers. It then requests /.well-known/oauth-authorization-server (with /mcp suffix in some runs) instead of the authorization server URL from the metadata.
- One commenter cited RFC 9728: the well-known URI string is inserted into the protected resource's resource identifier between host and path, so the /mcp-suffixed attempt matches that wording. Another argued the MCP spec's later step requires the authorization server's own well-known path, which is what the Inspector omits.
- Reporters using external IdPs like Microsoft Entra ID or Authentik noted their providers expect paths such as /tenant/.well-known or /application/o/xxx/.well-known/openid-configuration, which the Inspector's behavior does not accommodate.
- Commenter 9 found that with a public client and a separate authorization server, CORS blocked metadata discovery: adding
Access-Control-Allow-Origin: *on both servers allowed metadata to resolve, and token retrieval then worked once the authorization server behaved as a public client.
General advice: open the browser console and check for CORS errors, and verify the well-known metadata paths on the authorization server domain. No config option or version in the thread is confirmed to fix the ignored authorization_servers behavior.
Did this work for you?What @pksorensen tried on GitHub (Didn't work)
Connected Inspector 0.16.2 (http-streamable) to http://localhost:5010/mcp; the server returned 401 with a Bearer WWW-Authenticate header containing resource_metadata. The Inspector requested /.well-known/oauth-protected-resource/mcp, failed twice, fetched /.well-known/oauth-protected-resource (200), then requested /.well-known/oauth-authorization-server/mcp instead of the authorization server listed in the metadata.
Source: https://github.com/modelcontextprotocol/inspector/issues/675 (opens external site)
Did this work for you?What @kevklam tried on GitHub (Didn't work)
On 0.16.7, manually stepping through auth settings produced requests to /.well-known/oauth-protected-resource/_api/mcp, /.well-known/oauth-protected-resource, then /.well-known/oauth-authorization-server and /.well-known/openid-configuration on the MCP server's domain, all ignoring the authorization_servers returned in the metadata. Requests were also duplicated, once with and once without the MCP-Protocol-Version header.
Did this work for you?What @mllab-nl tried on GitHub (Partly worked)
On 0.16.5 with a public client and a separate authorization server (ProtectedMcpServer sample), metadata discovery initially failed due to CORS; adding Access-Control-Allow-Origin: * to both servers let the metadata resolve, and token retrieval succeeded once the authorization server behaved as a public client.
Did this work for you?What @mbroton tried on GitHub (Partly worked)
Tested Inspector 0.16.2 against a custom OAuth server: the sequence was GET /.well-known/oauth-protected-resource/mcp (404), GET /.well-known/oauth-protected-resource (200), GET /.well-known/oauth-authorization-server (200), then a registration step.
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?