“Authorization with the MCP server failed”

claude.ai started a connector's sign-in and it did not finish: discovery, registration, the consent redirect or the token exchange failed, and the message does not say which. The three common causes: (1) Discovery fails or finds the wrong authorization server: no protected-resource metadata, a `resource` that is not the URL entered, or metadata only for a later `authorization_servers` entry. claude.ai then falls back to `/authorize` on the MCP server's own origin. To tell: The doctor fails at protected-resource metadata, `resource` or authorization-server metadata; the browser lands on <your-host>/authorize, as in #78. (2) The authorization server's metadata stops claude.ai: no S256 in `code_challenge_methods_supported`, an `issuer` that is not the URL it was looked up for, or no way to get a client ID. To tell: The doctor fails at PKCE, `issuer` or registration, or shows claude.ai blocked on registration. (3) Consent succeeds and the token exchange does not happen or is refused: with Entra, commenters trace it to the app registration type; claude.ai's documentation also names a token endpoint slower than 10 seconds and cross-host redirects. To tell: The doctor passes every step; your identity provider's sign-in log shows the consent and no token request, or an error on it. One command shows which step breaks: npx --allow-git=root github:agentwares/mcp-oauth-doctor https://your-server.example/mcp --client claude-ai.

Check your server now

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

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

claude.ai and Claude Desktop (a named connector shows "Authorization with <Name> failed"). 172 issues in anthropics/claude-ai-mcp contain this string (58 open), counted 8 October 2026.

The three causes, and how to tell them apart

  1. Cause 1. Discovery fails or finds the wrong authorization server: no protected-resource metadata, a `resource` that is not the URL entered, or metadata only for a later `authorization_servers` entry. claude.ai then falls back to `/authorize` on the MCP server's own origin.
    The check fails at step prm. The doctor fails at protected-resource metadata, `resource` or authorization-server metadata; the browser lands on <your-host>/authorize, as in #78.
  2. Cause 2. The authorization server's metadata stops claude.ai: no S256 in `code_challenge_methods_supported`, an `issuer` that is not the URL it was looked up for, or no way to get a client ID.
    The check fails at step pkce. The doctor fails at PKCE, `issuer` or registration, or shows claude.ai blocked on registration.
  3. Cause 3. Consent succeeds and the token exchange does not happen or is refused: with Entra, commenters trace it to the app registration type; claude.ai's documentation also names a token endpoint slower than 10 seconds and cross-host redirects.
    The check cannot see this one from outside: it happens after consent, or inside the client. The doctor passes every step; your identity provider's sign-in log shows the consent and no token request, or an error on it.

Public reports

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

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