Disclaimer: Parts of this text were generated in conversation with AI (Anthropic Claude Sonnet 4.6). I do not claim to fully understand MCP and have gathered the design intent only from reading the docs and blog. Apologies in advance for inadvertent errors. However, I have reviewed and edited the text to the best of my knowledge and I feel confident that this proposal has the potential to significantly improve MCP.
tl;dr: The HTTP Events Query Protocol built on the HTTP QUERY method offers a more principled and scalable the Transport WG is actively designing toward. Several of the problems identified in the December 2025 transport roadmap post are problems Events Query already solves structurally.
Problems with the current transport
MCP's Streamable HTTP transport (2025-03-26) uses HTTP POST for client-server requests, with the server optionally returning a text/event-stream response for operations that produce multiple messages. This has the following problems:
-
POST is neither safe nor idempotent. A failed or timed-out tools/call request cannot be automatically retried by the client or an intermediary without risk of duplicate side effects. This places retry logic entirely on the application layer. As the Transport WG has identified, load balancers must parse full JSON-RPC payloads to route traffic rather than using standard HTTP patterns, and stateful connections force sticky routing that prevents effective auto-scaling.
-
The WG is separately exploring exposing routing-critical information like the RPC method or tool name via HTTP headers so that intermediaries can route without body inspection. Events Query addresses this more fundamentally: because it is built on QUERY — a method that is declared safe and idempotent — intermediaries have semantic permission to cache, retry, and route requests using standard HTTP infrastructure.
-
The response of the POST request is text/event-stream. This creates two compounding problems:
-
The native browser EventSource API is only defined to use the GET method. MCP implementations cannot use the native EventSource interface anyway and must instead resort to manual stream reading via the Fetch API.
-
You are tied down to use the text/event-stream , a line-framed UTF-8 text format which makes transferring say, JSON messages, tedious, increasing work for both servers and clients.
The foundation: HTTP QUERY
QUERY1 fills the gap between GET and POST: like GET it is safe and idempotent, but like POST it allows a request body that defines the query. Responses can be assigned a URI via the Location response header field, enabling the query itself to become a cacheable, GET-accessible resource — a property with direct applicability to MCP's capability discovery and tools manifest patterns, and aligned with the Server Cards direction the WG is pursuing.
What Events Query adds
HTTP Events Query, which I have proposed at the HTTPAPI WG in IETF, builds on QUERY to support streaming notification responses from the queried resource itself. The subscription is expressed in the QUERY request body; the response delivers the current resource representation (if requested) followed by a stream of event notifications — all within a single response, with HTTP content negotiation applying to both the representation and the notifications. This maps directly onto MCP's open design problems:
-
Stateless horizontal scaling: Because each Events Query request can be self-contained and is idempotent, there is no requirement for sticky routing or distributed session storage. Servers can scale horizontally without coordination. The initialize handshake the WG is looking to eliminate is replaced by per-request capability negotiation, which Events Query's content negotiation model already supports naturally.
-
Elicitation and sampling without suspended state: MCP's elicitation model requires the server to hold suspended execution state while awaiting a client response mid-tool-call — the primary driver of session statefulness. Events Query fits naturally here: the elicitation request arrives as a notification on the original QUERY's response stream, and the client answers with a follow-up QUERY to the same resource, eliminating suspended state and restoring serverless viability. The Transport WG's own proposed redesign — having the server return elicitation requests inline and the client bundle the answer into the next request — is structurally what Events Query already provides. URL mode elicitation, which involves asynchronous out-of-band completion notifications, maps onto an open Events Query subscription stream, no worse than the current transport's persistent GET/SSE channel requirement.
-
Tool invocation and progress streaming: A tools/call is a query operation in the QUERY sense — the request body describes the operation, and the server streams progress notifications followed by the final result in a single response. Unlike the current approach of returning text/event-stream from a POST response outside the EventSource specification, Events Query operates within standard HTTP semantics throughout.
-
Resource subscriptions: Events Query was designed precisely for this — receiving the current resource representation and subsequent change notifications in a single response, from the resource itself, without a dedicated notification endpoint. The WG is exploring replacing the general-purpose GET stream with explicit per-resource subscription streams; Events Query is that model.
-
Content negotiation for notifications: Events Query supports arbitrary media types for notifications, negotiated as part of the request. This eliminates the structural constraint of text/event-stream which is limited to UTF-8 text. Clients and servers are free to use application/json or any other suitable type directly, eliminating the double-framing of JSON-RPC inside text/event-stream and enabling binary data where appropriate.
Proposed next step
The Transport WG's December 2025 roadmap post describes problems that Events Query addresses. Rather than designing new application-layer mechanisms to work around the constraints of POST and text/event-stream, I would welcome a discussion on whether Events Query could serve as the foundation for the next MCP transport. I even suspect that many changes can be made in manner that is backwards compatible with the current use of POST (if legacy users are willing to forego the scaling benefits). As the author of the Events Query Internet Draft, I available to answer technical questions or work through the mapping between Events Query and MCP's invocation semantics in detail.
References:
Disclaimer: Parts of this text were generated in conversation with AI (Anthropic Claude Sonnet 4.6). I do not claim to fully understand MCP and have gathered the design intent only from reading the docs and blog. Apologies in advance for inadvertent errors. However, I have reviewed and edited the text to the best of my knowledge and I feel confident that this proposal has the potential to significantly improve MCP.
tl;dr: The HTTP Events Query Protocol built on the HTTP QUERY method offers a more principled and scalable the Transport WG is actively designing toward. Several of the problems identified in the December 2025 transport roadmap post are problems Events Query already solves structurally.
Problems with the current transport
MCP's Streamable HTTP transport (2025-03-26) uses HTTP POST for client-server requests, with the server optionally returning a
text/event-streamresponse for operations that produce multiple messages. This has the following problems:POST is neither safe nor idempotent. A failed or timed-out
tools/callrequest cannot be automatically retried by the client or an intermediary without risk of duplicate side effects. This places retry logic entirely on the application layer. As the Transport WG has identified, load balancers must parse full JSON-RPC payloads to route traffic rather than using standard HTTP patterns, and stateful connections force sticky routing that prevents effective auto-scaling.The WG is separately exploring exposing routing-critical information like the RPC method or tool name via HTTP headers so that intermediaries can route without body inspection. Events Query addresses this more fundamentally: because it is built on QUERY — a method that is declared safe and idempotent — intermediaries have semantic permission to cache, retry, and route requests using standard HTTP infrastructure.
The response of the POST request is
text/event-stream. This creates two compounding problems:The native browser
EventSourceAPI is only defined to use the GET method. MCP implementations cannot use the native EventSource interface anyway and must instead resort to manual stream reading via the Fetch API.You are tied down to use the
text/event-stream, a line-framed UTF-8 text format which makes transferring say, JSON messages, tedious, increasing work for both servers and clients.The foundation: HTTP QUERY
QUERY1 fills the gap between GET and POST: like GET it is safe and idempotent, but like POST it allows a request body that defines the query. Responses can be assigned a URI via the
Locationresponse header field, enabling the query itself to become a cacheable, GET-accessible resource — a property with direct applicability to MCP's capability discovery and tools manifest patterns, and aligned with the Server Cards direction the WG is pursuing.What Events Query adds
HTTP Events Query, which I have proposed at the HTTPAPI WG in IETF, builds on QUERY to support streaming notification responses from the queried resource itself. The subscription is expressed in the QUERY request body; the response delivers the current resource representation (if requested) followed by a stream of event notifications — all within a single response, with HTTP content negotiation applying to both the representation and the notifications. This maps directly onto MCP's open design problems:
Stateless horizontal scaling: Because each Events Query request can be self-contained and is idempotent, there is no requirement for sticky routing or distributed session storage. Servers can scale horizontally without coordination. The initialize handshake the WG is looking to eliminate is replaced by per-request capability negotiation, which Events Query's content negotiation model already supports naturally.
Elicitation and sampling without suspended state: MCP's elicitation model requires the server to hold suspended execution state while awaiting a client response mid-tool-call — the primary driver of session statefulness. Events Query fits naturally here: the elicitation request arrives as a notification on the original QUERY's response stream, and the client answers with a follow-up QUERY to the same resource, eliminating suspended state and restoring serverless viability. The Transport WG's own proposed redesign — having the server return elicitation requests inline and the client bundle the answer into the next request — is structurally what Events Query already provides. URL mode elicitation, which involves asynchronous out-of-band completion notifications, maps onto an open Events Query subscription stream, no worse than the current transport's persistent GET/SSE channel requirement.
Tool invocation and progress streaming: A
tools/callis a query operation in the QUERY sense — the request body describes the operation, and the server streams progress notifications followed by the final result in a single response. Unlike the current approach of returningtext/event-streamfrom a POST response outside the EventSource specification, Events Query operates within standard HTTP semantics throughout.Resource subscriptions: Events Query was designed precisely for this — receiving the current resource representation and subsequent change notifications in a single response, from the resource itself, without a dedicated notification endpoint. The WG is exploring replacing the general-purpose GET stream with explicit per-resource subscription streams; Events Query is that model.
Content negotiation for notifications: Events Query supports arbitrary media types for notifications, negotiated as part of the request. This eliminates the structural constraint of
text/event-streamwhich is limited to UTF-8 text. Clients and servers are free to useapplication/jsonor any other suitable type directly, eliminating the double-framing of JSON-RPC insidetext/event-streamand enabling binary data where appropriate.Proposed next step
The Transport WG's December 2025 roadmap post describes problems that Events Query addresses. Rather than designing new application-layer mechanisms to work around the constraints of POST and
text/event-stream, I would welcome a discussion on whether Events Query could serve as the foundation for the next MCP transport. I even suspect that many changes can be made in manner that is backwards compatible with the current use of POST (if legacy users are willing to forego the scaling benefits). As the author of the Events Query Internet Draft, I available to answer technical questions or work through the mapping between Events Query and MCP's invocation semantics in detail.References:
Footnotes
The QUERY method was approved by the IESG as a Proposed Standard on 20 November 2025. It is in the RFC Production Center queue awaiting final publication — an administrative step (Please see the reference above). ↩