MCP 2026-07-28 Specification: What Changed and What Operators Must Do

The Model Context Protocol (MCP) spec dated 2026-07-28 is the first major revision since November 2025, and it does not add a feature so much as re-plumb the protocol. If you run an MCP server or gateway in production, several things you may rely on, such as the session handshake and Dynamic Client Registration, are gone or on a deprecation clock. This guide explains what changed, what moved from the protocol onto your code, and a checklist for operators. Sources are the official MCP blog, Google's developer blog, Akamai's security research and Microsoft's November 2026 security update, all read on 7 November 2026.

What changed in MCP 2026-07-28

The MCP team's release post lists the headline changes. The spec ships a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework and updated Tier 1 SDKs. It also adds a formal deprecation policy with a twelve-month minimum window.

Practically, a stateless core means any request can land on any instance behind a plain round-robin load balancer. The MCP team says this was one of the most requested features, asked for to get better reliability and scalability.

The authorization changes you must act on

• Issuer validation: authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code (SEP-2468). This closes an authorization-server mix-up hole.
• Issuer-bound credentials: client credentials are bound to the issuer that minted them and cannot be reused across authorization servers (SEP-2352).
• Resource indicators: clients state which MCP server a token is for using RFC 8707, which addresses the confused-deputy problem (Google).
• DCR to CIMD: Dynamic Client Registration is formally deprecated. Do not build new integrations on it.

What moved from the protocol onto your code

Akamai's researchers put the trade-off plainly: the update eliminates protocol-level session hijacking, unsolicited server prompts and weak authentication methods, but application-managed state, interactive MCP Apps and long-running asynchronous tasks create new ways to abuse a server (Akamai). Their advice is to treat all client-provided state and metadata as untrusted input, to verify it cryptographically, to encode the output of AI-generated visual panels, and to set resource quotas on asynchronous tasks.

One more point from the field: as of 3 November 2026 the spec still says authorization is optional for MCP implementations, which leaves authentication and scoping to whoever deploys the server (DigitalOcean's summary). A new spec revision does not make a deployment secure by itself.

Why a signed tool is not a safe tool

A paper posted on arXiv on 4 November 2026 shows a legitimately signed MCP tool that does its advertised job while leaking data to a destination the policy allows. Across 153 attack runs, baseline defenses let unauthorized disclosure through in between 5.9% and 74.5% of runs, while the authors' data-isolated execution detected none (arXiv 2611.06585). The result is a research claim from one team, but it matches the practical lesson: authenticity of a publisher says nothing about what the code does with your data.

Vendors are moving the controls to the endpoint

Microsoft's November 2026 update says Microsoft Execution Containers are now generally available as an operating-system-enforced layer that limits what an AI agent can reach across files, networks and processes. Defender now discovers more than 50 supported local AI agents together with their configured MCP servers on Windows and macOS (Microsoft Security Blog). The direction is clear: assume the agent will be steered by hostile content, and bound what it can do.

An operator's checklist

1. Find session assumptions. Search your server code for the initialize handshake and Mcp-Session-Id use. Anything that stores state per session needs a new home, or must be passed in each request.
2. Treat request state as untrusted. Sign or encrypt any state you hand to a client, and verify it on every request.
3. Validate iss and bind tokens. Check the issuer on every authorization response and request tokens for a specific resource.
4. Plan the DCR to CIMD move. The deprecation window is twelve months at minimum, so schedule it rather than react.
5. Route on headers at the gateway. Use Mcp-Name for per-tool authorization and rate limits without parsing bodies.
6. Log per tool call. See what to log for MCP server audit trails.
7. Restrict egress and vet tools. Allowlist outbound hosts and use the malicious MCP server audit checklist before adding a server.
8. Limit task quotas. Cap runtime, concurrency and storage for asynchronous tasks.

For the organizational side, the gap between giving an agent tools and governing them is covered in the AI agent execution gap.

Frequently asked questions

When was the MCP 2026-07-28 spec released? On 28 July 2026, after a release candidate on 21 May 2026.

Is the initialize handshake still required? No. The handshake and the session header were removed in this revision.

Is Dynamic Client Registration removed? Not yet. It is deprecated and still works for backward compatibility, under a twelve-month minimum deprecation policy.

Is authorization mandatory in MCP? As of early November 2026 the spec still describes authorization as optional, so you must enforce it yourself.