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.