Cursor fails to fall back from Streamable HTTP to SSE transport for remote MCP servers

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Version: Latest as of March 11, 2026 (macOS darwin 24.6.0)

Description:

When connecting to remote MCP servers configured with “url” in ~/.cursor/mcp.json, Cursor first attempts the Streamable HTTP protocol by sending a POST request to the configured URL (e.g., POST /sse). When the server only supports the legacy SSE transport, it returns a 404 with an HTML error body:

Error
Cannot POST /sse

Cursor should fall back to SSE transport (GET request) upon receiving this response, but it does not. Instead, it treats the connection as permanently failed and never attempts the SSE GET handshake.

The server supports GET /sse (returns 200, text/event-stream) but not POST /sse (returns 404 HTML).
Restart Cursor.
Observe in Output > MCP that the connection fails repeatedly with Streamable HTTP error: Error POSTing to endpoint.
MCP Output Log:

[info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown → conn=connecting,auth=unknown
[warning] Transient error connecting to streamableHttp server: Streamable HTTP error: Error POSTing to endpoint: …Cannot POST /sse…
[warning] Connection failed: Streamable HTTP error: Error POSTing to endpoint: …Cannot POST /sse…
[warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown → conn=failed,auth=unknown
No SSE GET attempt is ever logged

Steps to Reproduce

Reproduction Steps:

Configure a remote SSE-only MCP server in ~/.cursor/mcp.json:

{
“mcpServers”: {
“MyServer”: {
“url”: “https://my-sse-server.example.com/sse”,
“headers”: {}
}
}
}

The server supports GET /sse (returns 200, text/event-stream) but not POST /sse (returns 404 HTML).
Restart Cursor.
Observe in Output > MCP that the connection fails repeatedly with Streamable HTTP error: Error POSTing to endpoint.
MCP Output Log:

[info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown → conn=connecting,auth=unknown
[warning] Transient error connecting to streamableHttp server: Streamable HTTP error: Error POSTing to endpoint: …Cannot POST /sse…
[warning] Connection failed: Streamable HTTP error: Error POSTing to endpoint: …Cannot POST /sse…
[warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown → conn=failed,auth=unknown

No SSE GET attempt is ever logged.

Expected Behavior

Expected Behavior:

After the Streamable HTTP POST fails with 404, Cursor should fall back to SSE transport by sending GET /sse with Accept: text/event-stream, as per the MCP transport negotiation spec

Actual Behavior:

Cursor retries the POST request indefinitely and never falls back to SSE. The MCP server remains in failed state.

Verified:

GET /sse returns HTTP 200 (SSE stream works correctly)
POST /sse returns HTTP 404 (expected, server is SSE-only)
“cursor.general.disableHttp2”: true does not fix the issue
Clearing ~/Library/Caches/Cursor does not fix the issue
Adding “transportType”: “sse” to the server config has no effect

Operating System

MacOS

Version Information

Version: 2.6.18
VSCode Version: 1.105.1
Commit: 68fbec5aed9da587d1c6a64172792f505bafa250
Date: 2026-03-10T02:01:17.430Z
Build Type: Stable
Release Track: Default
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like

Hey, thanks for the detailed report. The logs are really helpful.

This looks like a regression in the V2 MCP connection handler. The older V1 client did try an SSE fallback after Streamable HTTP failed, but the V2 FSM skips that step completely.

As a workaround until this is fixed, you can configure the server using command instead of url to force SSE transport through a local proxy. For example, using npx:

{
  "mcpServers": {
    "MyServer": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://my-sse-server.example.com/sse"]
    }
  }
}

mcp-remote bridges remote SSE servers to a local stdio connection, which bypasses the transport negotiation issue completely.

Let me know if that helps.

Thank you it worked :+1:

Thank you for logging this bug. I don’t even know what happened when cursor shows some errors when using MCP.

1 Like

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.