Impossible to connect to MCP server: AS metadata discovery crashes instead of falling back to OIDC

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Description

When authenticating to an MCP server that requires OAuth in Cursor Desktop, connection fails immediately with log:

OAuth callback exchange failed for user-test-admin-mcp-server: Unexpected token '<', "<!doctype "... is not valid JSON

The client crashes on the first failed discovery attempt. No authorization prompt or browser redirect ever appears — the failure happens during OAuth Authorization Server (AS) metadata discovery, before the actual auth flow starts.

Steps to Reproduce

OAuth server configuration (prerequisites for reproduction)

The MCP server’s OAuth AS used to reproduce this has three relevant properties:

  1. It only exposes OIDC discovery metadata, at /{path}/.well-known/openid-configuration — it has no RFC 8414 metadata endpoint anywhere.
  2. The domain has a catch-all redirect configured: any request to a path that isn’t explicitly handled gets redirected to a generic HTML page (200 OK, HTML body).
  3. That catch-all also covers /.well-known/oauth-authorization-server/{path} — i.e. exactly the path where RFC 8414 metadata would live, and exactly the URL the SDK tries first during discovery.

Steps to reproduce

  1. Configure an MCP server whose OAuth AS matches the server configuration described above (OIDC-only metadata, catch-all HTML redirect covering the RFC 8414 path).
  2. Enable the server and attempt to authenticate to that server.
  3. Observe error — no fallback to the OIDC discovery endpoint occurs, and authentication cannot proceed.

Expected Behavior

On a non-JSON 200 OK response from one discovery endpoint, the client should fall back to the next discovery endpoint in the MCP auth spec’s priority order (ultimately reaching OIDC discovery at the subpath), rather than aborting the entire auth attempt.

Operating System

Linux

Version Information

IDE:
Version: 3.14.7
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 6.8.0-40-generic

Additional Information

Root cause

The same issue appears in MCP TypeScript SDK (not sure whether the Cursor Desktop uses MCP TypeScript SDK to handle OAuth authorizations): modelcontextprotocol/typescript-sdk#2126:

  • Per RFC 8414 §3.2, a valid AS metadata response must return 200 OK with a JSON body.
  • Given the server configuration above, the SDK’s RFC 8414 discovery request lands on the domain’s catch-all and gets back 200 OK with an HTML page instead of a 404 or a JSON error.
  • The SDK calls response.json() on this response without first validating the content is actually JSON. Parsing the HTML body throws a SyntaxError.
  • Instead of treating this as a failed discovery attempt and falling back to the next discovery URL (per the MCP auth spec, which requires trying multiple endpoints in sequence — notably the OIDC endpoint at /{path}/.well-known/openid-configuration), the SDK lets the SyntaxError propagate, aborting the entire auth flow. Since the OIDC path-append endpoint is the only metadata endpoint this server actually has, this bug makes auth completely impossible against it.
  • The fix proposed upstream: wrap response.json() in a try/catch; on parse failure, cancel the response body and continue to the next discovery URL instead of crashing.

Logs

026-08-05 14:07:19.169 [info] [Shared MCP process] connecting streamableHttp for "test-mcp-server" (user-test-mcp-server)

2026-08-05 14:07:19.170 [info] [Shared MCP process] [V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown

2026-08-05 14:07:19.526 [warning] [Shared MCP process] MCP HTTP exchange completed

2026-08-05 14:07:20.596 [warning] [Shared MCP process] Transient error connecting to streamableHttp server: Unexpected token '<', "<!doctype "... is not valid JSON

2026-08-05 14:07:20.597 [warning] [Shared MCP process] Connection failed: Unexpected token '<', "<!doctype "... is not valid JSON

2026-08-05 14:07:20.598 [warning] [Shared MCP process] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the detailed report. The logs, repro steps, and the upstream link really help.

You’re basically right: if the discovery endpoint returns a non-JSON 200 OK, the client should treat that attempt as failed and move on to the next endpoint by priority, eventually reaching OIDC discovery on the subpath, instead of stopping the whole auth flow. We’re tracking this, but I can’t share an exact timeline yet.

As a temporary workaround, if you control the OAuth AS, configure your server so /.well-known/oauth-authorization-server/{path} returns a real 404, not an HTML catch-all page with 200. Then RFC 8414 discovery will fail cleanly and the client will fall back to your OIDC endpoint /{path}/.well-known/openid-configuration, so auth can succeed. It’s important that it’s exactly 404. If you return other content, even valid JSON, the client may treat it as real AS metadata and go down the wrong path.

A similar workaround via reverse proxy (Caddy) was discussed here: MCP headers config ignored when server has OAuth discovery. There’s an example using respond 404 for /.well-known/oauth-* that you can use as a starting point.

I’ll reply here when there’s an update. Let me know if the workaround helped.