The MCP 2026-07-28 release is the largest revision of the Model Context Protocol (MCP) since its launch, and it reaches into transport, extensions, authorization, and tool schemas at once (release announcement). If you run MCP anywhere near production, this MCP release is less a feature drop than a re-foundation. This overview walks through what changed and, for each change, what it means for the teams running MCP against real enterprise data.
At a glance: The 2026-07-28 MCP release reorganizes MCP around a stateless protocol core, with capabilities delivered as versioned, opt-in extensions, a shift from one monolithic spec toward a small core plus an extension ecosystem (release announcement). If you operate an MCP server, it changes how sessions, authorization, and tool schemas work, and it arrives as 2026 becomes the year MCP adoption goes enterprise-ready.
What the MCP 2026-07-28 release changes
The release's changes compound. The protocol core becomes stateless, which also reshapes how a server makes requests back to a client; a formal extensions framework arrives, with MCP Apps and Tasks as the first two official extensions; authorization gets hardened; tool schemas move to the full JSON Schema 2020-12 standard; and the older Roots, Sampling, and Logging capabilities start being retired (release announcement). The official announcement and spec cover the mechanics in full. This post stays on what each change means once you run it. If you're new to the protocol, start with what MCP is and why it matters.
Deprecation here is worth a closer look, because "deprecated" and "gone" aren't the same date. A few older mechanisms are already replaced in this release, while the broader Roots, Sampling, and Logging capabilities get at least a 12-month runway before removal (release announcement). The practical takeaway: check what your SDK still supports before planning a migration.
Statelessness: the core change
Older MCP kept a session on the server: a client connected, the server remembered that connection, and every later request had to return to the same instance. The 2026-07-28 release ends that (release announcement). Each request now carries what a server needs to handle it, so any instance can answer any request and you scale an MCP server the way you scale an ordinary web service. That also clears the stateful Server-Sent Events (SSE) limitations we flagged earlier. For the wire-level mechanics, and why they matter for enterprise AI, see our companion deep dive on stateless MCP.
For enterprise operators, that's the payoff: an MCP server that scales out and fails over like the rest of your stateless infrastructure, instead of pinning each client to the instance that started its session. The catch is timing. Full statelessness depends on the SDKs and clients finishing their own support, and when it lands it is likely to be a breaking change, so it is worth planning a migration around rather than switching on. Statelessness has real edges, too: some interactive features lean on state to behave correctly once a server scales out, and that state then has to live somewhere every instance can reach.
Multi round-trip requests: interactivity without a held session
Statelessness also has to solve the reverse direction. Sometimes a server needs to ask the client for something mid-request: an elicitation prompt for missing input, or a sampling call. The old design handled that by opening a long-lived Server-Sent Events stream back to the client and holding state until the answer arrived. In a load-balanced deployment that breaks, because the client's answer can land on a different instance than the one waiting for it, so the server needs sticky routing or shared storage to bridge the gap (SEP-2322).
Multi round-trip requests replace that pattern. Instead of opening a channel back to the client, a call can return an "input required" result that carries the server's follow-up questions plus an opaque token of its own state. The client answers and re-sends the original call with that token attached, and because everything the server needs rides in the request, any instance can pick it up and finish the job. It is a breaking change to how server-initiated requests work, and it narrows where they are allowed (release announcement).
For enterprise teams, this is what makes interactive features usable in production. Elicitation and sampling were effectively blocked on remote MCP servers that could not hold SSE connections or share session state across instances. Multi round-trip requests let those features run on ordinary stateless, load-balanced infrastructure, at the cost of one more breaking migration to plan in step with the stateless core.
The extensions framework: MCP Apps and Tasks
Rather than grow the core, the release adds an extensions framework: optional, versioned capabilities a server can opt into, so MCP can gain features without every server carrying them (release announcement). MCP Apps and Tasks are the first two official extensions.
MCP Apps lets a server ship a small sandboxed interface that the host renders alongside a tool's result (SEP-1865). Because that interface is declared up front, a security team can vet it before it ships. That review gate is what an enterprise needs before a rendered interface reaches its users. For most enterprise data, the natural fit is a sortable table or a typed form for a stored procedure rather than a freeform interface.
Tasks handles long-running work: instead of holding a connection open until a job finishes, a tool can hand back a ticket and let the client check on it later (MCP Tasks extension). For enterprise data, slow operations are the norm, not the exception: bulk exports, warehouse scans, federated joins across systems, and long stored procedures all push past a single request's time budget. Tasks gives them a standard shape, so an agent can start a long job and collect the result later instead of timing out mid-request.
Authorization hardening
If "authorization changes" makes you picture a server rewrite, most of the hardening lands on clients, not servers. The core idea is unchanged: an API can publish which authorization server protects it, so a client discovers how to authenticate instead of being wired up by hand (RFC 9728). The release tightens the client-side checks around that, which the MCP authorization spec lays out in detail. For a team, that reads as a direct answer to the identity and access-control gaps the NSA's MCP security advisory called out, and the migration work sits mostly with your clients.
The handshake is only half the question, though. The harder question is what happens after a client authenticates: whether access honors the permissions a user already holds in the source system, and whether every query an agent runs can be audited. That governance sits above the protocol, and it's a bar worth holding any production MCP setup to.
Tool schemas: full JSON Schema 2020-12
MCP tool definitions have always described a tool's inputs with a JSON Schema, but only a restricted slice of it. The release adopts the full JSON Schema 2020-12 standard, so tool authors can describe far more precisely what a tool accepts and returns (release announcement). The standard itself isn't new; using all of it is. A tighter contract means fewer malformed tool calls for a model to recover from, and fewer surprises in production.
The practical question this reopens for tool authors is how tightly to specify each tool. More constraint catches bad calls earlier, but over-specifying a schema for a source whose own contract is loose doesn't remove failures; it pushes them downstream, so the right level of strictness is better decided per source than set globally. For a tool that fronts a system of record, that precision is also a control surface: a tighter schema narrows what an agent can even ask a production system to do, the kind of boundary an enterprise wants before it puts an agent near live data.
What the release means if you're adopting MCP in production
Read together, the release codifies what production systems already needed: stateless scaling, opt-in extensions, standardized authorization, and precise tool contracts. None of that is new to anyone who has run a production service. What's new is the protocol agreeing on it.
The teams best positioned for the release are the ones already operating MCP against real enterprise data, because the spec is codifying problems they've hit. Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027, largely over cost, unclear value, and weak controls. The projects that survive tend to be the ones that treated governed data access as the hard part early. Adopters of this release get to inherit that experience instead of rediscovering it under load.
If you're evaluating MCP for enterprise data, the practical question is whether to build and run an MCP server per source yourself or adopt a managed MCP platform that handles connectivity and governance for you, the same trade-off these MCP server best practices for 2026 walk through.
What each change means for your team
Change | What it changes for your team | How to approach it |
Stateless core | MCP servers scale and fail over like ordinary web services, with no sticky sessions to pin a client to one instance | Plan the migration as client and SDK support lands, and externalize any state you were leaning on the session to hold |
Multi round-trip requests | Server-initiated calls like elicitation and sampling work without SSE streams or sticky sessions, on stateless infrastructure | Plan it alongside the stateless migration; it unblocks interactive features on remote and load-balanced servers |
MCP Apps | A server can return a sandboxed interface the host renders, and your security team can review it before it reaches users | Treat it as demand-led, and adopt it when a real use case needs richer output than a table can give |
Tasks | Long-running work such as exports and warehouse scans returns a ticket instead of holding a connection open | Map your slow operations to it, and expect it to standardize patterns your team likely already hand-rolled |
Authorization hardening | Most of the new work falls on your clients rather than your servers, as discovery and token checks get stricter | Audit your MCP clients against the new checks, and confirm access still honors source-system permissions and is logged |
Tool schemas | Tools can describe their inputs and outputs precisely, so agents make fewer malformed calls | Tighten schemas where the source contract is strict, and avoid over-constraining sources whose own contract is loose |
See what production-grade MCP looks like with CData Connect AI
Governed, secure connectivity to enterprise data is the hard part of putting MCP into production, and it's what CData Connect AI is built for. Through one managed MCP layer, your AI clients reach hundreds of enterprise data sources with authentication, source-system permissions, and query auditing handled for you. Start with the Connect AI MCP quick start to connect a source to an AI client in a few minutes.
Frequently asked questions
What is the MCP 2026-07-28 release?
It's the largest revision of MCP since the protocol launched. It makes the protocol stateless at its core, formalizes an extensions framework (with MCP Apps and Tasks as the first official extensions), hardens authorization, upgrades tool schemas to the full JSON Schema 2020-12 standard, and begins retiring Roots, Sampling, and Logging (release announcement).
Is MCP ready for enterprise production use?
Increasingly, yes, and this release is a large part of why: stateless scaling, standardized authorization, and precise tool contracts are the things production teams ask for. Readiness still depends on operating it well, with governed access, audited queries, and a real answer for long-running operations, which is where a managed MCP platform differs from a self-hosted server.
Does the stateless change break existing MCP servers and clients?
It breaks anything that relied on the old server-held session: sticky routing to one instance, or a client that expected the server to remember the connection. A server already built to run statelessly shares the philosophy, but adopting the release's specific stateless mechanics is still a migration that rolls out as client and SDK support matures (release announcement).
What are MCP extensions, and what are the first official ones?
Extensions are optional, versioned capabilities a server can opt into, so MCP can grow without every server carrying every feature. MCP Apps (a sandboxed UI a host renders alongside a tool result) and Tasks (long-running, check-on-it-later work) are the first two official extensions (release announcement).
Is JSON Schema 2020-12 required for MCP tools now?
As of the 2026-07-28 release, MCP defines tool input and output schemas against the full JSON Schema 2020-12 dialect, so 2020-12 is the standard tools are written to (release announcement). You don't have to use every feature it allows, but the full dialect is now available, which lets tool authors describe inputs and outputs far more precisely and reduces malformed tool calls.
What does the release change about authorization?
It tightens client-side checks: a client now confirms that a token came from the authorization server it expected (per RFC 9207), on top of the existing discovery model that lets a client find the right authorization server automatically (OAuth 2.0 Protected Resource Metadata, RFC 9728) (authorization spec; RFC 9728; RFC 9207).
References
Model Context Protocol. The 2026-07-28 MCP Specification Release Candidate.
Model Context Protocol. Authorization specification.
RFC 9728: OAuth 2.0 Protected Resource Metadata.
RFC 9207: OAuth 2.0 Authorization Server Issuer Identification.
JSON Schema. JSON Schema 2020-12.
Model Context Protocol. SEP-2575: Make MCP Stateless.
Model Context Protocol. SEP-2322: Multi Round-Trip Requests.
Model Context Protocol. SEP-1865: MCP Apps.
Model Context Protocol. MCP Tasks extension.
Over 40% of agentic AI projects will be canceled by end of 2027.
Explore CData Connect AI today
See how Connect AI excels at streamlining AI and business processes for real-time insights and action.
