MCP 2026 Specification Update: What Changed on July 28

The Model Context Protocol just shipped its most significant update since remote MCP first launched. On July 28, 2026, the spec went stateless — and that single architectural decision ripples through everything from how agents connect to servers, to how you scale deployments, to what your security team needs to worry about next.

If you run AI agents against MCP servers — or you're building the infrastructure that feeds them company context — this breakdown covers every change that matters and what it means in practice.

Why the MCP 2026 specification update is the biggest yet

According to the official MCP blog post from lead maintainers David Soria Parra and Den Delimarsky, MCP is now seeing close to half a billion downloads a month across Tier 1 SDKs. At that scale, the stateful session model was becoming a ceiling. The July 28 release removes that ceiling.

As the announcement puts it: MCP is "transforming from a bidirectional stateful protocol into a request/response stateless protocol." Ars Technica called it "MCP's most important update since remote MCP first launched over a year ago."

Here is what actually changed.

No handshake, no sessions — the stateless core

The headline change: the initialize/notifications/initialized handshake is gone. So is the Mcp-Session-Id header. Every request now carries its own protocol version and client capabilities inside _meta fields (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities). Clients should identify themselves on each request; servers should identify themselves in each result.

What this means concretely: there is no longer a session to establish before work can begin. Connections are faster. Clients can complete what used to be a handshake in parallel rather than sequentially. And critically, list endpoints — tools/list, resources/list, prompts/list — no longer vary per-connection, which makes them cacheable (more on that below).

For servers that genuinely need cross-call state, the spec introduces explicit server-minted handles passed as ordinary tool arguments. State lives in the application layer, not the protocol layer. This is the right separation.

GitHub's MCP Server shipped support ahead of the official release and described the practical win bluntly: they removed Redis sessions entirely. Database writes on initialize are gone. Database reads are gone from every call. The result is faster responses without users losing anything.

Multi Round-Trip Requests (MRTR)

Stateless does not mean single-shot. The spec introduces Multi Round-Trip Requests (MRTR), which let a server pause a request mid-execution and ask the client for additional input — then resume. This is how features like elicitation work in a stateless world.

Previously, server-to-client requests (sampling, elicitation) required an open session to route back to the right client. MRTR solves this without sessions by giving each in-flight request a handle the server can reference. You get the interactivity without the stateful overhead.

For business context delivery, this matters: an agent querying company data can now ask a clarifying question mid-task and resume with the answer, without holding a persistent connection open.

Header-based routing

With sessions gone, routing metadata moves to HTTP headers. Servers and proxies can now inspect and route requests based on headers alone — no deep packet inspection of the JSON-RPC payload required.

GitHub's changelog notes this directly: they previously had to inspect request payloads for logging and secret scanning. With the new spec, that information is guaranteed to be present in headers. Simpler, faster, and easier to operate at the infrastructure layer.

This also makes load balancing and gateway routing straightforward. Any standard HTTP load balancer can distribute MCP traffic without understanding the protocol internals.

Cacheable list results

Because list endpoints no longer vary per-connection, their results are now explicitly cacheable. tools/list, resources/list, and prompts/list can be cached at the client, proxy, or CDN layer.

For high-throughput deployments — think many agents hitting the same MCP server — this is a meaningful reduction in redundant work. A company's tool catalog does not change on every request. Caching it is the obvious optimization, and the spec now formally supports it.

Authorization hardening

The spec tightens the authorization model. The official changelog notes authorization hardening as a major change alongside the stateless core.

This is worth pausing on. Backslash Security's pre-release analysis identified three new attack surfaces the spec changes introduce: the elimination of stateful sessions in favor of portable handles, the deprecation of the Roots capability, and the introduction of MCP Apps (server-rendered HTML interfaces delivered to agents). Each of these creates endpoint-layer exposure that network and gateway-based security tools will not automatically catch.

The portable handle model means a handle exfiltrated from one context could potentially be replayed in another. MCP Apps introduce a new HTML rendering surface inside the agent. Security teams should treat both as new trust boundaries requiring explicit controls — not assumptions inherited from the old session model.

Tasks and the formal extension model

The spec formalizes a first-class extension mechanism. Tasks — long-running, async operations — graduate from informal convention to a proper extension. MCP Apps (server-rendered UIs delivered to agents) are also defined as an extension.

This matters architecturally: extensions are now a defined way to add capability to MCP without forking the core spec. Expect the ecosystem to ship extensions for domain-specific needs. AWS's AgentCore Gateway already ships support for the new spec, including the extension model.

What was deprecated

The official changelog lists the Roots capability as deprecated. Roots allowed clients to expose filesystem or resource roots to servers — a capability that created trust and security complexity. Its removal simplifies the trust model.

