MCP client cannot connect to modern-only 2026-07-28 Streamable HTTP servers (legacy initialize rejected)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Remote MCP servers that require MCP protocol revision 2026-07-28 only (stateless Streamable HTTP, no legacy initialize handshake, no SSE) fail to connect.

Cursor’s MCP client still performs the 2025-era handshake (initialize / typically 2025-11-25) and either omits MCP-Protocol-Version or sends a legacy body that modern servers reject.

This is a general client-era gap, not a single-server misconfiguration. Example endpoint that cut over on 2026-09-21: https://asdlc.io/mcp (modern-only; verified with @modelcontextprotocol/[email protected] pinned to 2026-07-28).

Steps to Reproduce

  1. Add a remote HTTP MCP server that only accepts MCP 2026-07-28 (no legacy initialize), e.g. in ~/.cursor/mcp.json:

{
“mcpServers”: {
“asdlc”: {
“type”: “http”,
“url”: “https://asdlc.io/mcp”
}
}
}

  1. Restart / reload MCP.
  2. Open Output → MCP and observe the connection logs.

Expected Behavior

Cursor’s MCP HTTP client should negotiate the modern era (2026-07-28): send MCP-Protocol-Version, use server/discover / per-request _meta (no initialize), and successfully list/call tools against modern-only Streamable HTTP servers. Prefer also documenting which protocol revisions the client supports.

Actual:

  1. Streamable HTTP POST fails with JSON-RPC -32020: MCP-Protocol-Version is required; supported: 2026-07-28
  2. Client falls back to SSE → 405 (server is POST-only / no SSE)
  3. Connection ends conn=failed; tools never appear

Operating System

Linux

Version Information

Version: 3.21.16
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
OS: Linux x64 (Fedora)

For AI issues: which model did you use?

N/A — not a model/AI-quality issue; this is the MCP client transport/protocol negotiation layer.

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Independent curl confirms the same rejection for legacy initialize, and that a modern header + legacy initialize body is rejected as header/body mismatch. Servers correctly implementing 2026-07-28 cannot downgrade.

References:

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey @tentakle, thanks for the detailed report, and for the curl checks.

You’ve read it right: Cursor’s MCP client currently speaks the 2025-11-25 revision and earlier, so it still opens with the initialize handshake and doesn’t yet negotiate 2026-07-28. A server that only accepts 2026-07-28 rejects that handshake, and the SSE fallback you saw is our client misreading the 400 as “Streamable HTTP not supported”.

There’s no client-side workaround right now. Adding an MCP-Protocol-Version header in mcp.json won’t help, since a 2026-07-28 header on an initialize body gets rejected as a header/body mismatch (which matches what you saw with curl).

The only workaround today is on the server: the 2026-07-28 spec allows a server to be dual-era, answering initialize for older clients while serving the stateless protocol to newer ones (the TypeScript SDK v2 server entry points can serve both eras from one endpoint). If asdlc.io can keep that legacy path enabled for now, Cursor will connect.

For anyone landing here later: Cursor currently supports MCP protocol revisions 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05 for remote servers.

10

Hey @Colin, thanks for the detailed response. Is there a timeline for when Cursor will support the new MCP 2026-07-28 specification?

11

No timeline at the moment!