The MCP 2026-07-28 release candidate is the largest major specification revision since MCP launched. It is also a compatibility test for everyone building clients, servers, SDKs, gateways, and developer tools around the protocol.
The release candidate was locked on May 21, 2026. The final specification is scheduled for July 28, 2026. This window is the time to test real implementations and find migration pain points.
1. Check your transport assumptions
The biggest change is that MCP is now stateless at the protocol layer.
If your current Streamable HTTP implementation depends on initialize, initialized, or Mcp-Session-Id, you have migration work. In the release candidate, each request carries the protocol version, client info, and capabilities in _meta. The new server/discover method covers cases where a client needs server capabilities up front.
A tools/call request over Streamable HTTP now includes headers such as:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
That changes how infrastructure can handle MCP traffic. A gateway no longer needs to inspect JSON bodies just to route or rate-limit common operations. A load balancer can send requests to any server instance because the protocol no longer assumes a sticky session.
The compatibility question is simple: does your server still hide required state in the connection?
If yes, move that state into an explicit application handle. For example, a tool can return a basket_id, browser_id, or job handle, and the model can pass it back as a normal tool argument later. That makes state visible to the model and portable across server instances.
2. Test server-to-client request flows
Stateless MCP still needs interaction during a call. The release candidate changes how that works.
Server-initiated requests can only happen while the server is processing a client request. For elicitation, roots, or sampling flows, the server returns an InputRequiredResult, and the client retries the original call with inputResponses and requestState.
That means clients need to preserve and replay the right data. Servers need to treat the retry as a continuation, even if it lands on another instance.
A good test case is a destructive tool call that asks for confirmation. The server should return an input request, the client should collect the answer, and the retry should succeed without relying on connection memory.
3. Treat MCP Apps as real app surfaces
MCP Apps let servers provide interactive HTML interfaces that hosts render in sandboxed iframes.
This is a big developer-experience change, but it also has security and product implications. Tools can declare UI templates ahead of time, which lets hosts prefetch, cache, and review them before anything runs. The UI still talks back through MCP’s JSON-RPC protocol, so UI-driven actions go through the same consent path as tool calls.
If you maintain a host, test your iframe isolation, permission prompts, and caching behavior. If you maintain a server, check that your UI template declarations are deterministic and do not depend on hidden session state.
The Apps model will reward consistent discipline: explicit templates, clear tool boundaries, and no surprise network behavior.
4. Harden authorization now
The release candidate tightens MCP authorization around OAuth 2.0 and OpenID Connect deployments.
Clients now need to validate the iss parameter on authorization responses under RFC 9207. Authorization servers should begin sending iss now because future clients are expected to reject responses without it.
Dynamic Client Registration also changes. Clients declare OpenID Connect application_type, which matters for desktop and CLI clients using localhost redirect URIs. Clients also bind registered credentials to the issuing authorization server’s issuer.
The migration checklist here is direct:
- Verify
isshandling in clients. - Confirm authorization servers send
iss. - Check Dynamic Client Registration metadata.
- Re-register when a resource moves between authorization servers.
This is especially relevant for MCP because one client may connect to many servers. Mix-up risks are not theoretical in that shape.
5. Stop building new work on deprecated core features
Roots, Sampling, and Logging are deprecated in the release candidate.
They still work. The deprecation is annotation-only for this release, and the methods, types, and capability flags continue to work in every spec version published within a year of it. Removal would require a separate SEP.
Still, new work should move elsewhere:
- Roots should move to tool parameters, resource URIs, or server configuration.
- Sampling should move to direct integration with model provider APIs.
- Logging should move to
stderrfor stdio or OpenTelemetry for structured observability.
If you maintain SDK abstractions, this is the moment to add warnings without breaking users. If you maintain docs, stop teaching deprecated features as the default path.
6. Validate tool schemas against JSON Schema 2020-12
Tool inputSchema and outputSchema now use full JSON Schema 2020-12.
For input schemas, the root still has to be type: "object", but schemas can now use oneOf, anyOf, allOf, conditionals, $ref, and $defs. Output schemas are unrestricted. structuredContent can be any JSON value instead of only an object.
That creates opportunity and risk.
Servers should bound schema depth and validation time. Implementations should not auto-dereference external $ref URIs. Clients that made assumptions about simple object-only schemas need tests against composed schemas.
Also check error handling. The missing resource error changes from MCP’s custom -32002 to the JSON-RPC standard -32602 Invalid Params. If your client matches on the literal code, update it.
As you work through the checklist, if you find any issues or major friction points bring them to the community. You can open an issue in the specification repository. For implementation questions, the relevant Working Group channel in the contributor Discord is the fastest path to an answer.