MCP remote HTTPS (/mcp/) broken on 3.0.9 — works on 2.6.22

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi,

I’m seeing an issue with remote MCP over HTTPS on Cursor 3.0.9. The same setup works on Cursor 2.6.22 on another machine.

Environment
Broken: Cursor 3.0.9
Working: Cursor 2.6.22

Note: I have downgraded to 2.6.22 and I am able to connect to my MCP thru https no problem. The problem persists when I upgrade to 3.0.9.

MCP server: Self-hosted app exposing Streamable HTTP MCP at https:///mcp/. Auth via X-API-Key header in mcp.json.

mcp.json shape (redacted)
{
“mcpServers”: {
“hestia-ai”: {
“url”: “https:///mcp/”,
“headers”: {
“X-API-Key”: “”
}
}
}
}

What happens on 3.0.9
From View → Output (MCP logs), the client:

Tries Streamable HTTP and reports: Error connecting to streamableHttp server, falling back to SSE: fetch failed
Then: Connecting to SSE server
Then fails with something like: Connect Timeout Error (attempted address: :80, timeout: 10000ms)
So after Streamable HTTP fails, the SSE fallback appears to use HTTP on port 80, which doesn’t match my configured https:// URL and times out (my API is HTTPS-only on 443).

What works on 2.6.22
Same mcp.json and same server: remote MCP connects and works with no fallback to SSE / port 80.

Expected behavior
Remote MCP should successfully use Streamable HTTP over https://host/mcp/ (port 443), same as 2.6.22.
If Streamable HTTP fails, the fallback should not silently retarget to http://host:80 when the user configured HTTPS.

Notes
curl -vI https:///mcp/ from this machine woks so I can narrow whether it’s purely client-side vs network/TLS.

Happy to provide more logs or try a nightly/build you suggest.

Thanks for looking into it.

Melisa

Steps to Reproduce

Steps to reproduce
Install or use Cursor 3.0.9 on macOS
Ensure a remote MCP server is reachable at https:///mcp/ and expects X-API-Key (or equivalent) on requests.
Open Cursor Settings → MCP (or edit ~/.cursor/mcp.json / project .cursor/mcp.json).
Add a remote server entry:
url: https:///mcp/ (include trailing slash if your server requires it)
headers: { “X-API-Key”: “” }
Save the config and fully quit and restart Cursor (or reload MCP if your build supports it).
Open View → Output, choose MCP (or MCP Logs) in the dropdown.
Trigger a reconnect if needed (e.g. open a chat that uses MCP, or toggle the server off/on).
Observe the log: Streamable HTTP connection fails, then fallback to SSE, then a timeout to :80.
Comparison (expected working path):

On Cursor 2.6.22, repeat steps 3–7 with the same mcp.json and same server.
Observe: MCP connects without the SSE fallback and without any connection attempt to port 80.
mcp.json shape (redacted)

{
“mcpServers”: {
“hestia-ai”: {
“url”: “https:///mcp/”,
“headers”: {
“X-API-Key”: “”
}
}
}
}

Expected Behavior

MCP should connect on port 443, no fallback immediately to port 80

Operating System

MacOS

Version Information

Broken version: 3.0.9
Working Version: 2.6.22

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi Melisa,

Thanks for the detailed report and for narrowing it down to a version regression.

This appears to be a separate issue from the known SSE fallback bug. In your case, the initial Streamable HTTP connection itself fails (“fetch failed”) before any transport negotiation occurs, and the SSE fallback connects to port 80 instead of your configured HTTPS port 443.

To help narrow down the cause, could you share:

  1. Full MCP output logs — open View > Output, select MCP Logs from the dropdown, copy the complete log output from a connection attempt (the exact text rather than a summary would be very helpful)

  2. Does your server use a self-signed or custom CA certificate? The newer Electron version in 3.0.X may handle TLS differently

  3. Try switching HTTP compatibility mode — go to Cursor Settings > Network and change the HTTP Compatibility Mode to HTTP/1.1, restart Cursor, and try again

In the meantime, you can work around this by using mcp-remote to bridge the connection over stdio, which bypasses the transport negotiation entirely:

{
"mcpServers": {
"hestia-ai": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://<your-host>/mcp/", "--header", "X-API-Key:<your-key>"]
}
}
}

Let me know if any of those help or if you can share the full logs.