How AI agents talk to their tools in 2026: SSE, Streamable HTTP, gRPC and WebTransport explained

A tool server that works on a laptop can run into trouble once it sits behind a load balancer. The people who maintain the Model Context Protocol (MCP), the standard that connects AI agents to tools, traced much of that pain to one design choice, a connection that stays open and pins each client to one server. They rebuilt the transport twice to remove it.

That story holds three surprises:

• Server-Sent Events, the technology many developers assume is dying, still streams answers in the three model APIs checked here.
• gRPC, the fast binary protocol many expect to take over, is only a custom option in MCP. In A2A, the agent-to-agent protocol, it is one of three equal choices.
• WebTransport has worked in every major browser since March 2026 and still accounts for about 0.002% of page loads.

This guide teaches the pieces in order, so you can judge what your own agents should use.

The vocabulary in one minute

• Streaming: sending an answer in pieces as it is produced, so a person sees text and an agent sees progress before the final result exists.
• Server-Sent Events (SSE): a web standard in which the server keeps an ordinary HTTP response open and pushes text events down it. Data flows one way, from server to client.
• WebSocket: a connection that starts as HTTP and then stays open, letting both sides send at any time.
• gRPC: a remote-call framework from Google that sends compact binary messages over HTTP/2 and can stream in both directions.
• WebTransport: a browser API for two-way communication over HTTP/3, which runs on QUIC and UDP.
• Stateless: a server keeps nothing between requests because each request carries what the server needs, so any instance can answer it.
• Sticky routing: a load balancer rule that sends a client back to the same server every time.

Where long-lived SSE sessions break in production

On a laptop, one client talks to one server and nothing goes wrong. In production a load balancer sits between them, and MCP's original design fought that setup. In its December 2025 roadmap, the MCP Transport Working Group named four problems:

• Load balancers and gateways had to parse full JSON-RPC bodies to route traffic.
• Stateful connections forced sticky routing, which pins a client to one server and blocks auto-scaling.
• Simple, short-lived tools still needed backend storage to track multi-turn interactions.
• There was no predictable rule for where a conversation's context starts and ends.

Vendors felt it. Keboola told customers its SSE endpoint would stop accepting connections on 1 April 2026, because SSE tied each client to one server replica and limited horizontal scaling. Streams also meet plumbing trouble on the way, since reverse proxies can buffer a response and hold events back.

How MCP rebuilt its transport

MCP kept Server-Sent Events and retired one transport design that used them, called HTTP+SSE. The current spec marks HTTP+SSE as deprecated since protocol version 2025-03-26 and eligible for removal in a future revision. Its replacement has changed twice since.

Each step removed something the SSE design had required: first the second endpoint, then the session, then the standing stream and resumability. Streamable HTTP can still answer a request with an SSE stream, which is why SSE shows up in the current spec.

The 2026-07-28 revision answers each problem in the spec itself:

• Every request is its own POST, so any server instance behind a load balancer can take it.
• Every POST carries MCP-Protocol-Version, Mcp-Method and, for tool calls, Mcp-Name headers, so a gateway can route and rate-limit without reading the body. Servers must reject a request whose headers disagree with its body.
• When a server needs input from the user or the client's model, it returns an input_required result and the client retries the call with the answers, instead of the server holding a request open on a stream.
• Change notifications flow over a stream the client opens on purpose with a subscriptions/listen request, and dropped streams are simply reopened.
• Servers should send X-Accel-Buffering: no on SSE responses so proxies such as nginx do not hold events back, and should send a periodic comment line as a keep-alive.

Statelessness leaves one duty with the server. TrueFoundry's write-up of the wire protocol notes that the spec tells servers to treat any state a client sends back as attacker-controlled.

Not every agent tool needs a network transport. Our sgrep story covers a command-line tool that agents call through the shell, with no MCP server involved.

How the big APIs stream today

Text streaming is SSE almost everywhere. Persistent sockets show up where an agent makes many tool calls in a row or handles live voice.

When a persistent socket pays off

An agent loop sends the model a request, runs a tool, sends the result back, and repeats. On plain HTTP, each turn re-sends context and pays connection overhead. OpenAI's WebSocket mode for the Responses API keeps one connection open, caches recent response state in memory on that connection, and lets each turn send only the new items plus a previous_response_id. OpenAI says runs with 20 or more tool calls have been up to roughly 40% faster end to end.

One connection can also run parallel conversations in named lanes, called stream_ids, and fork one conversation into another. The documented limits are 16 in-flight responses and 32 named streams per connection.

The trade-offs follow from keeping state on the connection:

• A connection lasts at most 60 minutes, so clients need reconnect logic.
• The cache lives in memory only, which is why the mode works with zero data retention and store=false.
• With store=false, a dropped connection or an evicted parent leaves nothing to continue from. The next call fails with previous_response_not_found, and the client must resend the full context.
• Background mode stays HTTP-only.

That is the opposite bet from MCP's. OpenAI trades statelessness for speed on one kind of workload, long tool loops, and MCP removed state from the protocol for tool servers that must scale behind load balancers. A persistent socket is a tool for a particular loop, with no claim to being the new default.

gRPC: strong between services you control

For service-to-service agent traffic, it is a strong option. For remote MCP servers in general, it is a custom option and has no official status.

