MCP Server Regression - MCP OAuth registration fails

Support Bug Reports
1

Hi Cursor team,

I’m connecting Cursor to our MCP Server and I hit a regression: connection worked until recently; now MCP fails during OAuth-related setup.

Has something changed in how Cursor handle MCP connectors recently?

Logs

2026-05-06 16:19:50.872 [info] [V2] Handling DeleteClient action, reason: server_disabled

2026-05-06 16:19:51.033 [info] [V2] Handling CreateClient action

2026-05-06 16:19:51.033 [info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown → conn=connecting,auth=unknown

2026-05-06 16:19:51.682 [info] MCP OAuth provider initialized

2026-05-06 16:19:51.874 [warning] MCP HTTP exchange completed

2026-05-06 16:19:52.061 [info] MCP HTTP exchange completed

2026-05-06 16:19:52.246 [info] MCP HTTP exchange completed

2026-05-06 16:19:52.254 [info] Registration lock acquired — this provider will register

2026-05-06 16:19:52.254 [info] No stored client information found

2026-05-06 16:19:52.442 [warning] MCP HTTP exchange completed

2026-05-06 16:19:52.443 [warning] Error connecting to streamableHttp server, falling back to SSE: HTTP 400: Invalid OAuth error response: SyntaxError: Unexpected token ‘N’, “No MCP con”… is not valid JSON. Raw body: No MCP connector found for redirect uris [“cursor://anysphere.cursor-mcp/oauth/callback”, “https://www.cursor.com/agents/mcp/oauth/callback”, “http://localhost:8787/callback”].

2026-05-06 16:19:52.650 [warning] MCP HTTP exchange completed

2026-05-06 16:19:52.651 [error] Error connecting to SSE server after fallback: SSE error: Non-200 status code (405) SSE error: Non-200 status code (405)

2026-05-06 16:19:52.653 [warning] Connection failed: SSE error: Non-200 status code (405)

2026-05-06 16:19:52.653 [warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown → conn=failed,auth=unknown

2026-05-06 16:19:52.653 [info] CreateClient completed, connected: false, statusType: error

Comments

On our end we whitelist

but not http://localhost:8787/callback (though it was working fine until recently)

6

A recent update changed Cursor to send all three OAuth redirect URIs during Dynamic Client Registration, including http://localhost:8787/callback (used for CLI auth). MCP servers that validate the full redirect_uris set against a strict allowlist reject the registration if they don’t recognize all three.

Workaround: Add http://localhost:8787/callback to your MCP server’s OAuth connector allowlist alongside the two you already have. This should unblock you immediately.

Our team is actively working on a fix that will only send the relevant redirect URIs during registration (rather than all three unconditionally). This should land in the next week or so.