Comment by dend
20 hours ago
Hey - one of the lead maintainers of the MCP project here. There are a lot of scenarios where this simply won't scale (both from a usability and security standpoint). Cookies were made for the browser. MCP servers and clients often operate in environments where that is not a guarantee.
I've been working on an MCP for creating semi-deterministic flows in Claude code (essentially skills, but broken down into pieces). In order to track execution and state, I have the LLM pass the MCP a unique "execution id" with every call. This lets me programmatically step it through skills and know exactly where execution progress is.
I've been considering a similar approach for the web. Essentially, do a short-lived, one-time use token exchange for every single call back and forth.
* LLM: "I'd like to interact with your site"
* Site: "Great, here's first token. I will exchange it for a new one on the next call. Do not share with with another site. You can authenticate in your browser with this link: [example.com]"
* Then you can go back and forth.
It'd be rather annoying to auth in the browser every time, but it would enable a low-touch flow.
Long term, it'd be ideal to have some sort of out-of-band credential store/tool available, but this would start proving the concept out. Don't use it for highly sensitive stuff, but it would enable a lot of agentic flows that are currently blocked by high-lift MCP setup.
Agree.
Many times what the server returns is dictated by what kind of client software a user is using. Cookies are obviously used by browser based clients, with full browser capabilities. MCP doesn't have those capabilities. How will the server know what to return?
I have separated handling for token based calls vs cookie based in my non-mcp projects.. because it suffers from the same issue.
Most of the endpoints, assuming the client talks to server using api's, work fine with cookies, some, do not.