MCP clients and cookie jars #1468
Replies: 3 comments 20 replies
-
|
I should note that I'm making an assumption here: If all access to MCP servers are authenticated (ie, I have a user identity), I can build my own server-side storage, keyed by the user identity. However, I'm assuming that there will exist at least some uses cases where there will be MCP servers that expose tools that aren't behind authentication/authorization. In those cases, you have standard abuse problems (scraping, spam, etc), and would want primitives to build rate-limiting, reputation, etc. Agent-side storage is useful for that. |
Beta Was this translation helpful? Give feedback.
-
|
I think @jonathanhefner has brought this up earlier as well. This would also complement #1442 perfectly. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think anyone is working on a proposal currently, so feel free to do so! Note, though, that I don't speak for the core maintainers, so I cannot guarantee whether such a proposal would be accepted. But I agree it would be useful, and I have seen it repeatedly brought up. |
Beta Was this translation helpful? Give feedback.
-
|
Happy to participate. I'd love it if there was some more input to help clarify use cases. I know what I need something like this to do, but my needs (anti-abuse) not be the same as everyone else. |
Beta Was this translation helpful? Give feedback.
-
|
Chris, are you on the contributors discord? We can start by putting some initial ideas down first and then getting more feedback from the others. |
Beta Was this translation helpful? Give feedback.
-
|
No, I'm not on the discord, as I've only been engaging via issues and discussions. Happy to join if it's open access and you can point at it. |
Beta Was this translation helpful? Give feedback.
-
|
@chhamilton There is a link here: https://modelcontextprotocol.io/community/communication#discord 😃 |
Beta Was this translation helpful? Give feedback.
-
|
Was thinking about this earlier today, and I wanted to offer a design: Define a special The prefix is bikesheddable. Some alternatives: We could then extend the concept to a full-on cookie-like mechanism with additional key prefixes like |
Beta Was this translation helpful? Give feedback.
-
|
I also brought up TTLs earlier and thinking more about it, I think I do agree with @jonathanhefner that request and session scopes are already well-defined so they don't need TTLs. If we do want to support global state, and it seems like it's a strong requirement for @chhamilton and @mcorner, then some optional TTL mechanism for it seems important for it. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, great discussion. I am totally fine with the implicit approach, I will rework the proposal. I am not wed to the mechanism I proposed and I definitely see how it can be viewed as too explicit and therefore too much work to use. We do want to have state that outlives the session. This is really crucial from an anti-abuse perspective at least. TTLs are very useful to have some guarantees on the bounds of state set to help automatically comply with any requirements on "forgetting" state, be it regulatory or internal policies. Stay tuned, I don't think it will take too long to rework and then I can turn it into a SEP. |
Beta Was this translation helpful? Give feedback.
-
|
I have made a bunch of updates to the doc to adopt this implicit approach. The biggest outstanding question ATM is if we should elevate the State out of the namespaced _meta properties and into a first class property and interface. Personally I am in favor of encoding the structure in the schema, but wdyt? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @jonathanhefner for all the comments. I will move what we have now to a real SEP and we can iterate from there. There are a bunch of alternatives listed that may elicit some comments from others that would provide more justification for their inclusion. |
Beta Was this translation helpful? Give feedback.
-
|
The SEP is now here: #1655 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
Discussion Topic
It doesn't appear as if the MCP specification dictates what MCP clients should do with cookies, and what properties of cookies MCP servers can rely on. That is, should the client support a cookie jar, and if so, should it be ephemeral (session lifetime), or persistent, and if it's persistent, what scope should the storage have?
I'm asking because I operate a security service. We make extensive use of cookies on the web platform. We are building a similar security service that deploys as an MCP proxy, and it would be useful for us to have some type of "agent-side storage". We'd love to be able to rely on cookies for that purpose. This would allow us to remember key facts about a particular agent (ideally bound/scoped to the account of the user owning the particular agent instance, and persistent) if it comes back in the future for additional interactions. Having this storage would mean we'd use elicitation less often (we plan on building step-up auth mechanisms based on secure OOB elicitation).
I'm curious about opinions, and potential other use cases. And anecdotally, whether or not agent-developers are supporting cookies in their MCP clients.
Beta Was this translation helpful? Give feedback.
All reactions