Model Context Protocol was the big AI development of 2025. It includes a lot of architectural baggage from when it was created and what people were trying to solve at the time. It’s going to evolve or be replaced for sure. But I think the biggest change will be that it will go stateless.
MCP made its first big strides as a way for developers to control the context information fed into LLMs. It’s a way to manage that all important context as a module that isn’t deployed with the LLM. It centered around communicating on one local host, because that’s how developers were creating, testing, and finally deploying applications. It gave dynamic and online ways to manage context that replaced some of what RAG, LangChain, and a lot of custom code was doing.
Most importantly, MCP provides a way to leverage the new technique all the model developers were adding: tool use. The previous architectures had programmers making decisions about the context information. Tool use puts that decision in the hands of the AI model, allowing it to request the context it needs. And the protocol arrived on the scene about the same time tool use started working.
Even MCP wasn’t ready to give all control over to a tool using model. The design was made by the programmers who had been working on controlling context information for years. And so the MCP server retains a lot of control. It does this by making a bidirectional connection from the client to server. The local connections handled this naturally. On the network they relied on HTTP SSE, which is a specialized and not quite popular protocol. SSE is useful for real time updates. This server controlled connection was seen as desirable to developers who wanted to update a context window very quickly. The protocol choice is currently being changed to HTTP Streaming, which is similar and just a little bit more common to see in other applications.
I think this will change. And here’s where they’re working on it. https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1442
State is difficult to handle in software even when it’s known and designed into the system. Sometimes it’s just easier to outlaw any state changes in your architecture. For example, REST is an API style where requests are inherently stateless. Many applications and websites are designed around using that stateless protocol. And those applications work great! In fact they’re easier to develop, easier to test, and so should contain less bugs than similar applications using stateful protocols. Stateless applications can be deployed to a serverless runtime, which lowers development costs and for smaller applications can very significantly lower the cost of running a service.
MCP designated resources, prompts, and tools as the services provided. The server retains some control over all of these even though the AI is operating the client side. The server can provide information about changes without the client even asking about them.
Alternatively, skills have similar goals of retrieving data and making changes, but are entirely serverless. Skills are just the instructions, rather than designing any protocol at all. Where to get the skills has been a more lawless area. And while there is a lot about skills are for instructions and workflows and MCP is about searching and actions, there’s really a lot of gray area where either works.
As tool use gets better we can rely on the AIs more and more to orchestrate the entire workflow of discovery of resources and managing its own context window. This means the control the server was keeping just isn’t helping as much. Then calls to the server can follow a more stateless architecture, supplying the protocol new advantages of simplicity and cost savings. And that’s why I think stateless MCP is coming and is going to be most of the MCP ecosystem.









