Daniel's been deep in the weeds building an MCP aggregation gateway, and he sent us a question that is exactly the right one to be asking right now. I'm going to read it because the framing matters.
"Do a technical episode on MCP transport architecture as it actually stands in 2026, aimed at someone running an aggregation gateway and deciding what to plug into it. Start with the transport landscape and be precise about it, because this is the source of most of the confusion. MCP began life as stdio — the client spawns the server as a child process and talks JSON-RPC over stdin/stdout. Then came HTTP+SSE, the two-endpoint design with a GET stream and a separate POST channel, which is now the deprecated legacy path. Then streamable HTTP, the single-endpoint successor where a POST can either return a plain JSON response or upgrade to an SSE stream, with session identity carried in a header and resumability via event IDs. Explain what each transport actually is on the wire, why the SSE design was replaced, and why in practice you still meet all three in the field."
"Then the real question: if you are running one gateway that fronts many servers, what should it speak in each direction? Make the case for the asymmetry — the gateway should present a single modern streamable HTTP endpoint northbound to clients, while southbound it speaks whatever each individual server offers."
He wants us to walk through local stdio servers where the gateway becomes a process supervisor, vendor remote servers where it becomes an OAuth client, and legacy SSE holdouts that need bridging. Then cover the cross-cutting problems that only appear once you aggregate — tool name collisions, context-window pressure from merged manifests, propagating list-changed notifications, health checking that distinguishes a dead process from a five-oh-three, timeouts, session affinity across replicas. And close on what the minimum viable plumbing on a local box actually is.
That's the question we're going to answer — not as a general explainer about what MCP is, but as a decision framework for someone who has to build or buy this thing today. And the reason this matters right now is that the spec has settled. The transport chapter was rewritten, the old path is explicitly deprecated, and yet if you actually go to wire up a gateway against real servers in the field, you hit all three transports immediately. The spec tells you what's correct. The field tells you what exists. The gap between them is where the gateway lives.
So the episode is really about that gap. What each transport is on the wire, why the old one was replaced, and then — and this is where Daniel's question gets interesting — what a gateway actually has to do when it can't choose one transport and be done.
Right. The core thesis is asymmetry. Northbound to clients, you present a single modern streamable HTTP endpoint. Southbound to servers, you speak whatever each server offers. This is not a compromise or a temporary migration hack. It's the correct architectural response to a heterogeneous ecosystem, and it will be correct for years because stdio is never going away for local tooling, and vendors migrate on their own timelines.
We'll start with what each transport actually looks like on the wire, because most of the confusion lives there. Then walk through the three server types a gateway has to handle, then the cross-cutting problems that only appear at aggregation scale, then what minimum viable plumbing looks like. Let's go.
Transport one — stdio. This is the original, and it has never been deprecated. The client spawns the server as a child process and they talk JSON-RPC over standard in and standard out. On the wire it's newline-delimited JSON messages, one JSON object per line, bidirectional. No HTTP, no headers, no connection management. The transport is literally the process boundary. If the process dies, the transport dies. If the process hangs, the transport hangs.
So the "endpoint" is a shell command.
The endpoint is npx at modelcontextprotocol slash server hyphen filesystem, or uvx run something. The client is responsible for spawning that process, setting its environment variables, setting its working directory, and then reading and writing lines of JSON to its standard I/O. There's no URL to POST to, no port to connect to. The process is the server.
And one process serves exactly one client.
That's the single-session constraint. A stdio server is one process, one stdin pipe, one stdout pipe, one client. If three clients need the same server, you have three choices. One: spawn three processes and pay for three. Two: have the gateway spawn one process and multiplex all three client sessions through it, which requires the gateway to namespace the JSON-RPC request IDs so they don't collide. Three: don't support multiple clients.
Multiplexing through one process — how awkward is that in practice?
It's... fine, mostly. The JSON-RPC spec uses request IDs to match responses to requests, and those IDs are scoped per session. If the gateway runs one process and proxies three sessions through it, it has to ensure that session A's request ID seven and session B's request ID seven don't get confused. The gateway wraps each request with a session-scoped ID before forwarding it to the server, then unwraps on the way back. It's not hard, but it's a thing you have to build, and it's a thing that a simple reverse proxy doesn't do because a reverse proxy doesn't know what a JSON-RPC request ID is.
Transport two — the one that got replaced.
HTTP plus SSE. This was the first HTTP transport added to the spec, and it's now explicitly deprecated as of the December twenty twenty-five blog post and the July twenty twenty-six spec revision. The design uses two endpoints. First, the client does a GET to slash SSE. The server responds with a server-sent events stream — that's a long-lived HTTP response where the body is a sequence of SSE event fields. This stream carries all messages from server to client. Second, the client does POST requests to slash messages, carrying JSON-RPC in the body, for all messages from client to server.
So the client opens a GET and holds it open. Then every time the client wants to send something, it does a separate POST. And every time the server wants to send something, it writes to the SSE stream.
That's the design. And the problems start immediately. How does the server know which SSE stream a given POST belongs to? There's no standard mechanism. Some implementations put a session ID in the SSE stream's first event and expect the client to include it in subsequent POSTs, but that's implementation-specific, not spec-mandated. The two-endpoint model means the client maintains two connections per session, which complicates load balancing — the GET and the POSTs might land on different replicas. And if the SSE stream drops, there's no standard resumability mechanism. The client just... reconnects and hopes it didn't miss anything.
I can see why this died.
It's architecturally fragile in exactly the way that makes operations teams hate you. The December twenty twenty-five blog post from the MCP team made the case clearly: session management was implicit and brittle, the two-endpoint design created affinity problems, and there was no standard way to resume after disconnection. Streamable HTTP fixes all three.
Which brings us to transport three.
Streamable HTTP. Single endpoint. The client sends a POST and the server can respond in one of two ways. For simple requests — ping, list tools, anything that completes immediately — the server returns a plain JSON response with content type application json. For requests that may produce streaming responses or server-initiated notifications, the server returns a response with content type text event stream, upgrading the POST response into an SSE stream.
Wait — the POST itself becomes the SSE stream? Not a separate GET?
That's the key design difference. There's one connection. The client POSTs, and the server decides whether to return JSON or an SSE stream in the response body. Session identity is carried in a header — Mcp hyphen Session hyphen Id. Every request from the client includes that header, and the server uses it to associate the request with the right session. No URL-based session tokens, no implicit affinity.
And the resumability piece?
The Last hyphen Event hyphen ID header. When the server sends events over the SSE stream, each event has an ID. If the connection drops, the client reconnects with a new POST, includes the Last hyphen Event hyphen ID header set to the last event ID it received, and the server replays any events it missed. This is standard SSE semantics applied to MCP, but the old HTTP plus SSE design didn't specify it. Streamable HTTP does.
So the spec history here is: stdio from the beginning, HTTP plus SSE added later, then streamable HTTP announced as the recommended transport in December twenty twenty-five and codified as the primary transport in the July twenty twenty-six spec revision, with HTTP plus SSE marked as legacy.
And yet in July twenty twenty-six, you still meet all three in the field. Stdio persists because local development tools are naturally child processes — there's no HTTP server to run. You type npx and you're done. That convenience is hard to beat. HTTP plus SSE persists because vendors built servers before the deprecation and haven't migrated — and honestly, some of them may never migrate if the server works and they have paying customers on it. Streamable HTTP is the default for new implementations, but the installed base is mixed and will stay mixed.
Which is exactly Daniel's situation. A gateway that only speaks one transport is broken by design. You don't get to choose what your servers speak southbound. You do get to choose what you present northbound. And the correct northbound choice is streamable HTTP — single endpoint, explicit session identity, resumability.
That's what each transport looks like on the wire. Now let's talk about what happens when you have to speak all three at once, starting with the hardest case: local stdio servers.
The gateway becomes a process supervisor. Not a proxy — a supervisor. It's spawning child processes, monitoring them, capturing their output, and deciding when to restart them.
First concrete problem: environment variables and working directory. A stdio server like the filesystem server needs to know which directories it's allowed to access. That's typically passed as a command-line argument or an environment variable. The gateway has to set these per server, not per request. When you configure the gateway, you specify for server A: working directory slash home slash daniel slash projects, environment variable ALLOWED underscore DIRS equals slash home slash daniel. Those are set at spawn time and they persist for the life of the process.
And if you get them wrong, the server starts and immediately fails, or worse, starts but silently operates on the wrong directory.
Which brings us to stderr capture. If the server crashes, standard error is the only diagnostic you have. The gateway must capture stderr and surface it as a structured error. If the gateway doesn't capture stderr, the server fails and the client gets... a hang. Or a generic "internal error" with no detail. The difference between a debuggable failure and a mystery is whether the gateway captured stderr and included it in the error response.
Cold start cost. First tool call after a period of inactivity.
This one bites people who are used to HTTP servers that are always running. A stdio server isn't running until the gateway spawns it. If the gateway spawns on demand — first tool call triggers process start — that first call pays the startup cost. For a Node server, that might be half a second. For a Python server with heavy imports, it could be two or three seconds. The gateway either needs to pre-spawn servers at startup and keep them warm, or it needs to communicate to the client that the first call will be slow. Most gateways pre-spawn.
Restart policy. The process dies. Now what?
The gateway needs a restart policy with exponential backoff and a max retry count. If the server crashes on every startup because of a bad config, you don't want the gateway retrying forever. Standard approach: three attempts with exponential backoff, then circuit-breaker open. The gateway returns an error to any client requesting that server until an operator intervenes. And the circuit breaker state needs to be visible — the gateway's health endpoint should report which servers are in circuit-breaker state.
And the single-session problem you mentioned earlier. Three clients, one process.
The right answer is multiplexing. Run one process and proxy multiple sessions through it. The gateway wraps each outgoing JSON-RPC request with a session-scoped ID, then unwraps the response to route it back to the correct client. The alternative — one process per client — means if you have twenty clients all using the filesystem server, you have twenty Node processes. That's wasteful and it doesn't scale. Multiplexing is more work to implement but it's the correct architecture.
The thing I keep coming back to is that none of this is what a reverse proxy does. Nginx doesn't spawn child processes or namespace JSON-RPC request IDs.
That's the misconception that trips people up. An MCP gateway is not a reverse proxy. For stdio servers, it's a process supervisor with an application-level multiplexing layer. If you try to treat it like an HTTP proxy, you'll build something that doesn't handle half the failure modes.
So the gateway is a process supervisor for stdio servers. But what about servers that aren't on your machine at all?
That's where OAuth comes in — and where credential custody becomes the defining architectural decision. When you connect to a vendor-hosted MCP server, the gateway becomes an OAuth client. This is not optional. The spec defines dynamic client registration, and if you're connecting to any vendor that follows the spec, you have to implement it.
Walk me through the flow.
Dynamic client registration means the gateway doesn't have pre-issued client credentials. Instead, it calls the vendor's registration endpoint — defined in the server's metadata — and registers itself as a client. The vendor returns a client ID and client secret. The gateway stores those. Then, when a client wants to use that server, the gateway initiates the OAuth authorization code flow: redirect to the vendor's authorization endpoint, get an authorization code, exchange it for an access token and refresh token.
And the resource indicator piece?
This is critical and easy to miss. A token minted for server A must not be replayable at server B. The standard mechanism is the resource indicator parameter from RFC eight seven zero seven. When the gateway requests a token, it includes a resource parameter that identifies the specific server the token is for. The authorization server binds the token to that resource. If someone tries to use that token at a different server, it's rejected.
Without resource indicators, a compromised token from one server is a skeleton key.
And in an aggregation gateway, the gateway holds tokens for potentially dozens of servers. If those tokens aren't resource-bound, the blast radius of a leak is every server the gateway connects to.
Token storage and refresh — where do they live?
On disk or in a secrets manager. The gateway stores access tokens and refresh tokens, refreshes them before expiry, and handles revocation if a token is compromised. This is standard OAuth client behavior, but the scale is different. A typical OAuth client manages tokens for one or two services. An MCP gateway manages tokens for every vendor server in the fleet. That's ten, twenty, fifty sets of credentials.
And this is the architectural consequence Daniel flagged. Credential custody moves into the gateway.
It's the single biggest change when you add remote servers. Before remote servers, the gateway held no secrets. It spawned processes and proxied JSON-RPC. After remote servers, the gateway holds OAuth client credentials and access tokens for every vendor. It becomes a high-value target. The security model shifts from "protect the host" to "protect the gateway's credential store." That means encrypted storage, audit logging of token access, and a rotation story.
And the simpler vendors who don't do OAuth?
Bearer tokens or custom headers. Some vendors just give you an API key and say "put it in the Authorization header." The gateway has to support both — full OAuth with dynamic client registration for spec-compliant vendors, and ad-hoc auth schemes for everyone else. The credential store needs to handle both, and the gateway's configuration needs to express which auth scheme each server uses.
We've covered local and remote. The third category is the most annoying: legacy SSE servers that haven't migrated.
This is the bridging problem. You have a server that only speaks HTTP plus SSE — the deprecated two-endpoint design. Your gateway presents streamable HTTP northbound. The gateway has to translate between them.
How does that translation actually work?
The gateway maintains a persistent SSE connection to the legacy server. It does a GET to slash SSE and holds the connection open. When the legacy server sends an SSE event, the gateway translates it into a streamable HTTP SSE event and forwards it to the client. When the client sends a POST to the gateway, the gateway translates it into a POST to the legacy server's slash messages endpoint.
And the session mapping?
That's the hard part. The legacy server's session is implicit — it's whatever SSE stream the GET opened. The modern client's session is explicit — it's the Mcp hyphen Session hyphen Id header. The gateway has to maintain a mapping: session ID X on the northbound side corresponds to SSE stream Y on the southbound side. If the SSE stream drops, the gateway has to reconnect and re-establish the mapping. If the client reconnects with a Last hyphen Event hyphen ID, the gateway has to replay events — but the legacy server might not support event replay, in which case the gateway has to buffer events itself.
So the gateway becomes a stateful bridge that buffers events and maintains session mappings. That's not a thin translation layer.
It's a full protocol bridge. And it's stateful, which means if you're running multiple gateway replicas, the bridge state has to be shared or the session has to be pinned to one replica. More on that when we get to cross-cutting problems.
Those are the per-server challenges. But once you aggregate multiple servers, new problems emerge that don't exist with any single server. The first one is so obvious it's almost embarrassing, but it bites everyone: tool name collisions.
You connect two servers, both export a tool called search. Or read file. Or list. What does the client see? If the gateway just merges the tool lists, the client sees two tools with the same name and no way to distinguish them.
The fix is namespacing.
The gateway prefixes each tool name with the server name or a configured alias. Server A's search becomes A slash search. Server B's search becomes B slash search. The client sees distinct tool names and can call the right one. The gateway strips the prefix before forwarding the call to the downstream server. This seems trivial — and it is, implementation-wise — but it has to be designed in from the start. If you bolt namespacing on after the fact, you break every client that was using the un-namespaced names.
Context-window cost. Twenty servers, fifty tools each.
A thousand tools in the merged manifest. Every time the client sends a prompt, the tool definitions are included in the system message or the tool use block. A thousand tool definitions, each with a name, description, and JSON schema for parameters — that's tens of thousands of tokens before the user has said a word. On a model with a two hundred thousand token context window, maybe that's fine. On a model with a thirty-two thousand token window, you've burned half the context on tool definitions.
Selective enabling.
The client only includes the tools it actually needs. The gateway's manifest lists all available tools, but the client opts in to a subset. The prompt only includes definitions for the opted-in tools. This requires the gateway to support per-client or per-request tool filtering.
And deferred schemas?
A more aggressive optimization. The initial tool list only includes tool names and descriptions — not the full JSON schema for parameters. When the client actually wants to call a tool, it calls tools slash get to retrieve the full schema. This keeps the initial manifest small and defers the schema cost to call time. The trade-off is an extra round trip before the first call to each tool.
Propagating list-changed notifications. A downstream server adds a tool. How does the client find out?
The MCP spec defines a notification — notifications slash tools slash list hyphen changed — that a server sends when its tool list changes. The gateway has to subscribe to this notification from every downstream server. When it receives one, it refreshes that server's tool list and emits its own list-changed notification to all connected clients. If the gateway doesn't propagate these, clients cache stale tool lists and calls fail mysteriously.
Health checking. You mentioned this earlier — a dead child process versus an HTTP five-oh-three.
The gateway needs two layers of health checking. Process-level: is the PID alive? For stdio servers, the gateway spawned the process, so it can check whether the process is still running. Protocol-level: even if the process is alive, can it respond to a ping? The gateway sends a JSON-RPC ping and expects a response within a timeout. A process can be alive but hung — the PID exists but the event loop is blocked. Only the protocol-level check catches that.
And for remote servers, the process-level check doesn't exist.
Right — you can't check the PID of a vendor's server. You only have the protocol-level check: send a ping, wait for a response. If it fails, you can't restart it. You can only report the health status and wait.
Timeouts.
A stdio server can hang on a tool call. The gateway needs a per-request timeout. If the server doesn't respond within, say, thirty seconds, the gateway returns a timeout error to the client. But it also needs a way to recover — if the process is hung, killing the request doesn't help. The gateway needs to be able to kill the hung process and restart it. That's process supervision again, but triggered by a request timeout rather than a crash.
Session affinity across replicas. You run two gateway instances behind a load balancer.
A client's session with the gateway is stateful. The session includes the Mcp hyphen Session hyphen Id, the set of downstream connections (which stdio processes are spawned, which SSE bridges are active, which OAuth tokens are in use), and in the case of SSE bridging, buffered events. If the client's next request lands on a different gateway replica, that replica doesn't have any of that state.
Two solutions.
Session affinity or shared state. Session affinity means the load balancer hashes on the Mcp hyphen Session hyphen Id header and routes all requests for a given session to the same replica. This is simple and works until the replica dies — then the session is lost and the client has to reconnect. Shared state means sessions are stored in Redis or equivalent, and any replica can handle any request. This is more resilient but more complex to implement. Streamable HTTP makes session affinity easier because the session ID is an explicit header — the load balancer doesn't have to parse URLs or cookies.
The asymmetry thesis in one sentence: northbound, streamable HTTP gives you session identity in a header and a single endpoint. Southbound, you speak whatever the server speaks. The gateway is the adapter.
And the adapter has to do all of this — process supervision, OAuth credential custody, transport bridging, namespacing, health checking, timeout management, session affinity. None of these are individually hard in the way that, say, distributed consensus is hard. But there are eight of them, and they interact, and getting them all right is a lot of code.
So what's the minimum viable plumbing on a local box?
Five components. One: a process supervisor that handles spawning, environment variables, working directory, stderr capture, restart policy with exponential backoff and circuit breaker, and multiplexing for stdio servers. Two: a credential store that manages OAuth client registration, token storage and refresh, resource indicators, and ad-hoc auth schemes for non-OAuth vendors. Three: a bidirectional transport bridge that translates between streamable HTTP northbound and whatever transport each server speaks southbound — stdio, HTTP plus SSE, or streamable HTTP. Four: a registry that maps server names to transport configurations, auth configurations, and tool name prefixes. Five: a namespacing layer that prefixes tool names, supports selective enabling, and optionally supports deferred schemas.
And what do you get for free by choosing a gateway that already has all five?
You don't have to build process supervision from scratch — which means you don't discover six months in that your restart policy doesn't handle the case where the process starts but then immediately crashes, or that you forgot to capture stderr and all your production errors are "internal error." You don't have to implement OAuth client registration for every vendor, each of which has slightly different metadata formats. You don't have to write a transport bridge for legacy SSE and discover that session mapping is the hard part. You don't have to retrofit namespacing after clients are already using un-prefixed tool names. And you don't have to figure out session affinity across replicas after your first production outage.
The alternative — assembling these five yourself — is feasible. Each component is well-understood. But each one has edge cases that take months to discover, and in aggregate they're a year of engineering work.
The decision framework for Daniel, or anyone in his position, is: how many of these components do you actually need? If you only have local stdio servers, you need the process supervisor and the registry — that's it. No OAuth, no transport bridging. If you have any remote servers, you add the credential store and the transport bridge. If you have more than, say, five servers, you need the namespacing layer because tool name collisions become probable. If you have more than one gateway replica, you need session affinity or shared session state.
The transport decision is made for you southbound. You speak whatever your servers speak. Northbound, you choose streamable HTTP because it's the only transport that gives you session identity in a header, resumability via event IDs, and a single endpoint. The asymmetry is not a bug.
It's the architecture. And I think the spec authors understood this. The December twenty twenty-five blog post didn't just announce a new transport — it laid out a migration path that implicitly assumes gateways will bridge the old and the new. The July twenty twenty-six spec revision codified streamable HTTP as primary, but kept the HTTP plus SSE section as a documented legacy appendix. They know the field is heterogeneous. The gateway is the answer to that heterogeneity.
Here's the open question I keep turning over. As the ecosystem matures, does stdio eventually disappear in favor of local HTTP servers? The spec is moving in that direction — streamable HTTP works fine for local servers, you just run them on localhost with a port. But the convenience of npx without running an HTTP server is genuinely hard to beat. No port conflicts, no process already running, no "is the server up?" check. You type the command and it works.
I think stdio persists for exactly that reason. The spec has never deprecated it, and I don't think it will. What might happen is that local server authors start shipping both — a stdio entry point for development and a streamable HTTP entry point for production. The gateway can then choose which transport to use based on context. But stdio as a concept — spawn a process and talk JSON-RPC over its standard I/O — that's not going anywhere.
The other trajectory I see: as more vendors adopt streamable HTTP, the transport bridging problem shrinks. But the credential custody and namespacing problems grow. The gateway's job shifts from protocol adapter to policy enforcement point.
In a world where every server speaks streamable HTTP, the gateway still has to manage OAuth tokens for every vendor, still has to namespace tool names, still has to handle health checking and timeouts and session affinity. The transport layer becomes simpler. The policy layer becomes the entire job.
If you found this useful, leave a review — it helps other gateway operators find the episode. And if you're building one of these five components yourself, we'd love to hear about it.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. We'll be back soon.
