I am reporting a regression/incompatibility in how Cursor handles MCP servers hosted behind an API Gateway (GCP Apigee). While the connection works perfectly in Kiro, Cursor fails to establish the connection, resulting in a persistent “Waiting for callback” loop and a JSON parsing error.
Steps to Reproduce
Host a Figma MCP server (SSE) behind a GCP Apigee Proxy.
Add the Proxy URL in Cursor Settings via Tools > MCP > Add New MCP Server.
Observe the “Waiting for callback…” state and console logs.
Expected Behavior
It should connect with my Figma MCP without any error.
But i get Console Error: SyntaxError: Unexpected end of JSON input
Handshake Failure: Cursor appears to be probing for .well-known OAuth metadata or specific sub-paths. When the Proxy returns a standard (non-JSON) 404 for these probed paths, Cursor’s internal JSON parser crashes rather than proceeding with the provided URL.
Comparison: Kiro handles the Proxy URL correctly, suggesting it is less rigid regarding the MCP discovery/probing phase or handles gateway 404s more gracefully.
he issue is likely that Cursor’s implementation of the MCP handshake is strictly expecting a JSON response for all discovery probes. Since the Direct URL works, the backend is fine; however, Cursor needs to be more “Proxy-aware” and handle cases where a Gateway returns a 404 for sub-paths without crashing the entire session.
This is a known issue we’re tracking. When Cursor connects to a remote MCP server, it probes for OAuth discovery metadata (e.g. .well-known endpoints). If the server (or an API gateway/proxy in front of it) returns a non-JSON response to those probes (e.g., a standard HTML 404 page), Cursor’s JSON parser fails rather than handling it gracefully and continuing the connection.
This has been confirmed across a few related reports:
We’re tracking this internally and working on making the OAuth discovery probing more resilient!
Could you share your MCP configuration for this server (with any secrets redacted)? Specifically, are you using just a url, or do you also have a headers block with an Authorization header?
We ran into this 404 issue as well in the course of finding a couple of the bugs that Colin referenced.
Cursor should handle HTML 404 and other error pages gracefully during discovery. Our workaround is to return JSON errors for specific resources that Cursor probes (e.g. /.well-known/oauth-protected-resource/api/mcp )*, but we shouldn’t have had to do this.
*Edit: to clarify, the path above is a valid OAuth discovery URI, but we support both API key and OAuth in our plugin, and because of the “MCP headers config ignored…” bug above, implemented a separate endpoint for API key auth, which needs to declare that it doesn’t support OAuth.
When I configure Figma MCP server using direct URL (non-proxy URL) then it works
Direct URL: https://mcp.figma.com/mc
This MCP uses Oauth (username and password on browser)
Cursor UI shows button ‘Connect’ that open the Browser and then user enter the username and password.
Config:
“figma”: {
When I use the Proxy URL (The Google Cloud API URL ), it shows JSON error in Cursor Teminal and at google API side it shows 401.
Proxy URL: https://xyx.com/v1/mcp/figma