Cursor MCP client probes OAuth even when server signals OAuth unavailable

[rsb]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When connecting to a remote MCP server that returns a 401 with a simple WWW-Authenticate: Bearer realm="..." header (no resource_metadata parameter), Cursor still probes multiple OAuth discovery endpoints before falling back to configured headers.

Per RFC 9728, the resource_metadata parameter in WWW-Authenticate is what signals OAuth discovery availability. Its absence should indicate OAuth is not supported.

Steps to Reproduce

1. Configure a remote MCP server with headers:

{
  "mcpServers": {
    "my-server": {
      "url": "https://example.com/api/mcp/",
      "headers": {
        "Authorization": "Bearer my_api_key"
      }
    }
  }
}

2. Server returns 401 with header:

WWW-Authenticate: Bearer realm="my-api"
(Note: No resource_metadata parameter)

3. Observe Cursor making requests to:

/.well-known/oauth-protected-resource
/.well-known/oauth-authorization-server
/.well-known/openid-configuration
/register (Dynamic Client Registration)

Expected Behavior

When resource_metadata is absent from WWW-Authenticate, Cursor should immediately use configured headers without probing OAuth endpoints.

Actual Behavior:

Cursor probes 4+ OAuth endpoints, fails, then eventually falls back to headers. This adds ~500ms latency and generates unnecessary server errors.

Operating System

Linux

Version Information

Version: 2.6.21
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.8.0-106-generic

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Server Logs Showing the Probe Sequence:

POST /api/mcp/           → 401 (WWW-Authenticate: Bearer realm="...")
GET /.well-known/oauth-protected-resource/api/mcp → 404
GET /.well-known/oauth-protected-resource         → 404
GET /.well-known/oauth-authorization-server       → 404
GET /.well-known/openid-configuration             → 404
POST /register                                    → 404
GET /api/mcp/                                     → 200 (finally uses headers)

Impact:

• Extra latency on every new MCP connection
• Servers without OAuth support see error logs
• Confusing error messages in MCP logs before connection succeeds

Suggested Fix:

Only probe OAuth discovery when resource_metadata is present in the WWW-Authenticate header, per RFC 9728.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for another solid report. It’s clear you’ve really dug into this.

This is a confirmed bug from the same family as your previous thread MCP headers config ignored when server has OAuth discovery. The root cause is the same. The SDK always kicks off the full OAuth discovery flow on any 401 and doesn’t check for resource_metadata in WWW-Authenticate. Your link to RFC 9728 is spot on, that’s the behavior we should be implementing.

I’ve logged this part too, RFC 9728 compliance and checking resource_metadata, along with the main ticket.

Glad the workaround with /api/mcp worked. Have a great weekend!