SEP-2260 Require Server requests to be associated with a Client request.#2260
Merged
evalstate merged 25 commits intomodelcontextprotocol:mainfrom Mar 10, 2026
Merged
Conversation
Member
|
Maybe explicitly exclude or include pings as valid requests to associate with? They have a request id, but I suppose they're not that useful for stateless transports. It would also be a kind of workaround to not having unsolicited server-initiated requests. |
CaitieM20
reviewed
Feb 17, 2026
CaitieM20
reviewed
Feb 17, 2026
CaitieM20
reviewed
Feb 17, 2026
CaitieM20
reviewed
Feb 17, 2026
…-requests Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
…-requests Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
- Fixed missing closing backtick in Abstract (sampling/createMessage, elicitation/create) - Fixed typo: 'Reqeusts' -> 'Requests' in Design Intent section
- Fixed Prettier formatting in SEP-2260 markdown file - Generated SEP documentation and updated docs index - Fixed missing closing backtick and typo in Abstract and Design Intent sections
- Remove trailing slash from ping#implementation-considerations link - Fix anchor reference for getting-logs-from-claude-desktop section
db2a164 to
a226dc4
Compare
This reverts commit a226dc4.
…specification into sep/unsolicitited-req
pcarleton
reviewed
Feb 18, 2026
pcarleton
reviewed
Feb 18, 2026
pcarleton
reviewed
Feb 18, 2026
Member
Author
|
I've made the wording consistent, and excluded Ping from the requirement. |
dsp-ant
reviewed
Feb 18, 2026
Member
dsp-ant
left a comment
There was a problem hiding this comment.
Thanks for putting this together. This looks very reasonable and a good clarification with little impact. I particularly appreciate the diligence in scanning existing servers.
markdroth
reviewed
Feb 19, 2026
9 tasks
evalstate
commented
Feb 27, 2026
Member
Author
evalstate
left a comment
There was a problem hiding this comment.
Would clients need to ensure the invariant holds true that requests cannot be? What is the recommended error handling here?
Error handling guidance added
CaitieM20
requested changes
Mar 10, 2026
This was referenced Apr 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
This PR tightens the scoping of Server to Client requests and to server as notice of upcoming changes where this pattern may not be supported by the underlying transport layer.
How Has This Been Tested?
This PR has been supported by research by @pja-ant on current (public) usage of this pattern.
Breaking Changes
Whilst a specification only change, this stops future use of "unsolicited" server-to-client requests in anticipation of future "stateless" transports.
Types of changes
Checklist
Additional context
This PR has previously been reviewed by the Transports Working Group here: modelcontextprotocol/transports-wg#8