For a new remote MCP server, use Streamable HTTP. The current MCP specification (version 2026-07-28) lists two standard transports, stdio and Streamable HTTP. The older HTTP+SSE transport isn't one of them, and the spec says: "The HTTP+SSE transport from protocol version 2024-11-05 has been deprecated since protocol version `2025-03-26`… New implementations **SHOULD NOT** adopt it; existing implementations **SHOULD** migrate to Streamable HTTP" (Streamable HTTP, spec 2026-07-28). SSE itself hasn't gone away: Streamable HTTP can still stream a reply as SSE.
What each transport is
| HTTP+SSE (2024-11-05) | Streamable HTTP (current) | |
|---|---|---|
| Endpoints | Separate SSE stream plus a POST endpoint | One MCP endpoint |
| Replies | Pushed on the long-lived event stream | "Replies arrive as a JSON object or a request-scoped SSE stream" (spec 2026-07-28, Transports) |
| Status in spec 2026-07-28 | "Deprecated… eligible for removal in a future revision" | Listed as a standard transport |
| Introduced | Protocol version 2024-11-05 | "Introduced in protocol version 2025-03-26 as a replacement for the HTTP+SSE transport" (spec 2026-07-28) |
Every status line above is quoted from the MCP transports overview and the Streamable HTTP page for spec version 2026-07-28. If the spec moves on, check those pages again before you rely on this table.
Client support
The protocol spec doesn't tell you what a given client ships. Check Cursor's MCP docs and Claude's current help pages for the transports each one supports, and pin the client version you tested against.
Auth is the same either way
The transport carries the messages, and OAuth sits on top of HTTP. The `401` challenge, PRM discovery and token validation work the same way. See the OAuth pillar for the full flow.
Pitfalls
- Confusing "SSE" with "HTTP+SSE". Streamable HTTP still streams responses as SSE. Only the old two-endpoint transport is deprecated, per spec 2026-07-28.
- Running both transports without a reason. The spec's backward-compatibility section describes how servers "wanting to support older clients" can host the old SSE and POST endpoints next to the new MCP endpoint. Only do that if you have such clients.
- Different auth on each endpoint. If you serve both, keep token validation identical.
- Relying on blog summaries for status. Quote the spec version you checked.
How to check it
Connect with MCP Inspector, pick the transport explicitly, and compare what you see with your server logs. A single POST endpoint means Streamable HTTP. A long-lived GET event stream plus a separate POST URL means the legacy transport.
Where the kit fits
The MCP Starter Kit ($27) is built for teams shipping remote MCP servers with OAuth in front of Cursor and Claude Connect. Soft path: start at /free; Cheat Sheet for the skim checklist mindset; kit when you want the auth-ready layout.
Soft next step
Confirm your server exposes a single Streamable HTTP endpoint, then test it in Inspector with the same auth you use in production. Soft ladder: /free, then the MCP Starter Kit ($27). Related: Kit vs OSS MCP boilerplate.