SEP-XXXX: Require Server-to-client requests to be associated with Client requests#8
Closed
evalstate wants to merge 18 commits intomodelcontextprotocol:mainfrom
Closed
SEP-XXXX: Require Server-to-client requests to be associated with Client requests#8evalstate wants to merge 18 commits intomodelcontextprotocol:mainfrom
evalstate wants to merge 18 commits intomodelcontextprotocol:mainfrom
Conversation
This text has been created with assistance of LLMs, but hand reviewed and edited.
kurtisvg
previously approved these changes
Feb 10, 2026
CaitieM20
requested changes
Feb 11, 2026
Contributor
CaitieM20
left a comment
There was a problem hiding this comment.
My Vote: Approved with suggestions!
mikekistler
reviewed
Feb 11, 2026
mikekistler
reviewed
Feb 11, 2026
mikekistler
reviewed
Feb 11, 2026
mikekistler
reviewed
Feb 11, 2026
| Servers **MUST** send `sampling/createMessage` requests only in association with an originating client request (e.g., during `tools/call`, `resources/read`, or `prompts/get` processing). | ||
|
|
||
| Standalone server-initiated sampling on independent communication streams (unrelated to any client request) is not supported and **MUST NOT** be implemented. Future transport implementations are not required to support this pattern. | ||
|
|
There was a problem hiding this comment.
It seems like what we are really saying with this SEP is that the fundamental communication model is changing from bidirectional to client-initiated request/response. Should we just come out and say that?
Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
Co-authored-by: Caitie McCaffrey <caitiem20@github.com>
…rts-wg into feat/sep-draft
kurtisvg
reviewed
Feb 13, 2026
kurtisvg
previously approved these changes
Feb 13, 2026
mikekistler
approved these changes
Feb 13, 2026
mikekistler
left a comment
There was a problem hiding this comment.
I recommended a few more changes, but nothing I would let block the review with the core maintainers.
Comment on lines
+49
to
+56
| ### Simplification Benefits | ||
|
|
||
| Making this constraint explicit: | ||
|
|
||
| 1. **Simplifies transport implementations** - Transports don't need to support arbitrary server-initiated request/response flows, which require a persistent connection from Server to Client; they only need request-scoped bidirectional communication | ||
| 2. **Clarifies user experience** - Users understand that sampling/elicitation happens *because* they initiated an action, not spontaneously | ||
| 3. **Reduces security surface** - Ensures client has context for what scope the additional requested information will be used for. This allows clients to make better informed decisions on whether to provide the requested info. | ||
| 4. **Aligns with practice** - Based on a scan of GitHub all existing implementations already follow this pattern, except one repo owned by the SEP author with a contrived scenario. |
There was a problem hiding this comment.
I think this should be the first, and maybe the only, section within Motivation, as I believe the reasons listed here are the most objective and compelling reasons for this change. Reasons given in other sections are subjective and open to debate. We should put the strongest reasoning first.
Member
Author
There was a problem hiding this comment.
Agreed. I'll leave the other text here for the moment as it contains links/context but appreciate that the proposal is stronger without.
| + The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the | ||
| + JSON-RPC _response_. These messages **SHOULD** relate to the originating client | ||
| + _request_. In particular, `sampling/createMessage` and `elicitation/create` | ||
| + requests **MUST** only be sent in this context (associated with a client request). |
There was a problem hiding this comment.
I don't think we need this change. The goal of the SEP is to discourage unsolicited server-to-client requests. Let's keep the scope to that.
Contributor
There was a problem hiding this comment.
If we do keep this, let's also mention roots.
markdroth
approved these changes
Feb 13, 2026
Contributor
markdroth
left a comment
There was a problem hiding this comment.
This looks really good to me! Just a few minor comments.
| + The server **MAY** send JSON-RPC _requests_ and _notifications_ before sending the | ||
| + JSON-RPC _response_. These messages **SHOULD** relate to the originating client | ||
| + _request_. In particular, `sampling/createMessage` and `elicitation/create` | ||
| + requests **MUST** only be sent in this context (associated with a client request). |
Contributor
There was a problem hiding this comment.
If we do keep this, let's also mention roots.
Co-authored-by: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com>
Co-authored-by: Mike Kistler <mikekistler@microsoft.com>
Co-authored-by: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com>
evalstate
added a commit
to evalstate/modelcontextprotocol
that referenced
this pull request
Feb 16, 2026
9 tasks
evalstate
added a commit
to evalstate/modelcontextprotocol
that referenced
this pull request
Feb 18, 2026
Contributor
|
Closing since this has moved to official SEP: (modelcontextprotocol/modelcontextprotocol#2260) |
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.
Draft proposal for deprecating Sampling and Elicitation.
Motivation and Context
Simplify future transport implementations, tighten existing text as although it works, various parts of the specification allude to this not being desirable (e.g.
nested).How Has This Been Tested?
Breaking Changes
Yes - but scope has been researched and found to be limited so far. One purpose of this SEP is to collect feedback from potentially impacted users we are not aware of.
Types of changes
Checklist
Additional context
For discussion at Transport W-G. The aim is to release new transport versions in H2. This SEP does not intend to change the specification, but serve as notice of intent. Wording changes can be proposed if timelines change.