MCP's Stateless Overhaul Turns AI Tool Calls from Phone Calls into Text Messages
MCP released a new version on July 28, 2026.
The most important change this time is just one thing: when AI calls a tool, it is no longer bound to the same server all the time.
In plain terms, the old MCP was like making a phone call you couldn't hang up.
The new version is more like sending a WeChat message.
Each time you make things clear, the other party can handle it upon receiving the message, without needing to remember which machine you chatted with last time.
This change transforms MCP from a locally convenient way to connect AI tools into something more suitable for cloud servers and company systems.
What does MCP do?
MCP can be understood as a set of universal rules for AI to use external tools.
For example, letting AI read code, query databases, organize documents, create projects, or manipulate design drafts.
These are usually not things the model can do itself, but rather the model calls external tools.
Previously, different AI software connected to different tools, often requiring custom interfaces for each.
MCP aims to unify the connection rules.
It's a bit like a USB interface.
As long as mice, keyboards, and USB drives all follow the same set of connection rules, the computer can use them together.
Why was the old version inconvenient for going online?
In the old MCP, the first time you used a tool, you had to establish a dedicated connection with the server.
Subsequent calls also needed to carry the credentials for this connection.
This was fine for local use.
But when the service was put on the cloud and multiple machines were spun up to share the load, trouble arose.
The AI had to ideally return to the same machine it first connected to.
If the machine changed, the new machine wouldn't know where the previous conversation had reached.
Scaling and failure recovery both became more troublesome.
If one machine broke down, users originally connected to it might have to start over.
How does the new version solve this?
The new version no longer requires maintaining a dedicated connection.
Each call carries the basic information needed to handle that specific task.
Therefore, any normal machine can take over the request.
| Past | Now |
|---|---|
| Establish a dedicated connection first | Directly state what needs to be done |
| Subsequent calls should ideally return to the original machine | Any normal machine can handle it |
| Must care for old connections when scaling | Can add servers like a normal website |
| A single machine failure has a greater impact | The next request can be handed to another machine |
When the service is busy, just spin up more machines.
If one of them has a problem, the next request is simply handed to another machine.
MCP services finally behave more like the websites and APIs we usually deploy.
What if a task is only half done?
If the server doesn't remember the previous content, what happens to a task that's only half done?
For example, if AI is importing a large file, it needs to know the progress later.
The new version's approach is to have the tool return a "claim ticket," which is a task ID.
Later, the AI brings this ID to ask, and the tool can find the corresponding task.
The task record belongs to the business itself and no longer depends on a specific server remembering you all the time.
Switch to another machine, and with the ID, you can still continue the task.
AI can ask you first, then continue execution
When AI calls a tool, either the information is insufficient, or the matter is too important and needs a human nod.
For example, when creating a project, the region and budget are not yet known, or a batch of data needs to be deleted, or a paid service needs to be activated.
The new version allows the tool to pause first and ask the user supplementary questions.
After the user answers, the AI carries the new information and continues the original operation.
AI: Help you create a service
↓
Tool: Need to confirm region and budget
↓
You: Shanghai, within 500 yuan per month
↓
AI: Continue creating
AI no longer only has two outcomes: direct execution and direct error.
It can also wait for human confirmation at key steps, making it more suitable for participating in real work.
Company systems can also manage AI more easily
It's convenient for AI to call company tools.
What the company cares more about is: what did it call, who allowed it to call, and can problems be traced if they occur.
The new version adds clearer labels to each request.
The company's existing security gateways, access controls, traffic limits, and operation logging systems can more easily identify which tool this request is about to call.
For example:
- Ordinary accounts cannot use tools that delete production data.
- High-cost tools can have their usage count limited individually.
- The call volume and cost of different tools can be counted separately.
- When problems occur, it's easier to trace who called what.
The new version also strengthens login authorization checks.
These changes are not flashy, but they determine whether MCP can move from a personal computer into a company's formal systems.
What other changes are there?
Tool lists, prompt lists, and resource lists could previously be requested repeatedly.
The new version allows the server to tell the AI: how long these contents don't need to be re-fetched.
This reduces the transmission of duplicate information and saves costs for both the server and the model.
Time-consuming tasks like batch file analysis, report exporting, and video generation can also be submitted first, with progress and results checked later.
Some old features and old connection methods have already begun to be phased out.
However, the official commitment is to retain at least a 12-month transition period.
Teams already using the old MCP don't need to tear everything down and start over immediately, but they can begin to inventory which parts still depend on the old connection method.
Why is this update worth paying attention to?
Commonly used SDKs for TypeScript, Python, Go, and C# already support the new version.
Platforms and tool services like AWS, Microsoft, Cloudflare, Google Cloud, as well as Figma and Supabase, are also following suit.
What they value is not just whether AI can call a tool.
More importantly, it's whether the tool can run stably on the cloud, whether it can integrate into existing permission and security systems, and whether problems can be investigated afterward.
Previously, MCP solved how AI could reach external tools.
Now, it's starting to solve how, after AI reaches the tools, things can be done safely and stably.
For ordinary people, this means seeing more AI operate real software and work systems for you in the future.
For developers, when making MCP tools, they should also think according to the standards of online services.
Not only consider whether the tool can run, but also whether it can scale, whether it can be managed, and how to recover if problems occur.
Thank you for reading. I am Chen Suiyi, the Tiger of Frontend. Public account 陈随易, personal website: https://chensuiyi.me.