Today, the protocol that silently connects every AI agent in your enterprise to every tool, database, and API it touches just changed in ways that will reshape your infrastructure, your security posture, and your governance model. If you've been watching your developers wire AI agents to internal systems while your platform team stood on the sidelines wondering how to govern any of it—that problem just got significantly smaller.
The Model Context Protocol's 2026-07-28 specification shipped today, and it's the largest revision to MCP since Anthropic introduced the protocol in November 2024. The headline change—MCP is now stateless at the protocol layer—sounds like a developer detail. It isn't. It's an enterprise infrastructure decision that eliminates a class of expensive, hard-to-govern infrastructure overhead while simultaneously handing platform teams the control point they've been missing since MCP went viral inside their organizations.
What MCP Is, and Why Enterprises Should Care
If you've been living in the business side of the house and haven't tracked MCP closely: it's the open standard that lets AI agents—coding assistants, autonomous workflow tools, enterprise chatbots—connect to external services. Your CRM, your ERP, your code repositories, your internal databases. Wherever your agents need to reach, MCP is the protocol they use to get there.
Anthropic introduced it in November 2024. By mid-2026, OpenAI, Google DeepMind, Microsoft, AWS, and hundreds of enterprise software vendors had adopted it. The Agentic AI Foundation—a Linux Foundation directed fund with Anthropic, OpenAI, Block, Google, and Microsoft as platinum members—now governs the protocol. This isn't an experimental standard. It's becoming the TCP/IP of enterprise AI.
The problem is what happened between November 2024 and today. MCP spread faster than governance could follow.
The Governance Problem Nobody Talked About
Here's a pattern that played out inside nearly every enterprise running AI agents in the past 18 months: developers found MCP, saw the value immediately, and wired a dozen internal servers to their coding agents before anyone in platform engineering knew it was happening. Not recklessly—just fast. The tooling was easy to deploy. The productivity gains were real. The governance framework didn't exist yet.
Platform teams faced a genuinely difficult technical constraint. The 2025-11-25 specification—what most enterprises are still running—required every MCP client to establish a session before any tool call. The server issued a session ID (an Mcp-Session-Id header) that every subsequent request had to carry. That session ID pinned each client to the specific server instance that issued it.
This created a structural problem for governance. There was no clean way to say "this specific tool call, from this specific agent, on behalf of this specific user, is or isn't authorized" without reconstructing the session context. Platform teams couldn't put a standard gateway in front of MCP servers because gateways couldn't route requests without inspecting the body of every call—and even then, the session state lived somewhere they didn't control.
Two bad options: let every team run their own MCP servers with their own auth posture, or build a custom proxy layer to fake statelessness on top of a protocol that was never designed for it. Most enterprises quietly chose the first option, which is why AI agent governance has been more aspiration than reality.
What Changed Today: The Session Is Dead
The 2026-07-28 specification eliminates both the initialize handshake and the session ID entirely. Under the new spec, an MCP tool call is a single, self-contained HTTP request that any server instance can handle:
- The protocol version, client identity, and client capabilities that previously required a handshake now travel in a
_metafield on every request. - A new
server/discovermethod lets clients fetch server capabilities on demand. - Two required headers—
Mcp-MethodandMcp-Name—let load balancers, gateways, and rate limiters route on the operation without inspecting the request body.
The practical effect: a remote MCP server that previously needed sticky load balancer routing, a shared Redis session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer. No sticky routing. No Redis. No body inspection.
What This Means for Your Infrastructure Team
The infrastructure simplification is immediate and real. For any team running remote MCP servers at scale, the old spec imposed a tax: sticky sessions meant you couldn't scale horizontally without either pinning clients to instances or sharing session state across instances via Redis or equivalent. Either approach added latency, operational complexity, and cost.
That tax disappears under 2026-07-28. Round-robin load balancing works out of the box. Tools/list responses now carry ttlMs and cacheScope fields—modeled directly on HTTP Cache-Control—so clients know exactly how long a capability list is fresh and whether it's safe to share across users. A long-lived SSE stream is no longer the only way to know when capabilities changed.
W3C Trace Context propagation is now formally specified in _meta, with fixed key names for traceparent, tracestate, and baggage. In practice, several SDKs were already doing this inconsistently. With the key names locked in the spec, a trace that starts in a host application can follow a tool call through the client SDK, through the MCP server, and into whatever the server calls downstream—and show up as a single span tree in any OpenTelemetry-compatible backend.
That last point matters more than it sounds. For the first time, you'll have a queryable audit trail of every agent-to-tool call across your infrastructure, using the same observability tooling you already operate.
What This Means for Your Security and Platform Teams
The governance story is where 2026-07-28 has its biggest enterprise impact, and it's worth reading carefully.
When the protocol required sessions, the auth boundary was messy. You couldn't intercept and evaluate individual requests independently; you had to understand session context to understand what a request was authorized to do. That made it nearly impossible to put a policy layer in front of MCP servers without building custom infrastructure.
Stateless requests change the model entirely. Every request now carries its own identity and capability information inline. That's a single, well-defined control point—and it's one a standard API gateway can enforce. Any call to an MCP server is, by definition, an agent acting on behalf of someone. That's the control point you've been waiting for.
Three additional changes in the same spec release reinforce this:
OAuth and OIDC alignment. Six Specification Enhancement Proposals (SEPs) in this release align MCP's authorization model more closely with OAuth 2.0 and OpenID Connect. Token exchange and token scoping now follow standard patterns your identity team already understands. Agents can be scoped to less privilege than the humans they represent—a basic security property that was awkward to enforce under session-based auth.
Schema validation at the edge. The inputSchema and outputSchema fields on tool definitions are now formally bound to JSON Schema 2020-12. Previously they were advisory; now they're a contract. A gateway can validate every tool call against the declared schema before it reaches a production system—and reject malformed or unexpected inputs at the perimeter. That's a meaningful defense-in-depth layer for any enterprise worried about prompt injection or unexpected agent behavior.
Deprecation of Roots, sampling, and logging. Three capabilities that existed in previous specs are now formally deprecated. Roots—which previously defined access scope for MCP servers—are being retired in favor of explicit server configuration and policy-layer enforcement. Logs are being pushed onto real infrastructure (OpenTelemetry), which means agent activity ends up in queryable observability systems you control rather than buried in protocol metadata you can't easily audit.
The New Capabilities: Tasks and MCP Apps
Beyond the stateless core, two extensions graduate to first-class status in this release, and both have significant enterprise implications.
Tasks is no longer experimental. The Tasks extension formalizes how MCP handles long-running work—the kind that doesn't complete in a single synchronous call. Think multi-step data processing, background report generation, autonomous workflow execution that might run for minutes or hours. The 2026-07-28 spec gives Tasks a formal lifecycle, error handling, and cancellation model.
For enterprise leaders thinking about agentic workflows—AI that executes multi-step business processes without constant human handholding—Tasks is the foundation. Without it, agentic workflows that took longer than a single request were difficult to build reliably. With it, platform teams have a standardized model for how agents manage durable work.
MCP Apps is a new extension that enables server-rendered user interfaces through MCP. Servers can now deliver sandboxed HTML UIs directly to MCP clients—which means an MCP tool can surface a confirmation dialog, a structured form, or a data visualization inside the agent interface without requiring a separate web application.
For enterprises deploying AI assistants for business users, this changes what agents can look like. Instead of pure text interactions, agents can present structured review interfaces for human-in-the-loop workflows—approval screens, data verification forms, summary dashboards. This is particularly relevant for finance, legal, and HR use cases where human approval is required before an agent takes action.
What This Means for Business Leaders
The technical changes above translate to three business outcomes worth understanding at the executive level.
Cost reduction in AI infrastructure. Eliminating sticky session requirements and Redis session stores from MCP deployments reduces operational overhead directly. Round-robin load balancing means you can use standard commodity cloud infrastructure for horizontal scaling rather than maintaining custom session-aware routing. For organizations running hundreds of MCP-connected agents at scale, this is a meaningful reduction in complexity and cost.
Risk reduction through real governance. The single biggest enterprise AI risk of the past 18 months has been shadow AI infrastructure—agents connecting to internal systems without platform oversight, creating data exposure and compliance risks that nobody had visibility into. The stateless spec doesn't eliminate that risk on its own, but it removes the technical barriers that made governance so difficult. If your platform team hasn't already built an MCP gateway layer, they can now do it with standard infrastructure.
A foundation for scalable agentic workflows. The Tasks extension and the formal stateless protocol together create what enterprises have been waiting for: a standards-based way to run autonomous multi-step AI workflows at scale, with audit trails, standardized auth, and observable execution. That's the prerequisite for moving agentic AI from pilot projects into production business processes.
What Your Team Should Do Right Now
The 2026-07-28 spec contains breaking changes. If your organization is running MCP servers in production, your team needs a migration plan. Here's where to focus:
Audit your MCP surface area first. Before migrating, find every MCP server your organization is running or connecting to—sanctioned and unsanctioned. For each one, understand whether it depends on the Roots capability for access control, whether it holds session state your infrastructure doesn't control, and whether it's reachable over HTTP with weak or missing auth. That inventory is your migration risk register.
Treat the spec change as an opportunity to centralize auth. The most valuable thing you can do with the 2026-07-28 migration is stand up a real MCP gateway with proper token scoping. Every agent call is now a discrete, inspectable HTTP request—which means you can actually enforce policy at that layer for the first time.
Validate schemas at the edge. With inputSchema and outputSchema formally bound to JSON Schema 2020-12, you can reject unexpected tool calls at the gateway before they reach production systems. If you're running an API gateway already, this is a configuration change, not a new infrastructure investment.
Move logs to OpenTelemetry before the deprecation lands. If your MCP servers are using the protocol-level logging capability, plan to migrate those logs to your existing OTel infrastructure. The deprecation gives you time, but the sooner you have agent activity in your standard observability stack, the sooner you have real audit capability.
The Bottom Line
MCP 2026-07-28 is not a minor version bump. It's a protocol that was designed for a world of individual developers and local servers, redesigned for a world of enterprise-scale AI agent deployments. The stateless core, the OAuth/OIDC alignment, the schema contracts, and the formal Tasks lifecycle together constitute a protocol that platform teams can finally govern the same way they govern the rest of their infrastructure.
The window between this spec release and your competitors building governance frameworks around it is short. The enterprises that treat today's spec change as an infrastructure event—and move quickly to put proper gateways, auth, and observability in place—will have a structural advantage in deploying agentic AI reliably and at scale.
For CIOs and platform leads: this is the spec you've been waiting for. The protocol finally caught up to where enterprise AI deployments already are. Now it's an execution problem, not a standards problem.
The 2026-07-28 MCP specification is available at modelcontextprotocol.io. The full release candidate details and SEP references are documented at the official MCP blog.
