Transport and headers

How MCP messages travel, and the headers the 2026-07-28 revision added, changed, or dropped.

Streamable HTTP

Changed in 2026-07-28 The HTTP transport for MCP, introduced in the 2025-03-26 revision. #

The HTTP transport for MCP, introduced in the 2025-03-26 revision. A server exposes one HTTP endpoint that accepts POST, and the client sends every JSON-RPC request or notification as its own POST. The server answers each one with either a single JSON object or a Server-Sent Events stream scoped to that request.

This revision removed the GET stream endpoint and protocol-level sessions, and stopped servers sending their own JSON-RPC requests on a stream.

Where you meet it

It is the transport every remote MCP server uses, and the one every authorization question applies to. Clients must send an Accept header listing both application/json and text/event-stream.

Also written: Streamable HTTP · streamable http transport · MCP endpoint · remote MCP transport

Source: MCP 2026-07-28: Streamable HTTP

On this site: Works in Claude Code but not claude.ai

stdio

The transport in which the client launches the MCP server as a subprocess and the two exchange newline-delimited JSON-RPC messages over the subprocess's standard input and output. #

The transport in which the client launches the MCP server as a subprocess and the two exchange newline-delimited JSON-RPC messages over the subprocess's standard input and output. The server must not write anything to stdout that is not a valid MCP message; stderr is free for logging.

Where you meet it

It is how a local MCP server runs inside an editor or desktop client. The MCP authorization specification does not apply here — stdio implementations should not follow it, and should take credentials from the environment instead.

Also written: stdio · standard input output transport · local MCP server

Source: MCP 2026-07-28: stdio

Read next: Streamable HTTP Statelessness

HTTP+SSE transport

Deprecated in 2025-03-26 The original two-endpoint HTTP transport from the 2024-11-05 revision: the client opened an SSE stream with GET and posted messages to a separate endpoint the stream advertised. #

The original two-endpoint HTTP transport from the 2024-11-05 revision: the client opened an SSE stream with GET and posted messages to a separate endpoint the stream advertised. Streamable HTTP replaced it.

Deprecated since 2025-03-26 and classified Deprecated under the feature lifecycle policy. New implementations should not adopt it; migrate to Streamable HTTP.

Where you meet it

You still meet it in older servers and in client fallback code. A modern client detects it by attempting a modern POST first and only opening a GET stream if the failure body is not a recognized modern JSON-RPC error.

Also written: HTTP+SSE · HTTP with SSE · SSE transport · old MCP transport · 2024-11-05 transport

Source: MCP 2026-07-28: HTTP+SSE Transport (2024-11-05)

Mcp-Session-Id

Removed in 2026-07-28 The HTTP header that carried a protocol-level session identifier in the 2025-03-26 through 2025-11-25 revisions. #

The HTTP header that carried a protocol-level session identifier in the 2025-03-26 through 2025-11-25 revisions. A server minted it, the client echoed it on later requests, and HTTP DELETE ended the session. The 2026-07-28 revision removed protocol-level sessions and this header with them.

Deleted from this revision as a breaking change, not deprecated first — so it is absent rather than scheduled for removal.

Where you meet it

A server on the current revision must ignore an Mcp-Session-Id header it receives, and must not mint or echo session IDs. If you are following a tutorial that tells you to send one, the tutorial predates July 2026. State that has to survive across calls is now passed as an explicit server-minted handle in ordinary tool arguments.

Also written: Mcp-Session-Id · mcp session id header · MCP session · no valid session ID provided

Source: MCP 2026-07-28: Earlier Streamable HTTP Revisions

MCP-Protocol-Version

The HTTP header that carries the protocol version on every Streamable HTTP POST, for example MCP-Protocol-Version: 2026-07-28. #

The HTTP header that carries the protocol version on every Streamable HTTP POST, for example MCP-Protocol-Version: 2026-07-28. Its value must match the io.modelcontextprotocol/protocolVersion field in the request body's _meta. A mismatch is rejected with 400 Bad Request and a HeaderMismatch error; an unsupported version is rejected with 400 and UnsupportedProtocolVersionError.

Where you meet it

It is also the header an intermediary has to check before it trusts any of the other mirrored headers. The specification says an intermediary enforcing policy on mirrored headers should reject a request whose version is older than the one requiring header-body validation, rather than trust an unvalidated value.

