July 23, 2026 · 6 min read
The MCP 2026-07-28 Release Candidate introduces something the protocol has never had before: a formal deprecation policy. For the first time, there's a structured process for how old MCP behavior gets removed and how long you have to migrate. Here's what the policy says and what it means if you maintain an MCP server or client.
MCP launched in late 2024 as Anthropic's internal protocol, open-sourced quickly as it gained traction. The first year of the protocol prioritized adoption over stability — breaking changes were common, spec versions multiplied, and server and client developers had to stay close to the changelog to avoid being broken by updates.
That was acceptable when MCP was a niche developer tool. It's not acceptable now that MCP is infrastructure. Enterprise deployments have change management processes. Production MCP servers have uptime requirements. Organizations can't absorb breaking protocol changes on short notice without planning cycles and testing windows.
The deprecation policy is the protocol's graduation from "move fast, break things" to "move deliberately, break nothing without notice." Under AAIF governance, the policy applies to all future spec versions.
The deprecation policy has three tiers based on what's being removed:
Changes to how existing protocol features behave — semantics that change without removing the feature entirely. Examples: changing when a field is required, altering error code meanings, modifying the expected structure of a response.
Tier 1 deprecations require 12 months from announcement to removal. They must be announced in a spec changelog entry, documented with a migration path, and flagged in any tooling that surfaces spec compliance information.
Removal of a protocol feature — an entire method, a parameter, or a capability. Examples: removing initialize entirely (if that's decided in a future version), dropping a specific content type, or removing a transport option.
Tier 2 deprecations require 18 months from announcement to removal, a replacement feature (or documented rationale for not providing one), and deprecation warnings in the official SDK implementations.
Changes to the fundamental communication model — transport protocol changes, authentication model changes, or wire format changes that affect all implementations. The most disruptive category.
Tier 3 deprecations require 24 months notice and must go through a public comment period of at least 90 days before the deprecation is finalized. This ensures the broader ecosystem has a voice before a breaking change is committed.
The 2026-07-28 RC introduces its own first set of deprecations under the new policy:
initialize method — Tier 2 deprecation, 18-month notice. The initialize method is deprecated in favor of server/discover. It will continue to work for 18 months from the July 28 release date — meaning it will be removed no earlier than January 2028. Servers should add server/discover now but can keep initialize as a fallback until January 2028.
Mcp-Session-Id on stateless responses — Tier 1 deprecation, 12-month notice. Stateless MCP servers must not return Mcp-Session-Id headers. If your server returns this header on responses that don't maintain session state, you have 12 months to remove it before clients may treat it as a protocol violation.
SSE transport — Tier 2 deprecation, 18-month notice. Server-Sent Events as a primary transport is deprecated. Streamable HTTP (the current recommended transport) replaces it. The SSE transport will be removed in the spec no earlier than January 2028. Libraries that depend on SSE-only transport should plan for migration.
AAIF maintains a public deprecation registry at the official MCP spec repository. Every active deprecation is listed with:
The official MCP SDK implementations (TypeScript, Python, Kotlin, Swift) will surface deprecation warnings at build time and runtime when you use deprecated features. If you're using the official SDKs, you'll see warnings well before anything breaks.
If you're implementing MCP directly against the spec (without the official SDKs), subscribe to the AAIF mailing list or watch the spec repository for deprecation announcements. The 12-24 month windows are generous, but they only help if you know the clock is running.
If you maintain an MCP server, here's what to do before July 28:
Add server/discover. Keep initialize for backward compatibility, but add server/discover as the primary capability negotiation endpoint. New clients will use it; old clients will fall back to initialize.
Remove Mcp-Session-Id from stateless responses. If your server is stateless — no per-session context, no sticky connections required — remove the session ID header. Returning it on a stateless server is now deprecated and will be treated as a protocol violation in 12 months.
Add Mcp-Method and Mcp-Name to your CORS headers. New clients send these headers; if your CORS preflight doesn't allow them, browser-based clients will fail.
Plan SSE migration. If you're using SSE transport, you have until January 2028, but migration to Streamable HTTP is straightforward and the sooner you do it, the more clients you'll be compatible with.
A formal deprecation policy is a maturity signal. It says the protocol is stable enough that backward compatibility is worth protecting, and that the governance body is willing to slow down in order to give implementers time to migrate.
For organizations evaluating whether to build on MCP, this policy significantly reduces the adoption risk. The question used to be "will this protocol exist and be stable in two years?" The deprecation policy answers yes, with specific notice periods that give you time to plan.
For developers who've been hesitant to invest heavily in MCP because of its rapid early evolution, the 2026-07-28 spec is the right moment to catch up. The protocol has found its stable shape. The deprecation policy means the shape won't change without warning.
AgentReady's MCP endpoint supports both the current spec and the 2026-07-28 RC. Connect to Claude, Cursor, or Windsurf and query any indexed site.
Connect AgentReady →