[Technical Question]Cursor MCP Client handshake

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi Cursor team, I’m integrating a Python FastMCP server with Cursor and need clarity on your MCP client’s HTTP handshake so we can align our server.

Context

  • Server: Python FastMCP (uvicorn), endpoint: https://myserver/mcp/
  • Health/readiness: OK (/health → 200)
  • Goal: Make Cursor work over HTTP (stdio not an option)

Observed behavior

  • Cursor attempts streamable HTTP with a POST-first initialize, then falls back to SSE.
  • Server responses:
    • POST /mcp/ → 400 “No valid session ID provided”
    • GET /mcp/ → 406 with body: “Client must accept text/event-stream”
  • Ingress sets mcp_affinity cookie and server sends mcp-session-id, but POST still 400 without a prior handshake.

Questions

  • Does Cursor’s HTTP client expect POST-first (no prior GET) for streamable HTTP?
  • If yes, what minimal headers should the POST include (e.g., Accept, mcp-protocol-version)?
  • If a GET handshake is required, what exact request (method + Accept) should we serve so Cursor will bind subsequent POSTs?
  • For SSE fallback, what endpoint and headers does Cursor expect?

What we can change

  • We can switch the server to stateless HTTP (POST-first JSON-RPC, no session requirement) if that’s what Cursor expects.
  • Alternatively, we can add an SSE endpoint compatible with Cursor’s fallback.

Thanks for confirming the expected handshake so we can implement the correct server behavior.

Steps to Reproduce

More of a technical question than a bug

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.5.11
VSCode Version: 1.99.3
Commit: 2f2737de9aa376933d975ae30290447c910fdf40
Date: 2025-09-05T03:48:32.332Z (6 days ago)
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

We are seeing the same issue.

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