Streaming HTTP and SSE Transports

What a transport actually covers

In MCP vocabulary, transport refers to how your application and the tool server physically exchange messages. It’s not a trivial implementation detail: it determines whether the connection stays open between calls, how results reach you, and what happens when a proxy decides to cut the connection. xAI supports two for remote MCP: Streaming HTTP and SSE (Server-Sent Events), both over HTTPS.

Streaming HTTP, the modern transport

Streaming HTTP is the newer of the two in the MCP standard. It relies on perfectly ordinary HTTP requests, with one nuance: the server can return its response as a continuous stream instead of waiting to calculate everything before emitting a single block. A call unfolds in four steps.

1. Grok sends a POST request to the MCP server with the tool parameters to call
2. The server starts processing the request
3. The response arrives progressively, piece by piece
4. The connection closes once the response is complete

This mechanism makes sense for slow or verbose tools. Take a search tool scanning a document corpus: rather than making the model wait until the last result, it emits its findings as they come. On the infrastructure side, Streaming HTTP behaves like classic web traffic, which explains why it passes through enterprise load balancers and proxies easily. Since each tool call is an independent request, there is no persistent connection to monitor.

Server-Sent Events, the open connection approach

SSE is the veteran of the MCP ecosystem. It relies on a persistent, unidirectional connection: the client opens it to the server, the server keeps it open and pushes events to it when it has them. In the MCP context, the tool call goes to a separate endpoint, and the result comes back via the already established SSE channel.

This operation has one real advantage and one symmetrical drawback. The advantage: since the connection is already there, successive calls don’t have to pay the establishment cost again, and the server can emit notifications without the client requesting them. The drawback: a long-lived connection is a fragile connection. A proxy applying a timeout, a two-second network cut, and the channel drops. A serious SSE implementation must therefore plan its reconnection logic.

You don’t choose, you inherit

Here’s the point that often surprises: you don’t select the transport. The MCP server imposes the one it implements. When you configure a server in the xAI API, you only provide its URL, and the API detects the current transport on its own. There is no parameter to force one over the other.

In practice, most recent public MCP servers have adopted Streaming HTTP; older ones remain on SSE. Both work transparently with the Grok API, and you generally won’t have any way to know which is used without looking at the server documentation.

What xAI doesn’t support

Three transports seen elsewhere in the MCP ecosystem are out of play here, and ignoring this list is the most frequent cause of a failed first attempt. The stdio transport, used by local MCP servers like those plugged into Claude Desktop, is not accepted: a server running on your machine and communicating via standard input/output cannot be connected to Grok. Plain HTTP is refused without exception, everything must pass over HTTPS. WebSocket, which some MCP implementations use, is also not recognized as an MCP transport by the xAI API.

Consequences for your architecture

The transport imposed by the server impacts your application’s robustness. With Streaming HTTP, since each call is stateless, restarting your service leaves nothing broken behind: the next request starts from zero and everything works. With SSE, the persistent connection can break mid-route, and you must decide what happens to a call that started but whose result never returned—retry it, abandon it, report an error to the user.

Rest assured though: in both cases, the xAI API handles the connection to the MCP server, not you. You implement neither the protocol nor the reconnection yourself. It suffices to provide the server URL, and these considerations only affect how you interpret an error or size your application timeouts.

Key takeaways

• xAI supports two MCP transports: Streaming HTTP and SSE, both over HTTPS
• Streaming HTTP is the modern transport, stateless and compatible with standard web infrastructure
• SSE maintains a persistent connection, useful for frequent calls but more fragile
• The transport is determined by the MCP server, not by your configuration
• stdio, plain HTTP, and WebSocket are not supported for remote MCP