The Model Context Protocol has reached a major infrastructure milestone: its 2026-07-28 revision moves the protocol toward a stateless core. For teams building agent systems, tool servers, IDE integrations, or multi-model orchestration layers, this is not a cosmetic spec update. It changes assumptions about sessions, initialization, scaling, compatibility, and governance.
The MCP release candidate described the July 28 specification as adding a stateless protocol core, an Extensions framework, Tasks, MCP Apps, authorization hardening, and a formal deprecation policy. The official MCP blog also warned that the release contains breaking changes. GitHub, which operates one of the most visible MCP server implementations, said ahead of the final release that its MCP Server already supported the new specification and described the protocol as “going stateless” on July 28.
The practical meaning is straightforward: MCP is being shaped less like a session-heavy local integration layer and more like an internet-scale protocol for remote tool access. That matters because agent systems are no longer confined to desktop developer tools. They increasingly run inside cloud services, CI systems, customer support workflows, issue trackers, and enterprise automation platforms.
What changed in MCP
The headline change is the move to a stateless protocol core. GitHub’s changelog says the new core removes sessions and initialize, with the goal of making remote MCP deployments easier to scale. That is a significant architectural shift. Stateful protocols can work well for local tools and controlled environments, but they complicate horizontal scaling, serverless execution, failover, edge deployment, and load balancing.
A stateless core gives implementers more freedom to run MCP servers behind ordinary web infrastructure. Requests can be distributed across instances without preserving a long-lived session on a specific backend. For large organizations, that can reduce operational complexity. For smaller teams, it may make hosted MCP servers easier to deploy using managed compute instead of custom long-running infrastructure.
The broader 2026-07-28 release also introduces an Extensions framework and Tasks, according to the release-candidate materials. Those additions suggest MCP is becoming more modular and more explicit about longer-running work. MCP Apps and authorization hardening point in the same direction: the protocol is maturing from early ecosystem glue into a more formal layer for agent-to-tool interaction.
The cost of that maturation is compatibility work. The MCP blog characterized the release as one with breaking changes, and the TypeScript and C# SDK materials published around the revision focus on migration support and stateless concepts. Any team operating an MCP server, embedding MCP in an IDE extension, or routing agent calls through internal infrastructure should treat the revision as an engineering event rather than a background standards update.
Why stateless MCP matters for developers and operators
Agent tools have a scaling problem that looks different from ordinary API scaling. A single user request can trigger many tool calls, model turns, retries, file reads, search queries, and approval steps. When the tool protocol assumes durable sessions, production operators must preserve state across those interactions or build workarounds around the protocol.
By removing sessions from the core, MCP better fits environments where agent workloads are bursty, distributed, and asynchronous. Serverless functions, edge workers, Kubernetes deployments, and multi-region systems all benefit when requests can be handled independently. That does not eliminate state from agent applications; it moves state into application databases, task queues, identity systems, or explicit workflow layers rather than embedding it in the protocol core.
For developers, the change should eventually make remote tool servers easier to consume. For platform teams, it may simplify observability and capacity planning. Instead of debugging opaque session affinity behavior, operators can focus on request-level traces, tool-call latency, authorization decisions, and error patterns.
There is also a governance angle. As MCP becomes more common in coding assistants and enterprise agents, companies will need policies around which tools agents can call, what data they can access, and which users or services are allowed to invoke them. Authorization hardening in the new revision is therefore not incidental. It reflects the reality that tool access is now a security boundary, not just a developer convenience.
Who is affected
The most directly affected groups are MCP server maintainers, SDK users, agent platform teams, and organizations exposing internal tools to AI agents. If a server depends on session behavior or older initialization flows, it will need testing against the new specification. If an application supports multiple MCP versions, it may need version negotiation, compatibility layers, or a phased migration plan.
IDE and developer-tool vendors are also in scope. MCP is increasingly appearing alongside coding agents, custom agents, and model-management features. A stateless protocol core makes it easier for these products to call remote tools reliably, but only if their integrations keep pace with the spec.
Businesses using agent automation should pay attention even if they never read the MCP specification. The change may affect the reliability of agents that connect to repositories, ticketing systems, databases, internal knowledge bases, or deployment tools. During migration windows, the likely failure modes are not only obvious outages. They may include missing tool capabilities, changed authentication behavior, or agents taking different paths because a tool server no longer behaves as expected.
For an AI API gateway such as Model Gate, the connection is practical. A unified AI API increasingly sits near model routing, API key management, usage analytics, and team API governance. As agent systems add MCP tool calls beside ordinary model calls, gateway and observability layers will need to account for both sides of the workflow: which model was used, which tools were invoked, what they cost, who authorized them, and where failures occurred.
Migration priorities and open questions
The first migration priority is compatibility testing. Teams should inventory MCP clients and servers, identify dependencies on sessions or initialize behavior, and test against the 2026-07-28 SDKs or conformance materials where available. Production systems should stage the upgrade, especially if agents perform actions with side effects such as creating pull requests, modifying issues, querying customer data, or executing deployment workflows.
The second priority is observability. Stateless infrastructure can be easier to scale, but distributed agent systems still need correlation IDs, trace capture, request logs, and policy events. Without those, teams may trade session complexity for debugging complexity. Usage analytics should distinguish between model calls and tool calls, especially when agent workflows are billed, rate-limited, or audited by team.
The third priority is authorization review. If the new spec hardens authorization semantics, implementers should not simply port old access assumptions into the new version. They should re-check token scopes, user delegation, service accounts, audit logs, and denial behavior. Tool access should be least-privilege by default, particularly for remote MCP deployments.
Some details remain worth checking before organizations make irreversible design decisions. The research available for this article included the release candidate, the specification page, SDK migration materials, and GitHub’s implementation note. The final normative wording of the 2026-07-28 specification should be reviewed directly before quoting exact protocol requirements in internal standards or customer documentation.
Even with that caveat, the direction is clear. MCP is becoming a more production-oriented protocol for agent infrastructure. The stateless core should make remote deployments easier to scale, but it also forces the ecosystem to clean up assumptions from earlier implementations. For teams building with agents, this is the kind of protocol change that deserves a sprint ticket, not just a bookmark.