Design SDK changes for stateless & sessionless MCP#919
Conversation
|
Hi @yarolegovich, @guglielmo-san, @jba, I have a draft of the first part of the design for stateless/sessionless MCP that's coming in the next spec version. It's focused on the connection establishment logic. PTAL if you're interested and let me know if you have any feedback. |
| New types in `protocol.go`: | ||
|
|
||
| ```go | ||
| const ErrCodeUnsupportedProtocolVersion = -32602 // INVALID_PARAMS per SEP-2575 |
There was a problem hiding this comment.
asked for a dedicated code modelcontextprotocol/modelcontextprotocol#2575 (comment)
| `resource/unsubscribe` when `>= 2026-06-30`. | ||
|
|
||
| > [!WARNING] | ||
| > Deprecated APIs: |
There was a problem hiding this comment.
how long are we going to keep them deprecated and will the new subscriptions/listen method fallback to old-protocol version RPCs?
if the answer to the latter is negative, as an MCP client developer I'm kind of incentivised to keep using ClientSession.Subscribe() and ClientSession.Unsubscribe() APIs, because this way I write the same code for old and new servers
There was a problem hiding this comment.
Our only way to remove deprecated APIs is to release v2. But I hear your argument, maybe it's actually better to hold off with making them deprecated until we have designed how the replacement would look like in v2 and backport it to v1. Deprecation without suggested replacement may not be received well.
There was a problem hiding this comment.
I don't think we can deprecate anything that can still be used in stateful mode: those protocol versions still exist, and may for some time (especially for stdio transports).
Perhaps in the package doc or README, we can suggest that stateless mode is recommended for remote servers because it is more scalable.
v2 will "solve" this problem because it will be all stateless. We'll just need one line in the doc that says to use v1 if you want state.
maciej-kisiel
changed the title
|
|
||
| Session objects (`ServerSession`/`ClientSession`) are the core part of the Go MCP SDK API. | ||
| They are returned from `Connect` functions and they are used to interact with the peer. | ||
| Even though SEP-2567 removes the concept of sessions from the protocol, we cannot simply remove |
There was a problem hiding this comment.
OK, at this point I concluded that it sounds like time to move to v2. It will dramatically simplify both the code and the API.
Normally the downsides of a v2 are:
- it's a challenge to make people aware that it exists
- users have to endure the pain of upgrading, or missing out on new features
I think those are mitigated here. No one who reads those SEPs will be surprised that our SDK (and surely others?) will do a major version bump. It will be easy to advertise, via the README in the repo, other MCP documentation about SDKs, and a doc comment on StreamableHTTPOptions.Stateless. And here it's not so much about getting some new features: it's basically a totally new protocol that a server author will either switch to completely, or not.
One downside is maintaining two separate pieces of code. But AFAICT if we put this into v1 we would basically be forking a lot of the code anyway. We can still have a lot of common code by moving it to internal. Common API can be shared in many cases by making aliases in v1 to the v2 types, and wrapping v1 functions around v2 functions, as we recommend in these cases.
Am I missing something?
There was a problem hiding this comment.
OK, you want to hold off on v2 for pluggable transports. I withdraw my comment.
jba
left a comment
jba
left a comment
There was a problem hiding this comment.
After a high-level reading, I have no comments. This seems like a reasonable path forward.
|
|
||
| Session objects (`ServerSession`/`ClientSession`) are the core part of the Go MCP SDK API. | ||
| They are returned from `Connect` functions and they are used to interact with the peer. | ||
| Even though SEP-2567 removes the concept of sessions from the protocol, we cannot simply remove |
There was a problem hiding this comment.
OK, you want to hold off on v2 for pluggable transports. I withdraw my comment.
3 participants
No description provided.