feat: add SEP-1685 revisions proposal

[gjz22]

Summary

This proposal adds an optional state field to both ServerRequest and ServerResponse messages in the Model Context Protocol (MCP). This enables servers to implement stateless request flows, eliminating the requirement for durable state storage and significantly reducing operational complexity and cost.

Key Points

• Primary motivation: elicitation requests in remote MCP servers where response times are unbounded (seconds to hours)
• Enables stateless server implementations by allowing servers to encode context in the state field
• Supports multi-round-trip interactions without server-side storage
• Backward compatible: the state field is optional

[markdroth]

Thanks for writing this up!

I think we'll probably want to integrate this into #12 instead of having it be a separate SEP. But let's first come to consensus on how we want the state field to be represented.

[markdroth]

I think you mean ClientResult rather than ServerResponse:

https://github.com/modelcontextprotocol/modelcontextprotocol/blob/a0856fb02f1b1c9245768929cad7191b2f6698a3/schema/2025-11-25/schema.ts#L2537

I made the same mistake in the MRTR SEP, and Catie fixed it. :)

[markdroth]

I would actually move it up to be a top-level field, not inside of the "dependent_requests" field. I think this is actually a separate (albeit synergistic) mechanism from dependent requests, and I could easily imagine cases where a server sends an incomplete request with state but without any dependent requests as a mechanism for shedding load from an individual server instance.

[markdroth]

I don't really understand what "more flexible" means here. What does this option allow a server to do that it can't do with option 1?

From my perspective, there are two separate things going on here, and I don't think we want to conflate them:

1. How does the server pass state through the client to a subsequent request?
2. How does the protocol identify individual dependent requests when it sees the responses?

I think that for (2), we want a very simple mechanism that ensures uniqueness, which is why #12 proposes using a map with simple string keys. I think that solves the problem in a simple and unambiguous way that is very easy for clients and servers to implement. I think that making the key something more complex than a string will make this harder to understand and harder to implement, and it does not provide enough benefit to be worth that trade-off.

For (1), I can't think of any case where the state will actually be associated with individual dependent requests. The two use-cases I can see here are the following:

• A server first asks for X, then when it gets X, it asks for Y. In the request for Y, it will want to encode X in the state field, so that it does not need to ask for X again. Note that in this case, X and Y are totally independent requests, so storing the result of X in state associated with Y doesn't make any sense semantically.
• A server may not actually need to ask for any info, but the server instance may need to shed load in the middle of processing a client-initiated request. It can do this by encoding its current state in the state field and sending an incomplete response, so that the client will try again and the load balancers can send the request to a different server instance. In this case, the server's incomplete response does not have any dependent requests, so there's no dependent request to associate the state with.

Are there other use cases here that I'm not thinking of in which the state will actually be associated with an individual dependent request?

[CaitieM20]

This has been incorporated into #12