In July 2026, the official MCP specification received a textbook-grade update: the core protocol moved to a Stateless architecture and officially supports Multi Round-Trip. On the surface it's just a version bump, but in practice these two terms rewrite how MCP Servers are deployed, scaled, and even monetized.
If you maintain an MCP Server today—or plan to build one—this piece is worth reading to the end. I'll "translate" the new spec into developer-friendly language and explain why it matters.
1. Stateless: From "Stateful Long Connection" to "Stateless Request"
Recall how the old MCP worked by default: the client and Server established a stateful long-lived connection (usually stdio or session-bound HTTP). For the lifetime of the session, the Server held all the context in memory—who you are, which tool you just called, what the intermediate results were.
This caused three classic pain points:
- Hard to scale horizontally: session state lived on a single machine's memory, so load balancing required sticky sessions, which broke down as traffic grew.
- Wasted resources: idle connections still consumed resources, making Serverless essentially off the table.
- Complex failure handling: when the Server restarted, all session state went to zero and every client had to reconnect.
The new spec changes the core protocol to Stateless: each request is self-contained, carrying all the information it needs; the Server no longer keeps session state. Process and forget—next time, the request comes back with the full context.
Stateful: connect → session state lives in Server memory → disconnect = amnesia
Stateless: every request is self-contained → scale freely, restart freely, load balance freely
The architecture philosophy here is the same lineage as HTTP/REST—the global Web runs on the stateless request-response model. With this step, MCP finally becomes truly "cloud-native."
2. Multi Round-Trip: Conversations Are No Longer "One-Shot"
The second change: Multi Round-Trip support.
Tool calls used to be essentially one-directional: the client issues tools/call, the Server returns the result, done. But real tasks are often multi-turn—take booking a hotel: search first, then check room details, then confirm live pricing, and only then create the order.
Under the old protocol, these steps either had to be orchestrated by the client itself, or crammed into a single call with parameters piling up.
The new spec allows the Server and client to make multiple round-trips within a single task: the Server can return intermediate results step by step, and can even ask the client for missing information (e.g. "How many guests?"), breaking complex flows into a natural conversational rhythm.
The impact on developers is direct: you can finally model a complex business flow (like the full hotel booking chain) as a natural, multi-step MCP interaction, instead of designing a bunch of fragmented tools and letting the client glue them together.
3. Who Does This Update Actually Change?
Teams Running Their Own MCP Servers
Migrate early.
Move state out to Redis / a database, and make endpoints self-contained. Once done, you'll see ops costs drop off a cliff—scaling no longer requires session migration, and releases no longer wait for connections to drain.
Stateless covered—now let's look at a concrete sample. Digging into it lets us land all the architectural features above.
Positioning First
RollingGo is a dual hotel+flight MCP Server: it packages global hotel inventory and flight capabilities into a standard MCP-tool "travel data layer"—2M+ global hotels, 110k direct-contracted hotels with real-time inventory, aggregating availability and rates from 500+ suppliers.
When a model calls it, what it gets back isn't a pile of web pages needing secondary scraping, but structured, bookable results.
The key is free with no call-volume limits—something uniquely rare in China's MCP ecosystem.
Hosted MCP Services: The Biggest Winners
Stateless is a natural fit for Serverless billing and auto-scaling.
Look at the numbers from China's ModelScope community to see how fast this path is being validated: RollingGo's hotel MCP, hosted on ModelScope, has already racked up 1.6M calls and #7 on the trending list—a hotel aggregation MCP hitting that call volume proves the stateless hosted model works for the "small team, big traffic" combination.
To complete the picture: RollingGo is a dual hotel+flight MCP where one free key covers 2M+ global hotels (110k direct-contracted, real-time inventory), aggregates 500+ suppliers, is compatible with 40+ mainstream AI clients, and has been integrated by 2,000+ Agents—used in cultural tourism, AI glasses, trip-planning apps, and more.
Try the hosted version directly:
RollingGo Hotel MCP on ModelScope
How to Connect
It's streamable-HTTP direct—no dependencies to install, no local process to run.
Just add a JSON block to your client's MCP config, using RollingGo-Hotel as the example:
{
"mcpServers": {
"RollingGo-Hotel": {
"url": "https://mcp.rollinggo.cn/mcp",
"type": "streamable-http",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}
Swap YOUR_API_KEY for a free key from the official site, save and restart, and your model's tool list now includes the full suite of hotel search, pricing, details, and booking—from query to reservation, zero glue code.
Where It Plugs In
The universality of this configuration is MCP's universality:
Claude Code, Cursor, Windsurf, GitHub Copilot, Antigravity, Kiro, Codex, OpenCode, Trae, Manus, Qoder—every major coding client is covered.
Coze, Cherry Studio and other Agent platforms have custom MCP entries where the same JSON works.
Same Server, same JSON, same set of tools wherever you run it.
Who's Using It
2,000+ Agents have already integrated it—local cultural tourism bureaus, AI earbuds, AI glasses, trip-planning apps, and thousands of developers have requested keys.
AI Application Developers
The good news is most of this is transparent to you—the client handles the protocol details.
But you should start paying attention to Servers that support multi-round-trip—they deliver noticeably better interaction, especially on multi-step flows like checkout and payment.
4. Migration Pitfalls to Watch For
If you start upgrading now, three pitfalls are worth flagging up front:
1. Don't Confuse "Stateless" With "No Context"
Context still exists—it's just carried by the client on each request (or stored externally).
When designing the payload, think clearly about what information must be self-contained.
2. Idempotence Matters More
Under a stateless architecture, retries are more common.
Every write operation must be designed with an idempotency key, or duplicate orders in multi-round-trip flows can quickly become incidents.
3. Long-Running Tasks Need Redesign
Work that used to be "held open" by a long connection now has to be split into multiple round-trips or converted to async callbacks.
In one sentence:
Stateless turns MCP from "a sidecar process for one client" into "an elastically scalable cloud service," and Multi Round-Trip turns it from "a one-shot function call" into "an interaction protocol that can run an entire business flow."
Together, they complete the last puzzle piece of MCP as infrastructure.
5. Appendix: Old vs. New Spec Cheat Sheet
The core changes condensed into a table—glance at it before upgrading:
| Dimension | Old spec | 2026 new spec | What it means for you |
|---|---|---|---|
| Session state | Server holds long-connection state | Core protocol is Stateless | Scaling, restarts, fault tolerance all simplified |
| Request model | Primarily single call | Multi Round-Trip | Complex flows can be broken into natural turns |
| Deployment | Tethered to client process | Cloud-native / Serverless-friendly | Hosted services become the mainstream shape |
| Load balancing | Sticky sessions required | No stickiness needed | Add machines freely |
| Failure handling | Disconnect = amnesia | Self-contained, replayable requests | Idempotent design becomes mandatory |
Two easily missed details:
First, after stateless-ification, the context in each request grows—watch your payload design; don't stuff the entire conversation history into every call.
Second, the official migration guide emphasizes backward compatibility—old clients connecting to new Servers work in most scenarios, but multi-round-trip tools will degrade to single-turn on old clients.
Plan for that degradation path in your tool design.
Has your MCP service upgraded? Hit any pitfalls? Drop your migration story in the comments—I'll consolidate the typical issues into the next piece.
Top comments (0)