“Failed to discover OAuth metadata”

The client got a 401 and could not find the protected-resource or authorization-server metadata that says where to sign in. The three common causes: (1) The browser-based Inspector is blocked by CORS on the metadata endpoints, while command-line clients are not. To tell: The doctor (which is not a browser) passes; the Inspector's browser console shows a CORS error. (2) A server under a path keeps its metadata where the client does not look: no `resource_metadata` in the challenge and no document at the path-aware well-known location, or authorization-server metadata appended to the issuer's path instead of inserted. To tell: The doctor fails at protected-resource metadata, or says the authorization-server metadata was found only at a location the spec does not list. (3) Discovery runs again when Claude Code refreshes a token, and fails then even though the first sign-in worked. To tell: Sign-in works and the error appears hours later; run the doctor at that moment to see whether a document has stopped answering. One command shows which step breaks: npx --allow-git=root github:agentwares/mcp-oauth-doctor https://your-server.example/mcp --client claude-code.

Check your server now

npx --allow-git=root github:agentwares/mcp-oauth-doctor https://your-server.example/mcp --client claude-code

Discovery only: no credential, no client registration. It prints the first broken step, whose it is, and the fix with the spec section.

Who prints it

the MCP Inspector, and Claude Code's debug log. 40 issues across GitHub, counted 8 October 2026.

The three causes, and how to tell them apart

1. Cause 1. The browser-based Inspector is blocked by CORS on the metadata endpoints, while command-line clients are not.
   The check cannot see this one from outside: it happens after consent, or inside the client. The doctor (which is not a browser) passes; the Inspector's browser console shows a CORS error.
2. Cause 2. A server under a path keeps its metadata where the client does not look: no `resource_metadata` in the challenge and no document at the path-aware well-known location, or authorization-server metadata appended to the issuer's path instead of inserted.
   The check fails at step as-metadata. The doctor fails at protected-resource metadata, or says the authorization-server metadata was found only at a location the spec does not list.
3. Cause 3. Discovery runs again when Claude Code refreshes a token, and fails then even though the first sign-in worked.
   The check cannot see this one from outside: it happens after consent, or inside the client. Sign-in works and the error appears hours later; run the doctor at that moment to see whether a document has stopped answering.

Public reports

• modelcontextprotocol/inspector#571, opened 28 June 2025: Dynamic Client Registration with third-party providers (Okta)
• modelcontextprotocol/inspector#675, opened 3 August 2025: the Inspector does not follow the spec's authorization scenarios; 21 reactions
• modelcontextprotocol/inspector#1168, opened 1 April 2026: discovery fails for sub-path servers when protected-resource metadata is unavailable
• anthropics/claude-code#28262, opened 24 February 2026: Claude Code: OAuth tokens not refreshed despite valid refresh tokens

Keep checking

Re-check it every hour and email me when a step breaks: agentcheck's free watch, no account — it follows the sign-in a new client follows, with these same rules.

Nightly, with history: mcpcheck Server Pro re-runs these sign-in checks against the server every night, with 90 days of history, and emails when one fails ($49 a server a month; the first run is free).

Other messages

• “Authorization with the MCP server failed”
• “Couldn't reach the MCP server”
• “Dynamic Client Registration not supported”
• “Incompatible auth server: does not support dynamic client registration”
• “Issuer mismatch”
• “invalid_redirect_uri”
• “Connection expired”
• “token exchange failed”

Written 8 October 2026 from the public issues above. The sign-in check · MCP Liveness · Terms · Privacy