Streamable HTTP changedspecification/2026-07-28/basic/transports/streamable-http
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 20 Oct 2026 20:07 UTC.
Upstream edited
Recorded here
Lines+66added
Lines−68removed
From line
1
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits3to this page, all time
The whole hunk
from line 1, old and new numbered
/
from line 1
11# Streamable HTTP
22
3<div id="enable-section-numbers" />
3> [!NOTE]
4>
5> Streamable HTTP was introduced in protocol version 2025-03-26 as a replacement
6> for the \[HTTP+SSE transport]\[http-sse] from protocol version 2024-11-05.
47
5<Info>
6 Streamable HTTP was introduced in protocol version 2025-03-26 as a replacement
7 for the [HTTP+SSE transport][http-sse] from protocol version 2024-11-05.
8</Info>
8> [!NOTE]
9>
10> Revision 2026-07-28 changed the behavior of Streamable HTTP. Clients must
11> ensure they handle backwards compatibility correctly. Changes included:
12>
13> * Removal of the GET stream endpoint.
14> * Removal of protocol-level sessions.
15>
16> See the [changelog](/specification/2026-07-28/changelog) and
17> [Backward Compatibility](#backward-compatibility) below.
918
10<Info>
11 Revision 2026-07-28 changed the behavior of Streamable HTTP. Clients must
12 ensure they handle backwards compatibility correctly. Changes included:
13
14 * Removal of the GET stream endpoint.
15 * Removal of protocol-level sessions.
16
17 See the [changelog](/specification/2026-07-28/changelog) and
18 [Backward Compatibility](#backward-compatibility) below.
19</Info>
20
2119In the **Streamable HTTP** transport, the server operates as an independent
2220process that can handle multiple client connections. At a glance:
2321
from line 83
8583 `Content-Type: text/event-stream` (an SSE response stream). The client
8684 **MUST** support both.
8785
88<Note>
89 This revision of the core protocol defines no client-to-server
90 *notifications* over Streamable HTTP. The only client-sent notification in
91 the core protocol, `notifications/cancelled`, is used only on the
92 [stdio](/specification/2026-07-28/basic/transports/stdio) transport; on
93 Streamable HTTP, closing the SSE response stream is itself the cancellation
94 signal and no `notifications/cancelled` message is expected (see
95 [Cancellation][cancellation]). The notification rules above describe the
96 transport mechanics for a notification POST; header requirements for
97 notification POSTs are not defined by this revision.
98</Note>
86> [!NOTE]
87>
88> This revision of the core protocol defines no client-to-server
89> *notifications* over Streamable HTTP. The only client-sent notification in
90> the core protocol, `notifications/cancelled`, is used only on the
91> [stdio](/specification/2026-07-28/basic/transports/stdio) transport; on
92> Streamable HTTP, closing the SSE response stream is itself the cancellation
93> signal and no `notifications/cancelled` message is expected (see
94> \[Cancellation]\[cancellation]). The notification rules above describe the
95> transport mechanics for a notification POST; header requirements for
96> notification POSTs are not defined by this revision.
9997
10098## Receiving Messages
10199
from line 132
134132them to the client, introducing unwanted latency and potentially breaking the
135133real-time nature of SSE communication.
136134
137<Note>
138 For long-lived streams — in particular the
139 [`subscriptions/listen`][subscriptions-listen] response stream — servers are
140 encouraged to periodically emit an SSE comment line (a line beginning with a
141 colon, e.g. `:\r\n`) as a keep-alive. This keeps the connection from being
142 closed by intermediaries or client idle timeouts during quiet periods when no
143 notifications are flowing. Per the [SSE specification][sse], any line beginning
144 with a colon is a comment that carries no event data; clients must ignore such
145 lines and must not treat them as malformed input.
146</Note>
135> [!NOTE]
136>
137> For long-lived streams — in particular the
138> \[`subscriptions/listen`]\[subscriptions-listen] response stream — servers are
139> encouraged to periodically emit an SSE comment line (a line beginning with a
140> colon, e.g. `:\r\n`) as a keep-alive. This keeps the connection from being
141> closed by intermediaries or client idle timeouts during quiet periods when no
142> notifications are flowing. Per the \[SSE specification]\[sse], any line beginning
143> with a colon is a comment that carries no event data; clients must ignore such
144> lines and must not treat them as malformed input.
147145
148146Resumable SSE streams via `Last-Event-ID` are not supported.
149147
from line 581
583581(e.g., a load balancer routing on the header value while the MCP server
584582executes based on the body value).
585583
586<Note>
587 When validating integer parameter values, servers **SHOULD** compare the
588 header value and the body value numerically rather than as strings (e.g.,
589 `42.0` and `42` are considered equal).
590</Note>
584> [!NOTE]
585>
586> When validating integer parameter values, servers **SHOULD** compare the
587> header value and the body value numerically rather than as strings (e.g.,
588> `42.0` and `42` are considered equal).
591589
592590When rejecting a request due to header validation failure, servers **MUST**
593591return HTTP status `400 Bad Request` and **MUST** include a JSON-RPC error
from line 622
624622 [Value Encoding](#value-encoding)) before comparing them to the body value.
625623* A header value contains invalid characters.
626624
627<Note>
628 Intermediaries **MUST** return an appropriate HTTP error status (e.g.,
629 `400 Bad Request`) for validation failures but are not required to return
630 a JSON-RPC error response.
631</Note>
625> [!NOTE]
626>
627> Intermediaries **MUST** return an appropriate HTTP error status (e.g.,
628> `400 Bad Request`) for validation failures but are not required to return
629> a JSON-RPC error response.
632630
633<Note>
634 Intermediaries that enforce policy based on mirrored headers (e.g., routing
635 or rate-limiting by tenant) **SHOULD** verify that the `MCP-Protocol-Version`
636 header indicates a version that requires header–body validation. If the
637 version is older or the header is absent, the intermediary **SHOULD** reject
638 the request rather than trusting unvalidated header values.
639</Note>
631> [!NOTE]
632>
633> Intermediaries that enforce policy based on mirrored headers (e.g., routing
634> or rate-limiting by tenant) **SHOULD** verify that the `MCP-Protocol-Version`
635> header indicates a version that requires header–body validation. If the
636> version is older or the header is absent, the intermediary **SHOULD** reject
637> the request rather than trusting unvalidated header values.
640638
641639## Backward Compatibility
642640
from line 683
685683
686684### HTTP+SSE Transport (2024-11-05)
687685
688<Warning>
689 **Deprecated**: The [HTTP+SSE transport][http-sse] from protocol version
690 2024-11-05 has been deprecated since protocol version `2025-03-26` and is
691 classified as Deprecated under the [feature lifecycle
692 policy](/community/feature-lifecycle#deprecating-a-feature)
693 ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
694 New implementations **SHOULD NOT** adopt it; existing implementations
695 **SHOULD** migrate to [Streamable
696 HTTP](/specification/2026-07-28/basic/transports/streamable-http). It is
697 eligible for removal in a future revision; see the [deprecated features
698 registry](/specification/2026-07-28/deprecated).
699</Warning>
686> [!WARNING]
687>
688> **Deprecated**: The \[HTTP+SSE transport]\[http-sse] from protocol version
689> 2024-11-05 has been deprecated since protocol version `2025-03-26` and is
690> classified as Deprecated under the [feature lifecycle
691> policy](/community/feature-lifecycle#deprecating-a-feature)
692> ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
693> New implementations **SHOULD NOT** adopt it; existing implementations
694> **SHOULD** migrate to [Streamable
695> HTTP](/specification/2026-07-28/basic/transports/streamable-http). It is
696> eligible for removal in a future revision; see the [deprecated features
697> registry](/specification/2026-07-28/deprecated).
700698
701699Clients and servers can maintain backward compatibility with the
702700deprecated [HTTP+SSE transport][http-sse] (from
No line in this hunk matches that.