Which MCP transports are in active use in 2026, and when do you pick each?

MCQ·Easy·4.0 · 0·~1 min·Asked atAi4bharat Razorpay Writer·Relevant atAnthropic

Attempt it

**An MCP transport** is the wire layer that carries JSON-RPC 2.0 messages between an MCP client and an MCP server. The protocol defines the message shapes; the transport defines how the bytes actually travel. Two transports are in active use in 2026. **Stdio** is the default for local servers. The host launches the server as a child process and they exchange newline-delimited JSON over standard input and standard output. Standard error is reserved for log output. Stdio is zero-configuration: the user adds a server by editing a config file with the launch command, and the host runs it on demand. No network ports are opened. Most personal-productivity servers use stdio: filesystem, fetch, memory, sqlite. **Streamable HTTP** is the standard for remote servers. It uses a single HTTP connection with bidirectional streaming and OAuth 2.1 with PKCE for authentication. SaaS-backed servers like GitHub, Slack, Linear, Notion, and Sentry use this transport. The earlier **HTTP plus SSE** transport used a separate Server-Sent Events stream for server to client messages. It was deprecated late 2025 because operating two connections proved more complex than the gains justified. New servers should not target it. From host code, calling a tool on a stdio server and calling a tool on a streamable HTTP server looks identical. Only the connection setup differs. The protocol is transport-agnostic by design.

**An MCP transport** is the wire layer that carries JSON-RPC 2.0 messages between client and server. MCP is transport-agnostic: the same `tools/list`, `tools/call`, and `resources/read` messages travel over whichever transport fits the deployment shape. Two transports are in active use as of 2026. **Stdio** is the default for local servers. The host launches the server as a child process. Messages are newline-delimited JSON over stdin and stdout; stderr is reserved for log output. Properties: zero configuration (user adds a config entry with the launch command), no network exposure (no ports opened), and sandboxing inherited from the host's process boundaries. Most official reference servers (filesystem, fetch, memory, sqlite, sequential-thinking) use stdio. **Streamable HTTP** is the 2026 standard for remote servers. It uses a single HTTP connection supporting bidirectional streaming, with OAuth 2.1 plus PKCE for authentication. It replaced the earlier HTTP plus SSE transport, which used a separate Server-Sent Events stream for server to client messages and was deprecated late 2025. Multi-tenant SaaS servers (GitHub's Go-rewritten server, Slack, Linear, Notion, Sentry, Stripe) use streamable HTTP. The transport-agnostic design means the JSON-RPC framing, capability negotiation, and request handling are identical regardless of transport. From host code, the only difference is the connection setup phase. Future transports can be added without breaking existing implementations. The decision is simple: local subprocess servers get stdio. Remote services get streamable HTTP. HTTP plus SSE is legacy; do not target it.

TL;DR

An MCP transport is the wire layer carrying JSON-RPC messages. Stdio (local subprocess) and streamable HTTP (remote service) are the two active transports in 2026; HTTP plus SSE was deprecated.

Memory aid

Easy to grasp

Think of MCP messages as letters in a specific envelope format. The transport is the delivery service that carries them. The letters do not care which service delivers them; they only care that they arrive intact. MCP has two delivery services in use today. Stdio is for when the destination is on the same machine (a local program on your laptop). Streamable HTTP is for when the destination is across the internet (a remote server in the cloud). An older third service called HTTP plus SSE was retired in late 2025 because it was harder to operate. New servers should not use it.

Key concepts

Transport Stdio Transport Streamable HTTP JSON-RPC 2.0

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

A transport in MCP is the layer you rarely think about until something breaks. It is the wire substrate that moves JSON-RPC 2.0 messages between the client (inside the host) and the server (the process wrapping an external system). The protocol defines message shapes and semantics; the transport defines how the bytes travel.

This deep dive covers what a transport is, why MCP is transport-agnostic, the two transports in active production use as of 2026, the transport that was deprecated late 2025, how authentication layers onto transports, and the design trade-offs that landed the ecosystem here.

What a transport is and why it is pluggable

A transport is the wire layer that carries JSON-RPC 2.0 messages between an MCP client and an MCP server. The protocol describes the messages (tools/list, tools/call, resources/read, the initialize handshake, notifications) and what each means semantically. It does not describe how the bytes get from one side to the other.

The pluggability is intentional. Different deployment shapes call for different wire layers. A local server that the host launches as a subprocess wants the cheapest inter-process channel (stdin and stdout). A remote multi-tenant SaaS server wants something that crosses the internet and integrates with existing auth systems (HTTP). Forcing both shapes onto one transport would compromise both.

The payoff is that the JSON-RPC framing, the capability negotiation, and the request handling are identical regardless of transport. From host code, calling a tool on a stdio server looks the same as calling a tool on a streamable HTTP server. The difference is contained in the connection setup phase.

Stdio: the default for local servers

Streamable HTTP: the 2026 standard for remote servers

The deprecated HTTP plus SSE transport

Why transport-agnosticism matters

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Claude Desktop's filesystem server uses stdio: launched as a Node subprocess on the user's machine, messages over stdin/stdout.
GitHub MCP server (rewritten in Go in 2025) uses streamable HTTP: multi-tenant, OAuth 2.1 authentication, deployed in GitHub's cloud.

What an interviewer would ask next. Try answering before peeking at the approach.

QWhy did the spec move from HTTP plus SSE to streamable HTTP?

HTTP plus SSE required two HTTP connections (POST for client to server, SSE for server to client) and was harder to operate across proxies, load balancers, and CDNs. Streamable HTTP collapses both directions onto a single connection with bidirectional streaming, fitting modern HTTP/2 and HTTP/3 deployments naturally.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Targeting HTTP plus SSE for new servers. That transport was deprecated late 2025 in favor of streamable HTTP. New remote servers should use streamable HTTP exclusively.

60 second bullets to scan on the way to the call.

Define an MCP transport as the wire layer for JSON-RPC messages.
Name the two transports in active use in 2026 (stdio, streamable HTTP).

Primary sources. Browse if you want the original framing.