Enterprise Managed Authorization, which lets central IT provision client access through an identity provider, shipped in the 2026-07-28 specification as an extension. Every implementation has to support the core. Extensions are optional, which means you cannot assume a server you did not write has it.
That is the most enterprise-shaped capability in the release, and it landed outside the part everyone must implement. Read as a scope statement, it is consistent with everything else the same release did.
The release narrowed the core in three other places
The specification deprecated protocol-level logging, sampling, and roots, and the guidance for each is to go do it somewhere else. Logging moves to stderr or OpenTelemetry. Sampling goes away because servers can call an LLM API directly. Roots become tool parameters or server configuration. All three keep working for at least twelve months, and then they are gone.
The authorization hardening followed the same instinct. Rather than inventing MCP-specific machinery, the spec leaned on work that already exists: issuer validation per RFC 9207, credentials bound to the authorization server that minted them, and Client ID Metadata Documents replacing Dynamic Client Registration. Good decisions, all of them. None of them make MCP an identity system, and none of them were meant to.
Then there is the piece that gives the game away. Method and tool names now travel in HTTP headers, Mcp-Method and Mcp-Name, so that infrastructure sitting in front of a server can route and meter on them without parsing the JSON body. The protocol built a door for something outside itself to stand in. It did not build the thing that stands there.
Why a minimal core is the right call
MCP was donated to the Linux Foundation in December 2025 and now lives under the Agentic AI Foundation, which reached 170 member organizations in four months. Anthropic, AWS, Microsoft, and OpenAI all have maintainers in the room.
Multi-vendor stewardship makes a specification more conservative, not less. Every capability in the core is one that four competitors have to agree on, implement compatibly, and support for at least twelve months before it can change. Governance features are exactly where those companies have the least incentive to converge, because each of them sells a governance product. Pushing that surface into extensions is how a protocol stays neutral enough to be adopted by everyone.
It is also the pattern that worked before. HTTP does not ship an identity system, an audit log, or a policy engine. It has headers, and an ecosystem grew up around them. TCP does not know who you are. The layers that carry everything tend to be the layers that assume the least.
So this is not a criticism. A protocol that tried to specify enterprise governance in 2026 would have shipped something four vendors quietly ignored.
The consequence is still yours
The bill arrives anyway. Every requirement a protocol declines becomes an operational decision somebody has to make, and the list from this one release is specific.
Logging is the clearest case. Protocol-level logging is deprecated, and the replacement guidance names stderr and OpenTelemetry. Both are fine answers for a developer debugging a server. Neither one produces a record of which tool an agent called, as whose identity, in what order, that an auditor can read a year later. If the sentence "we have an audit trail for our agents" is going to be true at your company, somebody is building that, and the protocol just told you it will not be them.
Authorization is the same shape. EMA being an extension means it is optional, which means in practice you cannot assume a server you did not write supports it. The 8.5% of MCP servers that authenticate with OAuth are not going to become 100% because a better mechanism exists in an optional document.
And the stateless core, which removed the session handshake and the session ID, means anything that used to hang off a connection now needs somewhere to live. Rate limits. Spend caps. Anything counted per agent rather than per request.
What to take from it
Read the deprecation list as a scope statement, because that is what it is. The protocol is telling you which problems it considers in bounds and which it does not, and the out-of-bounds pile is where most of the enterprise requirements ended up.
The teams that will have a bad year are the ones who read "MCP added authorization hardening" and concluded the governance problem was being handled upstream. It is being handled, in the sense that the protocol is getting out of the way cleanly and giving the layer above it the headers it needs. Building that layer is somebody's job, and the specification is now unambiguous about whose.