Streamable HTTP changedspecification/draft/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
26 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/draft/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/draft/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/draft/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/draft/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 582
584582(e.g., a load balancer routing on the header value while the MCP server
585583executes based on the body value).
586584
587<Note>
588 When validating integer parameter values, servers **SHOULD** compare the
589 header value and the body value numerically rather than as strings (e.g.,
590 `42.0` and `42` are considered equal).
591</Note>
585> [!NOTE]
586>
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).
592590
593591When rejecting a request due to header validation failure, servers **MUST**
594592return HTTP status `400 Bad Request` and **MUST** include a JSON-RPC error
from line 623
625623 [Value Encoding](#value-encoding)) before comparing them to the body value.
626624* A header value contains invalid characters.
627625
628<Note>
629 Intermediaries **MUST** return an appropriate HTTP error status (e.g.,
630 `400 Bad Request`) for validation failures but are not required to return
631 a JSON-RPC error response.
632</Note>
626> [!NOTE]
627>
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.
633631
634<Note>
635 Intermediaries that enforce policy based on mirrored headers (e.g., routing
636 or rate-limiting by tenant) **SHOULD** verify that the `MCP-Protocol-Version`
637 header indicates a version that requires header–body validation. If the
638 version is older or the header is absent, the intermediary **SHOULD** reject
639 the request rather than trusting unvalidated header values.
640</Note>
632> [!NOTE]
633>
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.
641639
642640## Backward Compatibility
643641
from line 684
686684
687685### HTTP+SSE Transport (2024-11-05)
688686
689<Warning>
690 **Deprecated**: The [HTTP+SSE transport][http-sse] from protocol version
691 2024-11-05 has been deprecated since protocol version `2025-03-26` and is
692 classified as Deprecated under the [feature lifecycle
693 policy](/community/feature-lifecycle#deprecating-a-feature)
694 ([SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596)).
695 New implementations **SHOULD NOT** adopt it; existing implementations
696 **SHOULD** migrate to [Streamable
697 HTTP](/specification/draft/basic/transports/streamable-http). It is eligible
698 for removal in a future revision; see the [deprecated features
699 registry](/specification/draft/deprecated).
700</Warning>
687> [!WARNING]
688>
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/draft/basic/transports/streamable-http). It is eligible
697> for removal in a future revision; see the [deprecated features
698> registry](/specification/draft/deprecated).
701699
702700Clients and servers can maintain backward compatibility with the
703701deprecated [HTTP+SSE transport][http-sse] (from
No line in this hunk matches that.