Page history
SEP-2322: Multi Round-Trip Requests
seps/2322-MRTR
History
seps/2322-MRTR First recorded · 1394 lines, first recorded
# SEP-2322: Multi Round-Trip Requests ## Abstract ## Motivation ## Specification ### Schema Changes ### Server-Initiated Request Support for Client Requests ### Ephemeral Tool Workflow #### Real-World Example for Ephemeral Workflow #### Use Cases for Request State ##### Use Case 1: Rolling Upgrades ##### Use Case 2: Load Shedding #### Protocol Requirements for Ephemeral Workflow ### Persistent Tool Workflow #### Protocol Requirements for Persistent Workflow ### Interactions Between Ephemeral and Persistent Workflows ### Guidance for Error Handling ## Rationale ## Backward Compatibility ## Security Implications ## Reference Implementation ### Acknowledgments
The first capture of this source. The page was already there, and this is what it said.
# SEP-2322: Multi Round-Trip Requests
> Multi Round-Trip Requests
<div className="flex items-center gap-2 mb-4">
<Badge color="green" shape="pill">
Final
</Badge>
<Badge color="gray" shape="pill">
Standards Track
</Badge>
</div>
<Note>
This SEP has reached Final status and is preserved as a historical record of
the design as accepted. Changes made to the protocol after finalization are
not reflected here. Refer to the [current
specification](/specification/latest) and its changelog for authoritative
requirements.
</Note>
| Field | Value |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SEP** | 2322 |
| **Title** | Multi Round-Trip Requests |
| **Status** | Final |
| **Type** | Standards Track |
| **Created** | 2026-02-03 |
| **Author(s)** | Mark D. Roth ([@markdroth](https://github.com/markdroth)), Caitie McCaffrey ([@CaitieM20](https://github.com/CaitieM20)), Gabriel Zimmerman ([@gjz22](https://github.com/gjz22)) |
| **Sponsor** | Caitie McCaffrey ([@CaitieM20](https://github.com/CaitieM20)) |
| **PR** | [#2322](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322) |
***
## Abstract
This proposal specifies a simple way to handle server-initiated requests
in the context of a client-initiated request (e.g., an elicitation
request in the context of a tool call) without requiring a shared
storage layer shared across server instances or statefulness in
load balancing, which will significantly reduce the cost of operating
MCP servers at scale in the common case. It also reduces the HTTP
transport's dependence on SSE streams, which cause problems in a lot of
environments that cannot support long-lived connections.
This proposed way of handling server-initiated requests will replace the current approach of sending server-initiated requests. This is a breaking change.
This SEP also specifies the subset of client requests that a server can
send a server-initiated request on. This is a reduced scope compared to the current spec and is also a breaking change.
Making a breaking change here is necessary since adoption of server-initiated request features like Elicitation, Sampling and ListRoots is very low or blocked for many Remote MCP servers or Server Hosted Clients due to the operational complextity of supporting the SSE streams and server-side state.
## Motivation
Note: This SEP is intended to provide a generic mechanism for handling
any server-initiated request in the context of any client-initiated
request. For clarity, throughout this document, we will specifically
discuss tool calls as a proxy for any client-initiated request, but it
should be read as applying equally to (e.g.) resource or prompt
requests; similarly, we will discuss elicitation requests as a proxy for
any server-initiated request, but it should be read as applying equally
to (e.g.) sampling requests.
We start with the observation that there are two types of MCP tools:
1. **Ephemeral**: No state is accumulated on the server side.
* If server needs more info to process the tool call, it can start from
scratch when it gets that additional info.
* Examples: weather app, accessing email
2. **Persistent**: State is accumulated on the server side.
* Server may generate a large amount of state before requesting more
info from the client, and it may need to pick up that state to
continue processing after it receives the info from the client.
* Server may need to continue processing in the background while
waiting for more info from the client, in which case server-side
state is needed to track that ongoing processing.
* Examples: accessing an agent, spinning up a VM and needing user
interaction to manipulate the VM
The vast majority of MCP tools will be ephemeral, and it is extremely
common for tools to be deployed in a horizontally scaled, load balanced
service, so we need to optimize for this case.
Today, if a tool needs to send an elicitation request in order to make
progress, the workflow works like this:
1. Client sends tool call request. For this example, let's assume that
the load balancers happen to send this request to server instance A.
2. Server A opens an SSE stream and sends the elicitation request on that
stream.
3. Client sends the elicitation response as a separate request, for which
the load balancers will choose a server instance completely
independently of the one they chose in step 1. In this example,
let's assume that the load balancers happen to send this request to
server instance B.
4. Server A must somehow discover the elicitation response delivered to
server B.
5. Server A then sends the tool call result on the SSE stream opened in
step 2.
```mermaid theme={null}
sequenceDiagram
participant C as Client
participant LB as Load Balancer
participant SA as Server Instance A
participant SB as Server Instance B
Note over C,SA: 1. Initial Request
C->>LB: Tool Call (Start)
LB->>SA: Route to Instance A
activate SA
SA-->>C: Elicitation Request (SSE Stream Open)
Note right of SA: Server A holds memory,<br/>waiting for response...
Note over C,SB: 2. User Responds
C->>LB: Elicitation Result
LB->>SB: Route to Instance B (Stateless LB)
activate SB
Note over SA,SB: A is waiting, but B has the data.
Note over SA,SB: Requires Shared Storage to bridge this gap.
deactivate SA
deactivate SB
```
The difficult part here is step 4, which requires some sort of
statefulness on the server side. The main way to solve this problem
today is to have a storage layer shared across all server instances, so
that multiple server instances can match up the elicitation response
on one server instance with the original ongoing tool call on a
different server instance.
There are two main approaches that can be used to solve this problem today:
* **Persistent Storage Layer Shared Across Server Instances**: Servers can
deploy and manage a persistent storage layer (e.g., PostgreSQL, Redis,
DynamoDB), which allow multiple server instances to match up the
elicitation response on one server instance with the original ongoing
tool call on a different server instance. This approach has a number
of drawbacks:
* The persistent storage layer is **extremely expensive**, especially for
ephemeral tools that may not already have such a layer (e.g., a weather
tool).
* The persistent storage layer imposes significant reliability concerns:
it becomes a critical dependency and therefore a potential single
point of failure. To avoid that, it must provide high availability,
replication, and backup mechanisms.
* The persistent storage layer becomes a bottleneck, limiting horizontal
scalability. Geographic distribution requires either expensive
global replication or sticky routing.
* The persistent storage layer also imposes significant operational
complexity. In horizontally scaled deployments, it requires
distributed locking or consensus protocols. It also requires special
garbage collection logic to determine when shared can be cleaned up,
which requires careful trade-offs: cleaning up state too aggressively
can reduce storage costs but limit how long users have to respond,
whereas cleaning up less aggressively accommodates slow users but
increases storage costs.
* This approach requires special behavior in the tool implementation to
integrate with the persistent storage layer. The MCP SDKs today do
not have any special hooks for this sort of storage layer integration,
which means that it's very hard to write in-line code via the SDKs.
* **Statefulness in Load Balancing**: With the use of cookies, it is
possible for the load balancing layer to ensure that the elicitation
request in step 3 is delivered to the same server instance that the
original request was delivered to in step 1. This approach, while
often cheaper than a persistent storage layer, has the following
drawbacks:
* It requires special configuration and behavior in the load
balancers, which is often difficult to manage.
* It breaks normal load balancing models, resulting in uneven load
distribution, thus increasing the cost of running the service.
* It requires special behavior in clients to propagate the cookies
used for statefulness.
* It requires the tool implementation to match up the elicitation
request with the ongoing tool call. (The MCP SDKs have some code to
handle this, but it's still a very strange pattern in the HTTP
world.)
* It is not fault tolerant. If the server instance goes down, all
state is lost, and the tool call would need to start over from
scratch. (This doesn't necessarily matter for ephemeral tools,
but it is an issue for persistent tools.)
Also, both of these approaches rely on the use of an SSE stream, which
causes problems in environments that cannot support long-lived
connections. They also require an instance of the tool to stay in memory
in a particular server instance indefinitely. This is particularly
problematic for elicitation requests specifically, since the result may
not come from the user for an unbounded amount of time (e.g., it could
be days or months, or maybe even never).
The goal of this SEP is to propose a simpler way to handle the pattern
of server-initiated requests within the context of a client-initiated
request. Specifically, we need to make it cheaper to support this pattern
in the common case of an ephemeral tool in a horizontally scaled, load
balanced deployment. This means that we need a solution that does not
depend on an SSE stream and does not require either a persistent storage
layer or stateful load balancing, which in turn means that we need to
avoid dependencies between requests: servers must be able to process
each individual request using no information other than what is present
in that individual request.
Note that while the goal here is to optimize the common case of ephemeral
tools, we do want to continue to support persistent tools, which generally
already require a persistent storage layer.
## Specification
This SEP proposes a new mechanism for handling server requests in the
context of a client request. This new mechanism will have a slightly
different workflow for ephemeral tools and persistent tools, the latter
of which will leverage Tasks. However, both workflows will use the same
data structures.
### Schema Changes
First, we introduce the notion of `InputRequests`, which represents
a set of one or more server-initiated request to be sent to the client,
and `InputResponses`, which represents the client's responses to
those requests. Both requests and responses are stored in a map with
string keys. For `InputRequests`, the map values are server-initiated
requests (e.g., elicitation or sampling requests), whereas for `InputResponses`, the map values are the responses to those requests. Here's
how that would look in the typescript MCP schema:
```typescript theme={null}
export type InputRequest =
CreateMessageRequest | ElicitRequest | ListRootsRequest;
export interface InputRequests {
[key: string]: InputRequest;
}
export type InputResponse =
CreateMessageResult | ElicitResult | ListRootsResult;
export interface InputResponses {
[key: string]: InputResponse;
}
```
The keys are assigned by the server when issuing the requests. The client
will send the response for each request using the corresponding key.
For example, a server might send the following input requests:
```json5 theme={null}
"inputRequests": {
// Elicitation request.
"github_login": {
"method": "elicitation/create",
"params": {
"mode": "form",
"message": "Please provide your GitHub username",
"requestedSchema": {
"type": "object",
"properties": {
"name": {
"type": "string"
}
},
"required": ["name"]
}
}
},
// Sampling request.
"capital_of_france" : {
"method": "sampling/createMessage",
"params": {
"messages": [
{
"role": "user",
"content": {
"type": "text",
"text": "What is the capital of France?"
}
}
],
"modelPreferences": {
"hints": [
{
"name": "claude-3-sonnet"
}
],
"intelligencePriority": 0.8,
"speedPriority": 0.5
},
"systemPrompt": "You are a helpful assistant.",
"maxTokens": 100
}
}
}
```
The client would then send the responses in the following form:
```json5 theme={null}
"inputResponses": {
// Elicitation response (ElicitResult).
"github_login": {
"action": "accept",
Cut at 300 lines.