Google Cloud makes the case for gRPC in a January 2026 post. It lists binary Protobuf messages that it says can be up to 10 times smaller than JSON, two-way streaming over one connection, built-in flow control, mutual TLS, per-method authorization, deadlines, OpenTelemetry tracing and typed schemas that reject malformed input. Spotify is quoted saying it runs experimental MCP over gRPC internally.

What MCP itself says is narrower. The Transport Working Group's roadmap says MCP will keep only two official transports, stdio for local servers and Streamable HTTP for remote ones, so every client and server can interoperate. Other transports are allowed as custom transports, and the group is working on making them easier to plug into the SDKs. Google Cloud says it will contribute a gRPC transport package for that mechanism. A community proposal to make gRPC an official transport, SEP-1352, carried a "without a sponsor" label when checked.

A2A, the agent-to-agent protocol, treats gRPC differently. Version 1.0 defines three interchangeable bindings: JSON-RPC over HTTP, gRPC and HTTP+JSON. Its Java SDK says all three are fully supported and considered equal.

Two cautions for developers. First, gRPC pays off most when you control both ends and already run gRPC services, which is the case Google's post addresses. Second, be skeptical of speed claims on small proofs of concept. One experimental library, RapidMCP, advertises about 17 times lower latency than Streamable HTTP, but only on local connections and as a self-described proof of concept.

WebTransport: in every browser, used by almost nobody

WebTransport is a browser API for low-latency, two-way communication over HTTP/3, which runs on QUIC and UDP. It can carry many streams and unreliable datagrams on one connection.

Its status in 2026 is new and thin:

• Browser support. The Web Platform Dashboard lists WebTransport as Baseline newly available since 24 March 2026, when Safari 26.4 shipped it. Chrome has had it since version 97 and Firefox since 114. Baseline widely available is expected on 24 September 2028.
• Usage. The same page puts it at about 0.002% of page loads, per Chrome Platform Status.
• Network limits. Browser WebTransport needs HTTP/3. Per the connect-bidi-web notes, on a network that blocks UDP the handshake in Chrome and Firefox simply fails, so a WebSocket fallback is still required. The same notes say it is not available on Cloudflare Workers.
• A moving spec. As of April 2026, the notes say Safari and the IETF were on draft-15 of the HTTP/3 binding while Chrome and Firefox still spoke draft-02. A compatibility tracker adds that the option to send request headers on connect is unimplemented in Safari, absent in Firefox and behind a flag in Chrome.

None of MCP, A2A, or the OpenAI, Anthropic and Gemini APIs documents a WebTransport option in the pages read. The likelier users are browser clients for live voice and video. WebRTC.ventures says browser-wide Media over QUIC is a 2026 to 2027 story. A server-side agent calling a tool has no need for a browser API at all.

What encryption does and does not decide

Every option above can be encrypted, so encryption does not pick a winner.

• SSE and Streamable HTTP are ordinary HTTPS. WebSocket runs as wss://.
• gRPC supports TLS with optional client certificates for mutual authentication, per gRPC's authentication guide. Encryption is something you configure on the channel, and the gRPC API also offers insecure credentials for local use.
• WebTransport needs a TLS certificate, and the connect-bidi-web notes say browsers hold those certificates to stricter rules than ordinary HTTPS.

What differs is what each layer asks you to secure. The MCP spec says servers must validate the Origin header to block DNS rebinding attacks, should bind to localhost when running locally, and should authenticate all connections. OpenAI's API docs list mutual TLS and Private Link as options, and WebSocket mode is compatible with zero data retention.

The better questions are who can call your tool endpoints, how clients prove who they are, and what retention terms apply once data arrives. TLS protects the hop between you and the provider, and the provider still reads your data in plain form to run the model.

Check your own stack

• Do I need the server to push anything, or only stream one answer? A chat answer needs no more than SSE.
• Is my MCP server still on the old two-endpoint design, with a separate stream path and message path? That is the deprecated HTTP+SSE transport, and the spec describes how to host it alongside the new endpoint while clients move.
• Do I rely on session IDs or sticky routing? The 2026-07-28 revision removes protocol sessions, and a server that supports only that revision should ignore an Mcp-Session-Id header.
• Do I depend on Last-Event-ID to resume a dropped stream? Streams are no longer resumable in that revision, and closing a stream cancels its request, so retries must be designed in.
• Does my proxy buffer streams? Without X-Accel-Buffering: no or keep-alive comments, events can arrive late, and idle timeouts can cut quiet streams.
• Is my agent loop long enough to justify a persistent socket? OpenAI's figure is for runs with 20 or more tool calls, and a socket brings a 60-minute cap and reconnect logic.
• Do I already run gRPC? If not, adopting it only for tool calls is a large change for an unproven gain.
• Who can call my tool server, and how do they prove who they are?

What to watch

• Support for the 2026-07-28 revision. SDKs, gateways and clients adopt revisions at different speeds. A Claude connector guide says Claude still accepts the old HTTP+SSE transport while documenting it as being deprecated.
• A removal date. The spec calls HTTP+SSE eligible for removal in a future revision and gives no date.
• Whether gRPC stays custom. The pluggable transport work and Google's package decide how easy that route becomes.
• WebTransport's spec. Baseline widely available is expected in September 2028, and the browsers' draft versions have not converged.
• Vendor figures. OpenAI's 40% speedup and Google's 10 times smaller messages are the vendors' own numbers, and no independent test of either was found.
• Docs change quickly. Everything here reflects documentation as read on 15 October 2026.