MCP Just Got Boring, and That Is Good News
The new Model Context Protocol spec is mostly about plumbing, which is exactly what you want from a standard your company is starting to depend on.
The Model Context Protocol released a new version of its specification, dated 2026-07-28. If you write code, there is a migration guide waiting for you. If you sign purchase orders instead, you might still want to read on, because this release says something useful about where the "let AI talk to our data" category is heading.
Short version: the exciting part of MCP is over. The plumbing part has started. That is the good phase.
First, what MCP actually is
MCP is a standard way for an AI assistant to reach a tool or a data source. Before it existed, every combination of assistant and system needed its own custom bridge. With it, a system exposes its capabilities once, and any client that speaks the protocol can use them.
Think of it as the USB-C of this space. Nobody gets excited about a connector. Everybody notices when there isn't one.
The adoption numbers in the release post are the kind of thing I usually distrust, but they are worth a glance: the official SDKs are seeing close to half a billion downloads a month, and the TypeScript and Python ones have each passed a billion downloads in total. Whatever else you think about the AI market, this particular plug has been chosen.
The headline change: the protocol forgot how to remember
The biggest change is that MCP no longer keeps a session open between client and server. Previously, a conversation started with a handshake, got a session ID, and continued inside that session. Now every request stands on its own and carries what it needs.
The restaurant version: the old model was a waiter assigned to your table who remembers what you ordered. The new model is a counter where you hand over a written order each time. Less charming, far easier to staff.
Why anyone outside engineering should care:
- Restarts stop being events. If a server process dies and comes back, there is no session to lose. The next request simply lands somewhere and works.
- Scaling gets dumb, in the good sense. Requests can go to any instance behind an ordinary load balancer. No shared session storage, no sticky routing, no clever infrastructure that only one person understands.
- Fewer long-lived connections. The old design wanted a stream held open between the two sides. Networks, proxies and firewalls dislike that. Corporate networks especially dislike that.
Operations teams have been asking for this. It is the difference between a demo that works on a laptop and something you are willing to leave running in a factory over a weekend.
Asking the user a question, without holding the line open
Sometimes a tool needs something back from the person: a confirmation, a missing parameter, a choice between two plants with similar names. Under the old design that meant the server called back to the client over the open connection.
The new mechanism is called Multi Round-Trip Requests, and it works the way a good form does. The server answers with "I need input" and lists what it needs. The client collects the answers and sends the original request again with those answers attached.
The capability survived. The requirement for a permanently open channel did not. That is the pattern for this whole release.
Routing information moved to the outside of the envelope
Requests now have to state which method and which tool they are calling in HTTP headers, not just inside the message body.
Small change, real consequence. A gateway, firewall or rate limiter can now see what is being asked without opening the payload. Which means your existing network policy tooling can make decisions about AI traffic the same way it does about everything else. Security review, meet a normal request you already know how to inspect.
Alongside that, catalogs of available tools and resources can now be cached, with the server saying how long the answer stays fresh. Less repeated chatter, more predictable behaviour.
Authorization: less invention, more OAuth
The release notes say authorization is where implementers spend most of their integration time. That matches my experience, and it matches almost every enterprise integration I have ever done.
This version tightens things: authorization servers should identify themselves in a way clients are required to verify, credentials are bound to the server that issued them and cannot be reused elsewhere, and the awkward case of desktop and command line apps redirecting to localhost is properly handled. Dynamic Client Registration, an approach that made a lot of security architects uneasy, is now formally on the way out in favour of client metadata documents.
The direction is clear. Fewer MCP-specific inventions, more alignment with OAuth as it is already deployed and already audited. When your identity team asks what this protocol does about authentication, the honest answer is becoming "mostly the same thing your other systems do", and that is the answer you want.
The change I like most is a calendar
MCP now has a formal deprecation policy with a minimum twelve month window. A few older features, including the legacy transport, are deprecated under exactly that rule. They keep working for at least a year.
This is the least glamorous item in the release and the most important one for anyone buying software. It converts upgrades from surprises into plannable work. It is also a signal about maturity: projects that publish a deprecation policy expect to still be around when the clock runs out.
The release, in one table
| The change | What it means if you buy software |
|---|---|
| Requests no longer need a session | Restarts stop being events, and it scales on ordinary infrastructure |
| Multi Round-Trip Requests | The assistant can ask for a confirmation without holding a line open |
| Routing details moved into HTTP headers | Firewalls and gateways can govern AI traffic like any other traffic |
| Tool and resource lists can be cached | Less repeated chatter, more predictable behaviour |
| Authorization moved closer to plain OAuth | Authentication your security team already knows how to audit |
| A twelve month deprecation policy | Upgrades become planned work instead of surprises |
Why this matters for IoT Data Flow
IoT Data Flow speaks MCP. It sits next to your databases, connects read-only, and lets people ask questions in plain language instead of waiting for a report. The software comes to your data, not the other way around.
That design and this release point in the same direction. A single-tenant box in a customer environment does not want a protocol that depends on held-open streams, hidden session state and bespoke authentication. It wants requests that stand alone, restarts that go unnoticed, traffic that a corporate network recognises, and authorization built from parts the security team has already approved.
There is migration work here, and I am not going to pretend otherwise. Anything that leaned on session identifiers has to be rethought. That is real effort, and the spec authors say as much.
Still, I would rather pay a migration cost toward a simpler protocol than keep building on a complicated one. The interesting phase of a standard is when it does new things. The valuable phase is when it stops surprising you. MCP just moved from the first to the second, and I think that is worth noting.