Can one server support both transports?

Yes, and many do. The MCP SDKs let you mount the same server logic behind a stdio entry point and an HTTP endpoint. It is a common pattern for a server that developers run locally while the hosted version serves the team.

Do I still need to support HTTP+SSE for older clients?

Only if you have measured clients that require it. It has been deprecated since March 2025, so keep it as a compatibility surface if your telemetry justifies it and drop it otherwise. New implementations should use Streamable HTTP.

How do I keep state across calls now that sessions are gone?

Mint an explicit handle on the server, return it from the tool that creates it, and require it as an argument on the tools that need it. Treat it exactly as you would a database identifier, including checking that the caller is entitled to it.

Does the Origin check matter for a server behind a VPN?

Yes. DNS rebinding runs from the user's browser, which is already inside your network boundary. A VPN does not remove the need to validate Origin.

MCP Transport: stdio vs Streamable HTTP

Pick stdio when one person runs the server on their own machine, and Streamable HTTP when a team has to reach it over a network. That single question, local process or shared endpoint, settles the transport choice more reliably than any feature comparison.

The complication is that Streamable HTTP has changed substantially. The transport shipped in March 2025 is not the one described in the current specification, and a tutorial written against the older revision will produce code that the 2026 spec explicitly tells servers to ignore.

In this guide, we cover how stdio and Streamable HTTP actually work, what happened to SSE, and what the 2026 revision removed. We also cover the security obligations a remote endpoint takes on, and what this looks like on a WhatsApp MCP server.

How Each Transport Actually Works

Aspect	stdio	Streamable HTTP (2026-07-28)
Process model	The client launches the server as a subprocess	The server runs independently and serves many clients
Message channel	One bidirectional stream, JSON-RPC newline-delimited on stdin and stdout, logs on stderr	One MCP endpoint accepting HTTP POST, one POST per client request
Streaming	No per-request streams; everything shares one channel and correlates by JSON-RPC id	A request gets either a single JSON response or a request-scoped text/event-stream
Cancellation	Client sends notifications/cancellations with the request ID	Closing that request's SSE response stream is the cancellation signal
Metadata	Carried in the JSON-RPC body, no header layer	Body plus headers: POSTs require MCP-Protocol-Version and Mcp-Method
Network exposure	None	An HTTPS endpoint you are responsible for securing

The stdio specification is short because there is genuinely little to it. The client owns the process lifecycle, and the security boundary is defined by what the client is allowed to execute.

Is SSE Deprecated in MCP? Not Exactly

The confusion here is worth clearing up, because "SSE is deprecated" gets repeated as though server-sent events were removed from MCP entirely.

The standalone HTTP+SSE transport was deprecated in protocol version 2024-11-05 and as of 2025-03-26. Streamable HTTP replaced it in that same revision.

SSE as a mechanism is still very much in use: under Streamable HTTP, a server may answer a POST with a text/event-stream response, and subscriptions/listen provides a long-lived POST-response stream for clients that opt into change notifications.

So if you are building today, do not implement HTTP+SSE. Do expect to see SSE content types in your traffic, because that is how streaming responses are delivered.

The 2026 Revision Removed More Than People Expected

This is the part most likely to break an implementation copied from an older guide.

The 2026-07-28 revision removed protocol-level sessions along with the Mcp-Session-Id header, and removed the initialize and initialized handshake.
Each request now carries the protocol version and client capabilities in _meta.
A current-only server that receives an Mcp-Session-Id should ignore it, and should neither mint nor echo session identifiers.
List results no longer vary by connection.
The practical consequence: anything you were storing against a session now needs an explicit, server-minted handle passed as an ordinary tool argument.
If your design assumed the server could quietly remember which account the caller was working on, that assumption is gone.
Servers still running the 2025-11-25 revision keep the older behaviour, so check which revision your SDK targets before assuming either model.
Resumability went too. Earlier revisions let a server put an ID on SSE events so a client could reconnect with Last-Event-ID and have events replayed.
The current revision removed SSE resumability Last-Event-IDand event IDs altogether.
If a response stream breaks, that in-flight request is simply lost, and the client must reissue it with a new JSON-RPC request ID.
That last point deserves engineering attention rather than a shrug. If reissuing a request could send a message twice, charge a card twice, or create a duplicate record, you need idempotency keys on the operations that matter.
The transport will not protect you.

Security Requirements for a Remote Endpoint

stdio has no listener, no Origin header, and no network endpoint, so none of this applies to it. The moment you move to Streamable HTTP, the specification sets out obligations:

Validate the Origin header on every incoming connection: This is the defence against DNS-rebinding attacks, where a malicious page in the user's browser resolves a hostname to your local server and starts issuing requests. Return HTTP 403 when a present Origin is invalid.
Bind to 127.0.0.1, not 0.0.0.0, when the server is meant to be local: Binding to all interfaces on a laptop quietly publishes your MCP server to the coffee shop network.
Authenticate every connection: For a team deployment, put the endpoint behind your identity layer and serve it over TLS.
Keep streaming responses unbuffered: Reverse proxies love to buffer, which turns a streaming response into a long silence. Setting X-Accel-Buffering: no and sending keep-alive comments on quiet streams avoids it.

Choosing For a Team Deployment

Streamable HTTP is the right answer when several people or automated clients share one deployed server, when the server holds shared credentials or reaches internal systems, when you want central authentication, logging, and rate limiting, or when clients run on machines you do not control.

The costs are operational rather than protocol-level. You own an authenticated endpoint, you own the proxy configuration that keeps streaming intact, you isolate concurrent clients from each other, and you keep state in explicit handles or a real datastore rather than leaning on the protocol.

stdio is the right answer when each user can run their own process, when local filesystem or developer-tool access is the point, and when minimizing network surface matters more than sharing. Its limitation is structural: each user gets a separate subprocess with a separate state.

Making one stdio server serve a team means putting a wrapper or gateway in front of it, at which point you have taken on the networking, auth, and lifecycle work that Streamable HTTP already handles.

What This Looks Like on a WhatsApp MCP Server?

A WhatsApp server is almost always the remote case, and it is worth being concrete about why.

The server holds WhatsApp Business API credentials that no individual user should have a copy of. It acts on shared customer data, so every call needs to be attributable to a person. Multiple team members connect from different clients, and the tenant boundary between accounts has to hold regardless of who is connected.

That rules out stdio on its own. It also means the OAuth layer is not an optional decoration, because it is what turns "this endpoint is reachable" into "this endpoint knows who is calling." Wati's MCP server runs as a remote endpoint and authenticates each connection against the user's own account, so the server can tell callers apart instead of treating every request as the same shared key.

Connecting a client to a remote server is correspondingly a network and identity exercise, not a config-file edit.

The walkthrough in connecting Wati MCP to Claude shows the flow end-to-end, and the security considerations for WhatsApp MCP servers cover what an exposed endpoint needs beyond the transport itself.

Choose the Right MCP Transport for Your Use Case

For local, single-user MCP servers, stdio is the simplest choice. For shared, remote access, Streamable HTTP is the better fit, with authentication and security controls built into the deployment.

For WhatsApp use cases, Wati provides a remote MCP server that handles the connection and OAuth flow, so you can get started without building the infrastructure from scratch.

Want to see it in action? Book a Wati demo and explore how Wati’s MCP server connects AI clients to WhatsApp.