The Legacy HTTP+SSE Transport and How to Migrate

HTTP+SSE was MCP's original transport for remote servers, defined in the 2024-11-05 specification. The client opened a long-lived Server-Sent Events (SSE) connection to receive messages and sent its own messages to a separate POST endpoint. It was replaced by Streamable HTTP in 2025-03-26 and is listed as Deprecated in the 2026-07-28 spec.

Status in the 2026-07-28 spec: deprecated

If you run or depend on an older remote MCP server, this page explains how the old transport worked, what the spec says about it today, and how to move off it. Every detail was checked against the official spec pages on 28 October 2026.

What HTTP+SSE was

The 2024-11-05 transports page defined it. "The server MUST provide two endpoints":

1. "An SSE endpoint, for clients to establish a connection and receive messages from the server."
2. "A regular HTTP POST endpoint for clients to send messages to the server."

The flow went like this. The client opened the SSE connection. The server's first event was an endpoint event "containing a URI for the client to use for sending messages." From then on, the client POSTed every message to that URI, and the server sent all replies as SSE message events on the open connection.

A first event on the SSE stream looked roughly like this. This sketch is ours, based on the 2024-11-05 description, and the sessionId query string is an illustrative implementation choice, not a spec requirement:

event: endpoint
data: /messages?sessionId=abc123

Each later server message arrived as a message event whose data was a JSON-RPC object:

{"jsonrpc": "2.0", "id": 1, "result": {"tools": []}}

Why it was replaced

In the 2024-11-05 design, replies to every request flowed over one long-lived stream, and the client had to work with two endpoints. A client could not get a plain JSON reply to a single POST.

The 2025-03-26 changelog lists the fix as a major change: it "Replaced the previous HTTP+SSE transport with a more flexible Streamable HTTP transport." Streamable HTTP uses one endpoint, and a server can reply to each POST with plain JSON or a stream scoped to that request.

What the 2026-07-28 spec says

The Streamable HTTP page carries a warning box. HTTP+SSE "has been deprecated since protocol version 2025-03-26 and is classified as Deprecated under the feature lifecycle policy." It continues: "New implementations SHOULD NOT adopt it; existing implementations SHOULD migrate to Streamable HTTP. It is eligible for removal in a future revision."

The deprecated features registry lists its earliest removal as "Three months after SEP-2596 reaches Final." The 2026-07-28 release post describes it as "officially deprecated, with a year-long offramp." The registry is the formal record, so plan on the registry's wording and watch for the SEP status. Our versioning and deprecation guide explains how the lifecycle works.

Supporting old and new clients at once

The 2026-07-28 spec still documents backward compatibility.

Servers that want to support older clients should "continue to host both the SSE and POST endpoints of the old transport, alongside the new 'MCP endpoint'." Combining the old POST endpoint with the new one is possible "but this may introduce unneeded complexity."

Clients that want to support older servers should:

1. Accept a server URL from the user.
2. POST a request to it with the standard Accept header.
3. If that works, treat it as a Streamable HTTP server.
4. If it fails with 400, 404 or 405, and the body is not a recognized modern JSON-RPC error, send a GET and expect an SSE stream whose first event is endpoint.
5. If the endpoint event arrives, use the old transport from then on.

Step 4's body check matters. Modern servers also return 400 and 404 with JSON-RPC errors, and those should not trigger a fallback.

How to migrate a server

A practical order of work:

1. Upgrade your SDK. The official SDKs implement Streamable HTTP. See the official MCP SDKs.
2. Add a single MCP endpoint that accepts POST, such as /mcp.
3. Return JSON or a request-scoped SSE stream per request, not a shared stream.
4. Pick a target version. If you go straight to 2026-07-28, skip sessions entirely and require the new headers. If you must stay on 2025-11-25 for now, follow that revision's session rules.
5. Keep the old endpoints during a transition window, then remove them once your client logs show no old traffic.
6. Re-check security. Validate Origin, bind local servers to 127.0.0.1, and add authorization for remote use.

The details of the new transport are in MCP Streamable HTTP transport.

Common mistakes

• Building something new on HTTP+SSE because an old tutorial used it. The spec says not to.
• Falling back on any 400 or 404. Check the response body first.
• Removing the old endpoints with no warning. Some clients may still depend on them.
• Assuming the security rules changed. The 2024-11-05 page already required Origin validation.

Next step

Once you are on Streamable HTTP, the next job is usually sign-in. Read MCP authorization: what the spec requires, or ask our MCP development team to plan the migration.

Frequently asked questions