The initialize handshake and Mcp-Session-Id header are removed entirely, not merely deprecated. If your server implementation relies on either, migration is required.

SDK and ecosystem status

All Tier 1 SDKs (TypeScript, Python, Go) have shipped beta support with backwards compatibility preserved. Per the official blog, most existing implementations do not need immediate changes to maintain support — but you should plan migration to drop legacy session handling.

GitHub's MCP Server, VS Code, and AWS AgentCore Gateway all shipped support at or before the July 28 release. This is a coordinated ecosystem rollout, not a flag-day migration.

What it means for business context delivery

If you are using MCP servers to feed AI agents company knowledge — from Slack, Notion, HubSpot, Google Drive, or any other source — the July 28 spec changes are net positive and worth understanding in three ways.

Scalability is no longer a protocol constraint. The stateful session model was the primary reason MCP servers were hard to scale horizontally. Stateless HTTP is trivially load-balanced. If your company context MCP server was a single-instance bottleneck, that architectural constraint is gone.

Faster agent connections. No handshake means agents connect and query immediately. For agents that make many short-lived context lookups — checking a deal status, pulling a recent Slack thread, verifying a customer record — the latency reduction compounds.

Security requires explicit attention. The new portable handle model and MCP Apps surface are not automatically secured by the old session boundary. Any MCP server exposing sensitive company data needs to treat handles as bearer tokens and apply authorization controls at the tool level, not just at connection time. This is especially true for MCP servers built for business context, where the data being served is confidential by definition.

Gyld's approach — permissioned knowledge (private / team / company-wide), source citations on every result, and customer-controlled indexing — maps directly onto what the new spec demands: explicit, application-layer access controls rather than protocol-layer session assumptions. You can read more about how Gyld works as the business context layer for AI and how it compares to RAG and other grounding approaches.

The practical checklist for teams running MCP servers

• Audit session dependencies. Any server code that reads Mcp-Session-Id or relies on initialize state needs to be updated. Replace with server-minted handles passed as tool arguments.
• Enable list caching. Update clients and proxies to cache tools/list, resources/list, and prompts/list responses. This is free performance.
• Review authorization at the tool level. Do not assume the connection boundary is a security boundary. Apply authorization checks inside tool handlers.
• Treat MCP Apps as an untrusted surface. If you implement or consume MCP Apps, apply the same scrutiny you would to any HTML rendered in a privileged context.
• Update SDKs. All Tier 1 SDKs have beta support. Pin to a version that includes the July 28 spec and test your server against it.
• Check handle scope. If your server mints handles for stateful operations, scope them tightly — treat them as short-lived bearer tokens, not persistent identifiers.

Key takeaways

• The MCP 2026 specification update makes the protocol stateless: no handshake, no sessions, every request self-contained.
• Multi Round-Trip Requests preserve interactivity without persistent connections; header-based routing simplifies infrastructure; list results are now cacheable.
• Security teams need to treat portable handles and MCP Apps as new trust boundaries — the old session model's implicit protections are gone.

If you want your AI agents to have real, permissioned, always-current company context served over a spec-compliant MCP server — without building or maintaining the pipeline yourself — start building your company brain with Gyld.

Frequently asked questions

What is the biggest change in the MCP July 2026 specification update?

The core change is that MCP is now stateless. The initialize/notifications/initialized handshake and the Mcp-Session-Id header are removed entirely. Every request carries its own protocol version and client capabilities in _meta fields. Servers that need cross-call state use explicit handles passed as tool arguments instead of relying on session infrastructure.

Do I need to update my existing MCP server immediately?

If your server uses session IDs or the initialize handshake, you will need to migrate. However, all Tier 1 SDKs (TypeScript, Python, Go) have shipped backwards-compatible beta support, so most implementations can continue operating while you plan the migration. Check the official changelog for the specific removals.

What are Multi Round-Trip Requests and why do they matter?

MRTR lets a server pause an in-flight request, ask the client for additional input, and resume — without holding a persistent session open. This enables interactive patterns like elicitation in a stateless architecture. For business context use cases, it means an agent can ask a clarifying question mid-task and continue with the answer.

What are the new security risks in the July 2026 MCP spec?

Backslash Security identified three new attack surfaces: portable handles (which can be replayed if exfiltrated), the deprecation of Roots (which changes the trust boundary), and MCP Apps (server-rendered HTML delivered to agents, a new execution surface). Security teams should apply explicit authorization at the tool level and treat handles as short-lived bearer tokens.

How does going stateless affect MCP server scalability?

Stateless HTTP requests can be load-balanced across any number of server instances using standard infrastructure — no sticky sessions, no shared session store required. GitHub's MCP Server removed its Redis session layer entirely after adopting the new spec, eliminating database reads on every call. Horizontal scaling of MCP servers is now straightforward.