Transport Streamable HTTP

MCP's modern remote transport is called Streamable HTTP. It lets your server live behind one web URL that any client on the internet can reach.

Unlike older designs, Streamable HTTP uses a single endpoint, often something like /mcp. Both requests and replies flow through that one path.

To call a tool, the client sends a normal HTTP POST to the endpoint. The body is the same JSON-RPC message you already learned about. 📨

The server can reply in two shapes: a plain JSON response for quick calls, or an event stream when it wants to send results bit by bit.

The client's Accept header signals what it can handle. Listing both JSON and the event-stream type lets the server choose the best reply format.

The transport changed, but the language did not. Every message over HTTP is the same JSON-RPC request, response, or notification you met earlier.

With the Python SDK you flip one switch: run your server with the streamable-http transport instead of stdio. The tools stay exactly the same.

Because it is ordinary HTTP, it plays nicely with the whole web stack: load balancers, proxies, and TLS all work without anything special. 🌐

Streamable HTTP can run stateful, remembering a session, or stateless, treating each call fresh. You choose based on how your server holds context.

An earlier HTTP+SSE design used two separate paths and was clunkier. Streamable HTTP replaced it as the recommended way to serve MCP remotely.

This single-endpoint design is what makes a remote MCP server practical to deploy and easy for any client to connect to from anywhere.

How does a client send a tool call over Streamable HTTP?

Streamable HTTP serves MCP over one HTTP endpoint: clients POST JSON-RPC, and the server answers with JSON or a live event stream. Same logic, remote reach. 🚀