SEP-2322: Multi Round-Trip Requests #2322
SEP-2322: Multi Round-Trip Requests #2322CaitieM20 wants to merge 79 commits intomodelcontextprotocol:mainfrom
Conversation
…emove garbage file
…uestParams — now available on any
client-initiated request, not just tool calls
2. Added typed InputResponse = ElicitResult | CreateMessageResult — InputResponses values are now properly typed
instead of { result: { [key: string]: unknown } }
3. Updated examples — removed the extra result wrapper from TaskInputResponseRequest and
TaskInputResponseRequestParams examples to match the new typed schema
All checks pass: ✅ TypeScript compiles, ✅ JSON schema up to date, ✅ 140/140 examples valid.
Caitie Note: Need to take a look at task-input-response-params.json looks wrong on cursory inspection.
…ngInputRequest → SamplingCreateRequest.
…itRequets these should only be sent as part of IncompleteResponse Objects now
…a JSONRPCIncompleteResultResponse and add examples
…pper in the SEP because InputRequests maps keys directly to the requests so the InputResponses now follows that pattern and there is no benefit to the added wrapper. The only argument for the wrapper would be if we wanted to carry error's alongside results but we do not in these cases. If there is an error the client would retry until the necessary information was retrieved and then send back to the server.
…ut content ordering changes
MRTR schema changes
Marking SEP as Approved with Changes Updating SEP to make IncompleteResponses on available on specific request/response paths (CallTool, GetPrompt, ListResources) making matching schema updates as well. Updating Backward Compatibility & Programming Model section based on Maintainer Discussions in NY
Co-authored-by: Stephen Halter <halter73@gmail.com>
Hey folks, Appreciate the feedback on this. The core maintainers were able to look at usage data from across a variety of MCP Clients, and we don't see a large amount of elicitation usage today. Partly because of the challenges highlighted in this SEP. Moreover many popular Agentic Clients create a new session per tool call. Or share sessions across multiple chat windows. The current way protocol sessions is defined is underspecified and not consistently implemented across the ecosystem, meaning most MCP Servers that try to leverage them will not work correctly. I had a conversation with a developer who was having to implement different variations for each Client it targeted due to inconsistencies (this is not what we want and creates fragmentation in the ecosystem). I hear you on its a breaking change however, I would argue this works in very few cases today. The goal with MRTR is to ensure we have a consistent and supportable implementation for Elicitations and other features moving forward that is well defined and works consistently across the ecosystem |
| if becomes a problem. | ||
|
|
||
| ## Backward Compatibility | ||
|
|
There was a problem hiding this comment.
@halter73, @felixweinberger, @maxisbey, @maciej-kisiel I updated this section to reflect what was discussed at the MCP Maintainer meetup in New York, can you please take a look. I'd like to close out on this by next week.
There was a problem hiding this comment.
If I interpret this section correctly, then it will be legal to support the old await-style syntax in the new SDK versions with the behavior of advertising the 2025-11-25 as the protocol version supported by the server (i.e. no wrapping of MRTR underneath by the SDK). Enabling 2026-06-XX would then require some manual adjustment (e.g. declaration that server-to-client communication is not used or rewriting the handlers to be MRTR-compatible).
If we're aligned on this, then the section LGTM.
There was a problem hiding this comment.
yes I think that's correct. There is some discussion of should we flag the old await style behavior as deprecated (i.e. 2025-11-25 is the last version this is supported) just so developers understand the future path.
update doc type and make result_type camelcase resultType
address a few comments
This is already required since they are not marked optional in the schema. Let me know if there is something more specific you want added here.
Technically you can do this since the Input
Since these aren't marked as optional in the Schema they are required. Let me know if there is something more explicit you want me to add.
Technically you can smuggle these back in InputResponse today since its just the ElicitResult which provides a way to say elicitation declined. I don't know that I'd encourage that pattern in the ephemeral case because its implying that the two requests are somehow associated, and the whole point in MRTR is that they are not.
I think this is a comment for @kurtisvg and SEP-1442
Currently Conformance tests support a draft tag, that's what the conformance tests associated with this SEP have. I'm fine with us moving to a more explicit header to mark what's on deck for the June release and make it clear what we expect SDK maintainers to support, but I think this comment is for the conformance test group |
SEP Cleanup, fixing typos, adding collapsible sessions to make it easier to read. Renamed RetryAugmentedRequestParams to InputResponseRequestParams, to better align with other type names added in this SEP. Removed SEP wording that says ephemeral scenario does not support Elicitation Form URLs, I have a prototype of this working by leveraging request state. Also re-added URLElicitationRequiredError since this may still be necessary.
This is a draft SEP for Multi Round-Trip Requests (MRTR) from the Transports Working Group. It is one of the changes discussed and planned at the December 2025 Core Maintainer Meetup. Exploring the Future of MCP Transports Blog
This SEP Is still in draft, Schema changes are proposed but not locked, documentation updates, conformance tests and additional work still to come, but its ready to move out of Transports Working Group and open up to broader feedback.
Authors: Mark D. Roth (@markdroth), Caitie McCaffrey (@CaitieM20), Gabriel Zimmerman (@gjz22)
Motivation and Context
See SEP for details.
How Has This Been Tested?
Conformance Tests: modelcontextprotocol/conformance#188
Breaking Changes
Yes, see SEP for details
Types of changes
Checklist
Additional context