The internet has a shape that network engineers draw as an hourglass. Enormous variety at the top — every application anyone ever wrote. Enormous variety at the bottom — every physical medium, from fibre to radio to copper. And in the middle, one narrow, unglamorous, universally agreed layer that everything must pass through. They call it the thin waist, and for decades it has been the Internet Protocol.
The waist is where the leverage in a system quietly accumulates, and it accumulates precisely because the waist is boring. Nobody sells IP. Everyone depends on it. Whatever occupies that position stops being a product and becomes a fact about the world, and the interesting economics move to the layers above and below it.
I think we have just watched an agent-tooling waist form, faster than these things usually happen, and the two events that tell you so are a governance decision and a changelog.
The tell was giving it away
On 9 December 2025, Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI. The platinum member list is the striking part: Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. MCP joined Block's goose and OpenAI's AGENTS.md as founding projects, with more than ten thousand active public servers already in the wild.1
Read that as an economic signal rather than a press release. A protocol you own is a product. A protocol you donate is infrastructure. Anthropic handed governance of its most strategically interesting piece of open work to a neutral body whose funding members are, without exception, the companies it competes with most directly. You do not do that with something you intend to monetise. You do it when you have concluded that universal adoption is worth more to you than control, which is the same calculation that produced every durable standard in computing.
It also removes the objection that was reasonably raised in the first year — that building your integration layer on a single vendor's protocol makes you a hostage. That objection is now substantially weaker, and its weakening is exactly what a waist forming looks like.
You can read it in the changelog
The second tell is more technical and, to me, more persuasive, because specifications reveal priorities in a way announcements do not.
The specification published on 28 July 2026 is described as the largest revision since launch, and what it does is worth listing plainly.2 The protocol core became stateless: the initialize handshake and session identifiers are gone, and each request now carries its own protocol version, client identity and capabilities — so that, in the spec's own framing, any request can land on any instance behind a plain round-robin load balancer. Server-initiated requests that needed a held-open stream were replaced by multi round-trip requests, where a tool needing mid-call input returns a result type of input_required instead. Routing moved into headers, Mcp-Method and Mcp-Name, so that gateways can route and authorise without parsing JSON bodies. List results became cacheable, carrying a time-to-live and a cache scope. Authorisation was hardened around existing standards: RFC 9207 issuer validation against authorisation-server mix-up attacks, and a shift from dynamic client registration to client ID metadata documents, with credentials bound to the issuing server. Long-running work moved into a Tasks extension with poll-based operations.
Now notice what that list actually is. Stateless so load balancers work. Headers so gateways work. Cache controls so caches work. OAuth conventions so existing identity infrastructure works. None of these are AI features. This is a protocol being reshaped to fit the boring plumbing of the web as it already exists — load balancers, reverse proxies, CDNs, identity providers. That is precisely what happens to a specification on its way to becoming a waist. It stops being interesting and starts being deployable.
What it standardised, and what it did not
Here is where I want to be careful, because the enthusiasm around MCP consistently overstates its coverage.
What is standardised is the plumbing: how a tool describes itself, how it is invoked, how the bytes move, and now how authorisation is negotiated against conventional identity infrastructure. That is a real achievement and it collapses the integration maths in the diagram above from a product into a sum.
What is not standardised is most of what makes a fleet of agents safe to operate. There is no built-in discovery — you point a client at an endpoint you already know about. Permissions are coarse, without the field, endpoint or task-level granularity that would let you say what a tool may touch rather than merely whether it may be called at all. Which produces what the community has taken to calling authorisation creep: agents steadily accumulating the ability to act across systems without any explicit, delegated grant tied to a specific action.3
The best sentence I have read on this — and I wish I had written it — is that discovery must never be mistaken for permission.3 Knowing that a tool exists and being entitled to use it are different facts, and a protocol that carries the first without the second hands you an integration surface rather than a security model.
None of this is a criticism of the specification, incidentally. Waists are narrow on purpose; IP does not tell you who is allowed to send a packet either. But it does mean that anyone who reads "we're MCP-compatible" as "we've handled the trust problem" has misread the layer they are standing on.
The attack surface is the feature working correctly
This connects directly to what I wrote about injection, and the connection is not incidental.
A protocol whose entire purpose is to let agents reach arbitrary tools is, by construction, a protocol that expands what an attacker can reach through your agent. The malicious package I described in that essay — a legitimate-looking server that shipped clean for fifteen versions and then quietly added a line that blind-copied every outgoing email to its author — was not an exploit of MCP. It was MCP working exactly as designed, carrying a tool that was hostile. The transport had no opinion, because transports do not.
So the provenance question sits above the protocol, unhandled by it, and every team assembling an agent from community servers has silently extended trust to every one of their authors. That is a supply-chain posture, and it wants supply-chain answers: pinned versions, known publishers, egress control that does not depend on the tool behaving.
Building on something still moving
The practical question for anyone shipping on this, which is the part where I have a stake rather than a view.
A specification that has just undergone its largest revision since launch is not finished, and the honest framing is that you are building on a moving surface that is nevertheless the best available bet. My working rules are unremarkable: pin the protocol version explicitly rather than inheriting whatever a library defaults to; treat extensions as extensions, with a plan for what happens if one does not survive to the next revision; keep your own harness decisions — which tools exist, what they return, what the errors say — separable from the transport, because those are yours and the transport is not; and assume the trust layer is your problem, because at present it is.
The strategic reading matters more than any of that. If MCP really is settling into the waist, then value moves away from it in both directions — down toward the model providers and up toward whatever is built on top. Integration plumbing is on its way to becoming a commodity, and quickly. Anyone whose differentiation is that they connected an agent to a system is holding an asset with a visible expiry date. What does not commoditise is the layer above: knowing which tools should exist for a given domain, what they should return, and what the thing is supposed to accomplish. The waist makes the connection free. It has nothing to say about whether the connection was the right one to make.
The honest caveat: I am reporting a specification and a governance change accurately, and then speculating about where a young ecosystem goes, which is a different activity with a worse track record. Protocols that look inevitable have failed before, competing agent-interoperability proposals are live and unresolved, and the fine-grained authorisation and identity work that would close the gaps described here is still open. My confidence is high on the diagnosis — a waist is forming and MCP is currently occupying it — and considerably lower on the timeline and on whether the current shape survives the next two revisions. Specification details in this piece are current as of the 28 July 2026 release and will age.