MCP client re-opens GET stream indefinitely after HTTP 405

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor’s MCP client (Streamable HTTP, user-agent cursor/1.0.0) keeps sending GET /mcp to open the server-to-client SSE stream after our server answers 405 Method Not Allowed with Allow: POST, DELETE. The MCP spec says a server that offers no SSE stream answers this GET with 405, and the client should stop asking.

Observed on our server (a remote MCP server) over 25 hours, one user: 1,026 GETs, all 405, median gap 29s, against 16 initialize calls. Three other Cursor users show the same pattern at lower volume. Tool calls work normally; only the stream open loops.

Steps to Reproduce

  1. Add a remote Streamable HTTP MCP server that does not offer the SSE stream (answers GET with 405 and Allow: POST, DELETE).
  2. Connect and leave Cursor open.
  3. Watch the server logs: GET /mcp repeats roughly every 30s, each answered 405, with no new initialize in between.

Expected Behavior

After a 405 on the GET stream, don’t reopen it for that session.

Operating System

Other

Version Information

Observed server-side across several users, so the exact IDE version is unknown. MCP client user-agent: cursor/1.0.0 (one user on cursor/3.21.18 darwin arm64).

Additional Information

Possibly related: Two of my remote Streamable HTTP MCP servers reliably fail after Cursor idle-suspends the connection (idle-suspend resume). Staff noted in July that one GET 405 on connect is expected; this is repeated GETs without reconnecting.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @mihir_khandekar, thanks for the report and for the server-side numbers.

For a single connection, Cursor’s client should send that GET once, and after a 405 it doesn’t open the stream again on that connection. What you’re most likely seeing is Cursor opening new connections to your server over and over. Each new connection makes the GET one more time. Cloud features like Grok Bot and Cloud Agents connect from Cursor’s servers and can open a new connection for each task, which would line up with a steady stream of GETs.

To confirm which case you’re hitting, could you share a short excerpt (about 5 minutes) of your request log for one affected user? For each request, we need the timestamp, method, status, source IP, user agent, and whether an Mcp-Session-Id header was present (the value isn’t needed).

Answering the GET with 405 is correct, so nothing needs to change on your side in the meantime.

7

Thanks Colin, you’re right. Our log samples initialize at 1% but records every 405, so the real ratio is about one GET per connection. All the GETs come from three AWS us-east-1 addresses with no Mcp-Session-Id (our server is stateless), which matches Cloud Agents or Grok Bot opening a connection per task. Not a client bug, closing this out.