Stateless MCP

Why this conversation

An agent is only as useful as the tools it can reach, and the Model Context Protocol is how many of them reach those tools. On the second day of AGNTCon + MCPCon Europe in Amsterdam, Shaun Smith had presented in the MCP keynotes, on stateless MCP in production. Later that morning the host asked Shaun to walk through the highlights of that work for the foundation. The story of that week is in AGNTCon + MCPCon Europe 2026: who we met.

A protocol without sessions

Shaun is one of the MCP maintainers, and had recently been involved in the latest protocol release, which includes the stateless MCP version: “removing the session handshakes, making it cacheable”, along with other general changes that make MCP easier to deploy for big customers.

The host remembered getting their hands dirty with the previous iteration, which was a little complicated to get started. Shaun’s answer is that it depends on the server. If all a server does is very simple, it may never meet the challenges of scaling. A server that maintains any kind of state, or one that uses advanced features such as elicitations, can stumble into a number of problems, and the protocol carried quite a lot of overhead. Now there are options: run a very lightweight, simple server, and scale up the complexity as needed.

Elicitations on any node

Elicitations are a way for a server to ask the end user, usually the human, a question. They travel out of band: they are meant for the human to see, not the model. In the previous version of the protocol, the server had to remember which questions it had asked to which clients. In a horizontally scaled environment that meant sending the traffic back to the same server, or building very complicated shared state mechanisms.

In the new version, when the server wants a user’s response to an elicitation, it sends the question back to the client. The client then answers with both the question that was asked and the answer. Any server node can reconstruct the response as if it were fresh, so it scales and does not suffer from the timeout and robustness issues the previous version was prone to.

Assembling the pieces

The host pointed to the layers piling up around an agent, from the model and the prompts to the harness and its tools, and asked how the system will evolve. For Shaun, “ultimately it’s the job of the integrator, of the agentic engineer to assemble these things correctly.” There are many new ways to do that. Tool search and programmatic tool calling extend what an agent or a chat application can do without loading the context of everything at once. The trade-off is that the tools then have to be discoverable. One of the good things about MCP, Shaun says, is that the tools are self-describing for the model, and each has a title that tells the user what is going on. It is still an integration job, but there are now enough options to use pretty much any pattern.

Start with less, then measure

On best practices, Shaun points to an emerging theme in the industry: the importance of good evaluations and benchmarks. Some are open and very accessible, Terminal Bench among them, and without such evaluations it is very difficult to say whether one thing is better than another. Shaun is keen to make benchmarking and evaluation far more accessible, so that people can check, for example, whether the files and skills they give an agent still help when a new model comes out.

How much context does an agent need? Shaun’s general principle is that as models evolve, “the right answer is usually to start with less and only add more where you see the model struggling.” Some techniques that made sense six to nine months ago to guide a model now get in the way: nothing breaks, but things work less efficiently than they could. The point is to understand which interventions are sensible, “the fewer, the better, which is why we test and we evaluate.” Otherwise teams end up building layers on layers and probably lowering performance overall.

Twice a year, and how to join

MCP is moving to a twice-yearly cadence: a release every six months, with a two-month overlap window to prepare new roadmaps and get new specification versions out. Shaun expects the next release to keep enhancing the protocol, though probably not as big a jump as this one. The host added that a predictable cadence helps organisations plan their deployments, and that WebMCP is booming. Shaun’s view: “anything which helps automate and make things more discoverable for agents is a good thing.”

To get involved with the working group, Shaun suggests visiting modelcontextprotocol.io, joining the Discord, looking at the GitHub repository, asking questions, and finding the maintainers who work in your area of interest to share ideas with them.

When it comes out

The episode is edited and in the release order. Like every episode it goes out on YouTube first, then on Apple Podcasts, Spotify and Amazon Music.