Simplify HTTP transport with Websockets and stateless request/response options #493

Is your feature request related to a problem? Please describe.

The current HTTP transport mechanisms for MCP (both HTTP+SSE and Streamable HTTP) introduce unnecessary complexity, state management challenges, and security concerns. As someone implementing an MCP server, I've encountered several issues:

1. Excessive Complexity: The current approach requires maintaining session state across multiple connections and offers too many ways to achieve the same outcomes (multiple session creation methods, SSE opening options, and response delivery methods).

2. Security and Scalability Concerns: Managing state across HTTP and SSE connections creates potential vulnerabilities and scalability challenges, particularly in enviorments with more then one node.

3. Poor Developer Experience: The current transport mechanisms don't follow established web standards, have a lot of corner cases and is making implementation unnecessarily difficult.

4. Implementation Burden: The server must maintain complex state management to "join" connections across calls, which significantly complicates any redundant/distributed deployment scenarios. Eg. The answer to a rpc POST coming in to one server in Europe might have to be returned through a SSE established to a server in the US.

5. Distributed System Challenges: The current approach forces implementations to maintain cross-server state for sessions. In a distributed environment (load balancers, multiple regions, autoscaling), this requires implementing complex shared session state management that could be entirely avoided with Websockets, where the state remains local to a single connection.

Describe the solution you'd like

I propose replacing the current HTTP+SSE and Streamable HTTP transports with two simpler, well-established alternatives:

1. Websockets for full-duplex communication, GET /mcp:

   • Websockets provide a true socket-like experience similar to stdio but over HTTP
   • They eliminate the need for complex session state management across multiple connections
   • They're widely supported by all modern browsers, servers, and client libraries
   • They follow established web standards and patterns

2. Simple HTTP request/response for stateless operations, POST /mcp:

   • A straightforward REST-style API for single request/response interactions
   • No session state to maintain
   • Perfect for simple tool invocations or short interactions
   • Follows standard HTTP patterns that developers already understand
   • Some concessions probably have to be made in terms of the initial handshake of the MCP protocol
     • On top of my head...
     • POST /mcp/capabilities might return the standard initialize response
     • POST /mcp can contain initialize request and the rpc call

This approach would:

• Dramatically simplify the protocol
• Reduce implementation complexity
• Improve security by reducing the attack surface
• Make the protocol more accessible to developers
• Better align with the stdio transport model (Websockets are conceptually similar to stdio streams)

Describe alternatives you've considered

1. Refining the current Streamable HTTP approach: While Streamable HTTP could potentially be simplified and better documented, its fundamental design still introduces unnecessary complexity compared to Websockets, is a mismatch conceptually to stdio and will still forces state management over multiple sockets/threads/server/regions.

2. gRPC: While powerful for service-to-service communication, gRPC is overkill for this use case, doesn't really play nice in the browser and isn't as universally supported in browsers as Websockets.

Additional context

The current approach seems to be attempting to reinvent Websockets using a combination of SSE and HTTP requests, creating what is essentially a more complex, less standard, and less secure version of Websockets.

Addressing objections to Websockets (from PR #206)

I've reviewed the objections to Websockets stated in PR #206 and would like to address them, and the issue comment #206 (comment):

1. "RPC-like use would incur unnecessary overhead": This is incorrect. Websockets actually reduce overhead for RPC-like interactions by eliminating the need to establish new connections and perform TLS handshakes for each call. For stateless operations, a simple HTTP endpoint can be provided alongside Websockets, giving developers the best of both worlds if this turns out to be a real problem.

2. "Cannot attach headers like Authorization in browser Websockets": While true that headers can't be added after connection establishment, there are standard, well-established patterns for this:

   • Authorization tokens can be passed during the initial connection as header, cookies or via query parameters
   • Post-connection authentication can occur in the first or subsequent message
     • Authorization can be part of the MCP protocol or a subprotocol. Eg. sending key-value pairs over the socket

3. "Only GET requests can be upgraded to Websocket": This is true as well but really does not matter. The Websocket standard specifies the use of GET, and this is not a limitation but simply how the protocol works. Every Websocket library handles this transparently. To do a GET and open a socket to then send down a rpc message over the socker doesn't introduce additional complexity or realy latency compared to the current approach in any mening full way.

4. Regarding compatibility concerns: Supporting both Websockets and a simple stateless HTTP API would simplify the compatibility matrix compared to the current complex state management across multiple HTTP connections and SSE streams.

State management advantages of Websockets

The current approach requires maintaining complex session state across multiple connections, which becomes particularly problematic in distributed environments:

• In a load-balanced environment, SSE connections and HTTP requests may be routed to different servers, requiring shared state.
• Session resurrection/resumption requires complex distributed state management and introduces a DoS risk since the cliend does not need to stick around.
• With Websockets, the entire session state remains local to a single connection, dramatically simplifying implementation.
• For redundancy, standard Websocket failover patterns are possible as well.

Websockets provide exactly the bidirectional message exchange in a standardized, widely-supported way that closely mimics the preferred stdio transport. As the specification itself notes:

"Clients and servers MAY implement additional custom transport mechanisms to suit their specific needs. The protocol is transport-agnostic and can be implemented over any communication channel that supports bidirectional message exchange."

But it does not seem that the standard way of doing things should be this complex