Your agent tool layer just became infrastructure

The most consequential agent-infrastructure release this quarter removes capabilities instead of adding them. On July 28, the Model Context Protocol finalizes its largest revision since Anthropic introduced it in November 2024, and the headline change is a deletion: protocol-level sessions are gone. The initialize handshake and the session header — the two things that forced sticky routing on every horizontally scaled deployment — are simply removed. An MCP fleet now sits behind a round-robin load balancer like any other stateless HTTP service.

That is not an exciting sentence, and that is the point. Protocols create enterprise value at precisely the moment they stop being interesting — when the operations team can run them with the load balancers, identity providers, and gateways it already owns. MCP has just crossed that line, and the crossing quietly ends the two-year phase of enterprise agent programs that began when the protocol shipped: the connector-building era. What replaces it is a harder, less technical question that most organizations have not assigned to anyone.

What actually changes on July 28

The release candidate was locked on May 21 with a ten-week validation window for SDK maintainers; the specification goes final on July 28. Three changes matter architecturally.

The protocol core is stateless. The previous revision (2025-11-25) required clients to establish sessions and carry a session ID on every request, which meant horizontally scaled MCP servers needed sticky routing or a shared session store. Both are gone. Client metadata now travels per-request in _meta fields, and application state moves into explicit handles that the model can inspect, compose across tools, and pass between steps. This is more than an ops convenience: state that used to hide in transport metadata is now visible in the trace, which means it is testable and auditable in a way session state never was.

Gateways become a first-class deployment assumption. New Mcp-Method and Mcp-Name HTTP headers let a gateway route and rate-limit tool traffic without inspecting request bodies. List and read responses can carry ttlMs and cacheScope metadata for caching layers, and W3C Trace Context propagation threads agent tool calls into standard distributed tracing. A specification does not add fields for middleboxes unless middleboxes are where it expects to live.

Authorization aligns with the identity stack you already run. Six enhancement proposals tighten OAuth 2.0 and OpenID Connect conformance, including issuer validation per RFC 9207. Alongside the core spec, the Enterprise-Managed Authorization extension — promoted to stable in recent weeks — lets an organization provision MCP server access centrally through its identity provider: an admin enables a server for the org, and users inherit access scoped to the groups and roles they already hold, with no per-app OAuth consent. This is shipping, not roadmap: Okta is the first supported identity provider, Anthropic has wired the extension through its Claude clients, and seven SaaS vendors — Atlassian, Figma, and Linear among them — already accept it server-side.

Read together, this is a specification redesigned around the realities of enterprise deployment: load-balanced fleets, API gateways, corporate identity, distributed tracing. The demo-friendly parts were already done. This revision is for production.

The connector era is ending

Since the protocol shipped, the visible work of most enterprise agent programs has been connectivity: standing up MCP servers in front of internal systems, wrapping APIs, negotiating auth for each integration. Sessions never mattered on a laptop; they broke the first time a server was deployed highly available — one more instance of the demo-to-production gap where the failure lives in infrastructure, not in the model.

That work is now being commoditized from both ends. On the supply side, the platform vendors are simply handing you the connectors: at Next ’26, Google put more than fifty managed MCP servers into GA or preview — the database portfolio end to end, BigQuery through Spanner to Bigtable, with Google operating the servers — and the SaaS vendors above ship their own endpoints as product features. On the control side, Gartner analysts project that 75% of API gateway vendors will have MCP features by the end of 2026, which is the market’s way of saying the control point has been identified and everyone is racing to sell it to you.

When the protocol scales behind commodity load balancers, access is provisioned through your IdP, and the hyperscaler maintains the connectors, building tool integrations stops being differentiating work. The differentiating work moves up a level.

Exposure is the new decision

Here is the uncomfortable symmetry: everything that just made the tool layer cheap to operate also made it cheap to sprawl. When a connector took a sprint to build, scarcity was your governance. When it takes a checkbox in an admin console, the estate grows by default — every team enables the servers it finds useful, every SaaS renewal arrives with an MCP endpoint attached, and agent reach expands monotonically because nobody’s job is to decommission a tool. Gartner’s February 2026 report, Best Practices to Counter MCP Security Risks, is blunt about where this lands: by 2027, incidents tied to prompt injection, data access, or agent misconfiguration will impact more than 40% of enterprise MCP deployments.

The correction is to treat the tool estate the way you learned to treat APIs a decade ago: as a governed product surface, not a wiring closet. In the enterprise agentic AI reference architecture, tools are first-class components and the only path to side effects; the July revision finally gives that boundary a standardized, gateway-enforceable substrate. The minimum viable platform on top of it:

1. A catalog of record. Every MCP server reachable by any agent — internal, managed, SaaS-embedded — registered with an owner, a purpose, and a scope tier. If it is not in the catalog, the gateway does not route to it.
2. A gateway in front of everything. The new routing headers make per-tool policy, rate limits, and cost attribution cheap. There is no longer an engineering excuse for agents calling tool endpoints directly.
3. Contract tests per tool. The must_call_tools / must_not_call_tools assertions in an eval harness are contract tests for the estate; run them when the server changes, not only when the agent does. A vendor updating their MCP server is a change to your system.
4. Scope tiers with different rules. Read-only retrieval, reversible actions, and irreversible actions are different products with different review bars — a checkbox for the first, an architecture review for the last.
5. A decommissioning path. Tools leave the catalog the way they enter it: deliberately. An estate that only grows is an attack surface with a growth rate.

The conglomerate version

For a diversified group, the estate does not grow from one direction but four: servers built by group IT, servers built independently by subsidiaries, servers embedded in SaaS the group licenses, and servers built by system integrators under transformation programs. The July changes sharpen two questions that are organizational, not technical.

First, EMA moves the access decision into the identity provider — which means your IdP group structure, exactly as it exists today, has just become your agent authorization policy. In a group where directory groups have accumulated across acquisitions, reorganizations, and subsidiary IdP federations, “users inherit access scoped to the groups they already have” is only as sound as that accumulated sprawl. Directory hygiene used to be an audit finding; it is now a production control on autonomous software.

Second, cross-entity exposure gets easier than cross-entity governance. A subsidiary’s manufacturing system behind an MCP server is one IdP policy change away from being reachable by every agent in the group — an inter-company access pattern, executed at machine speed, that your legal entity structure was never asked to approve. The economics favor a group-level tool estate run as a shared service, and the single catalog and audit surface that come with it; but that only works if the catalog encodes entity boundaries as policy, not as convention.

Questions for the next architecture review

1. Can we enumerate every MCP server our agents can reach today — including SaaS-embedded ones an admin enabled with a checkbox?
2. Who decides that a new tool enters the estate, and is that a platform decision or a team-level default-yes?
3. Are our IdP groups, as they actually exist across entities, an authorization policy we would defend for autonomous software?
4. Do our tools have contract tests that run when the server changes, not just when our agents do?
5. What left our estate in the last quarter — and if the answer is nothing, who owns decommissioning?

The protocol has done its part: the tool layer is now boring, scalable, and governable with infrastructure you already own. What remains is a decision about ownership — and the window to make it cheaply is the next few quarters, while your tool estate still fits on one screen.