Also written: MCP-Protocol-Version · protocol version header · mcp protocol version · unsupported protocol version

Source: MCP 2026-07-28: Protocol Version Header

Mcp-Method

New in 2026-07-28 An HTTP header mirroring the JSON-RPC method field of the request body, required on all Streamable HTTP POST requests. #

An HTTP header mirroring the JSON-RPC method field of the request body, required on all Streamable HTTP POST requests. The transport mirrors body fields into headers so that intermediaries can route and inspect requests without parsing the body.

Added in this revision and required for compliance.

Where you meet it

A proxy that strips unknown headers will break a compliant client, because the server must reject a request whose required headers are missing with 400 Bad Request and -32020.

Also written: Mcp-Method · mcp method header · mirrored headers

Source: MCP 2026-07-28: Standard Request Headers

Mcp-Name

New in 2026-07-28 An HTTP header mirroring params.name or params.uri from the request body, required on tools/call, resources/read, and prompts/get requests. #

An HTTP header mirroring params.name or params.uri from the request body, required on tools/call, resources/read, and prompts/get requests. A server that processes the body must reject a request whose header does not match the body value.

Added in this revision and required for compliance on the three named methods.

Where you meet it

It is what lets a gateway rate-limit or route by tool name without reading the payload. A value that is not plain ASCII is carried in a Base64 sentinel form, =?base64?VALUE?=, which an intermediary must decode before comparing it to the body.

Also written: Mcp-Name · mcp name header · tool name header

Source: MCP 2026-07-28: Standard Request Headers

x-mcp-header

New in 2026-07-28 An extension property a server puts on a parameter inside a tool's inputSchema to have the client mirror that parameter's value into an HTTP header named Mcp-Param-{Name}. #

An extension property a server puts on a parameter inside a tool's inputSchema to have the client mirror that parameter's value into an HTTP header named Mcp-Param-{Name}. Using it is optional for servers; supporting it is mandatory for clients on Streamable HTTP.

Added in this revision. Clients on other transports may ignore the annotation entirely.

Where you meet it

The constraints are strict and the penalty is silent: the annotated property must be reachable through properties keys alone, must be a string, integer, or boolean, and a client must reject a tool definition that breaks any of the rules by excluding that tool from tools/list. One malformed annotation makes a single tool disappear with only a client-side warning.

Also written: x-mcp-header · Mcp-Param · custom headers from tool parameters · tool parameter header

Source: MCP 2026-07-28: Custom Headers from Tool Parameters

Statelessness

New in 2026-07-28 MCP is a stateless protocol as of the 2026-07-28 revision. #

MCP is a stateless protocol as of the 2026-07-28 revision. Servers must not rely on prior requests over the same connection to establish context, and cross-request state must be referenced by an explicit identifier the client passes on each request. As the specification puts it, an open connection, such as a stdio process, is not a conversation or session.

Introduced in this revision (SEP-2567, SEP-2575). Earlier revisions were session-oriented.

Where you meet it

This is what removed sessions, the initialize handshake, and stream resumability all at once, and it is why sticky routing is no longer a requirement in front of an MCP server. A client may interleave unrelated requests on one transport, and a server must not read connection identity as conversation identity.

Also written: stateless · statelessness · stateless MCP · sessions removed · MCP is stateless

Source: MCP 2026-07-28: Statelessness

subscriptions/listen

New in 2026-07-28 A long-lived request that opens a server-to-client notification stream filtered to the event types the client names. #

A long-lived request that opens a server-to-client notification stream filtered to the event types the client names. It replaces the resources/subscribe RPC and the HTTP GET endpoint of earlier revisions. A client opts in to specific types, and the server must not send a type the client did not request.

Added in this revision, replacing resources/subscribe, resources/unsubscribe, and the GET stream.

Where you meet it

Its state is scoped to the request, not the connection, so it does not reintroduce sessions. Request-scoped notifications such as notifications/progress do not travel on the listen stream — they flow on the response stream of the request they belong to.

Also written: subscriptions/listen · resources/subscribe · MCP notifications stream · subscriptionId

Source: MCP 2026-07-28: Subscriptions

[data-glossary-term]:target > details::details-content { content-visibility: visible; } [data-glossary-term]:target > details > summary [data-term-gist] { display: none; } [data-glossary-term]:target > details > summary [data-term-chevron] { rotate: 90deg; }