SEP-2260 Require Server requests to be associated with a Client request.#2260
Conversation
|
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. |
…-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
|
I've made the wording consistent, and excluded Ping from the requirement. |
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
|
Can I pull a user query from the client prior to the LLM call with this SEP? My problem I want to fix:
As a result, when multiple sessions or subagents require different tool sets, there is no reliable way to target notifications/tools/list_changed to a specific agent session. The same agent instance may therefore expose inconsistent tools across concurrent contexts. This makes dynamic tool manipulation difficult in real-world agent environments. |
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