SEP-2322: Multi Round-Trip Requests #2322
SEP-2322: Multi Round-Trip Requests #2322CaitieM20 merged 112 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
Conflict with SEP-2663 on
|
Following up on this: I started to implement both semantics (in an experimental go sdk) - in v1/experimental maps isError: true -> failed, while v2 (aligned with SEP-2663) maps it to completed. The 2663 semantics are cleaner: failed means "the protocol broke" (JSON-RPC error), completed means "the tool ran and gave you a result" (even if that result says isError: true). Since 2663 supersedes the experimental tasks spec, would it make sense to either drop the tasks.mdx edit from this PR (let 2663 own the semantics), or align it with 2663 for the interim? That way implementations don't have conflicting guidance during the migration window. |
This comment was marked as resolved.
This comment was marked as resolved.
All of these SEPs are still in progress, We are collaborating on order of check in to make sure we land the docs correctly. This SEP is planned to be checked in prior to SEP-2663, so we'll address the task specific doc changes in that one, while also pulling this out into an Extension |
* rename IncompleteResult to InputRequiredResult
|
Hey @prezaei if you can give us til 5/15 to get all the in flight SEPs landed, vs open comments where they differ that'd be helpful. We are tracking all the issues and will make sure the Draft Specification and Schema is coherent when we cut an RC on 5/15. |
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