On July 28, 2026, the Model Context Protocol project published its biggest specification revision since MCP launched: the 2026-07-28 spec. Anthropic confirmed the same day that support for it is rolling out across Claude products, noting that Claude’s connector directory now lists more than 950 MCP servers used by millions of people every day.
If you run any MCP server in your Claude Code .mcp.json — a local stdio process, a remote HTTP server behind OAuth, anything in between — this revision touches the wire protocol underneath it. None of it requires you to rewrite .mcp.json today. But it changes what “supported” will mean for MCP servers over the next several months, and it’s worth understanding before you hit a compatibility question you can’t explain.
This piece is grounded in the official MCP spec release notes and Claude Code’s own MCP reference docs. Where Anthropic hasn’t published Claude-Code-specific rollout details, this article says so rather than guessing.
The headline change: MCP drops protocol-level sessions
Every MCP spec since launch has been a stateful, bidirectional protocol. A client opened a connection, ran an initialize/initialized handshake, and got pinned to a specific server instance for the life of that session — tracked with a session identifier the server issued and the client echoed back on every request.
The 2026-07-28 spec removes that. Requests become self-contained: each one carries what a server needs to process it, without depending on a prior handshake or a server holding session state in memory.
That single change has a very practical downstream effect for anyone who runs MCP servers rather than just connects to them: a stateless server can sit behind a plain load balancer with round-robin routing, deploy to serverless or edge infrastructure, and scale horizontally without a shared session store. That wasn’t true under the old stateful model, where sticky sessions were effectively required.
For Claude Code users, this mostly matters if you maintain a remote HTTP MCP server for your team rather than consuming someone else’s. If you’re running local stdio servers (the common case for most .mcp.json entries), the stateless core is largely invisible — stdio never had the sticky-session problem to begin with, since there’s one server process per client.
Server-to-client interaction changes shape too
The old protocol let a server push follow-up requests to the client over a long-lived stream — the mechanism behind things like elicitation, where a server pauses mid-tool-call to ask the user something. Removing sessions removes the transport those follow-ups relied on.
In its place, the spec introduces an explicit InputRequiredResult a tool call can return instead of a final answer:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Delete 3 files?",
"schema": { "type": "boolean" }
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}The client collects the answer and re-issues the same call with the response and the echoed requestState attached — any server instance can pick it up, since everything needed to continue lives in the payload rather than in server memory. If you’ve built a custom MCP server with confirmation prompts or multi-step tool calls, this is the part of the migration that actually requires new code, not just a version bump.
Tasks moves out of core, as an extension
The spec formalizes an extensions framework: capabilities that used to live in (or were experimentally bolted onto) the core protocol now ship as independently versioned extensions with reverse-DNS identifiers, negotiated through an extensions map at connection time.
Two extensions matter here:
MCP Apps — servers can ship interactive HTML interfaces that render in a sandboxed iframe. Tools declare their UI templates in advance (for prefetching and security review), and the rendered UI talks back to the host over JSON-RPC, routed through the same audit/consent pipeline as any other tool call. This is the underlying mechanism for connector-backed dashboards in things like Claude Artifacts.
Tasks — moved out of core into its own extension, with a genuinely different lifecycle than its 2025-11-25 experimental version. The client advertises Tasks support as a capability; a tools/call can now return a task handle instead of a result; the client drives progress with tasks/get, tasks/update, and tasks/cancel; and the server — not the client — decides whether a given call runs as a task. tasks/list is gone entirely, since listing every in-flight task isn’t safe to expose without server-side sessions to scope it. If you built anything against the experimental Tasks API, this is a breaking change, not a compatible extension.
Auth gets six specific hardening changes
If your .mcp.json includes any HTTP server behind OAuth — which Claude Code has supported since well before this spec update — six separate proposals tighten how MCP does authorization:
| Change | What it fixes |
|---|---|
iss validation (RFC 9207) | Clients must check the issuer parameter on token responses, closing a class of mix-up attacks between authorization servers |
application_type declaration | CLI/desktop clients register as native apps during Dynamic Client Registration, so servers stop defaulting them to “web” and rejecting localhost redirect URIs |
| Issuer-bound credentials | Credentials are bound to the issuing server; clients re-register instead of reusing credentials when a resource migrates between auth servers |
| Refresh token requests | Spec now documents the request flow for refresh tokens against OpenID-Connect-style servers |
| Scope accumulation rules | Clarifies scope behavior during step-up auth and .well-known discovery |
| Error code alignment | Missing-resource errors move from the MCP-custom -32002 to the JSON-RPC-standard -32602 |
None of this changes how you configure OAuth in .mcp.json today — Claude Code’s oauth.clientId, oauth.callbackPort, and oauth.scopes fields keep working the same way. It changes what a conformant server is required to do on its end, which mostly shows up as fewer confusing auth failures against identity providers like Okta or Entra that already enforce strict issuer and redirect-URI checks.
Nothing breaks today — but there’s a clock
The spec ships a formal deprecation policy alongside the changes, and three existing features start it:
| Deprecated | Recommended replacement |
|---|---|
roots | Tool parameters, resource URIs, or server-side config |
sampling | Direct integration with an LLM provider’s API |
logging | stderr for stdio servers; OpenTelemetry for structured observability |
Anthropic and the MCP steering committee committed to keeping deprecated methods, types, and capability flags functional for at least twelve months after publication, with removal requiring a separate proposal. If none of the MCP servers in your .mcp.json use roots or sampling directly (most don’t — these are lower-level primitives most server frameworks abstract away), there’s nothing to act on right now.
What to actually do about this
If you only consume MCP servers others built (the majority of .mcp.json setups): do nothing yet. Existing stdio and HTTP servers keep working against Claude Code exactly as configured. Revisit this if a specific server you depend on announces a 2026-07-28-only rewrite.
If you maintain a remote MCP server for your team: check whether your server framework’s SDK has shipped 2026-07-28 support, and read the migration section of the spec release notes directly — it walks through removing initialize/initialized handshake logic, migrating away from Mcp-Session-Id, and adding client info to request _meta.
If your server does anything with roots, sampling, or custom Tasks-style long-running calls: start planning, even though you have a year. The Tasks lifecycle change in particular is a real rewrite, not a compatibility shim.
Keep MCP Secrets Out of Your .mcp.json
The OAuth hardening in this spec is a good prompt to check how your own MCP servers handle credentials. Never put API keys directly in .mcp.json — 1Password CLI’s op run injects secrets at runtime instead, so nothing sensitive lands in a committed config file, shell history, or a teammate’s screen share.
FAQ
Q: Do I need to update my Claude Code .mcp.json because of the 2026-07-28 MCP spec?
No. Existing stdio and HTTP server configurations keep working as-is. The spec change affects what MCP server implementations do internally, not the .mcp.json schema Claude Code reads.
Q: What does “stateless core” actually mean for a server I run myself?
Your server no longer needs to track a client session in memory or pin a client to a specific instance via Mcp-Session-Id. Each request is self-contained, which is what makes serverless and load-balanced deployments practical for the first time.
Q: Is the Tasks extension backward compatible with the experimental 2025-11-25 Tasks API?
No. The lifecycle changed — the server decides whether a call runs as a task, tasks/list was removed, and progress is driven through tasks/get/tasks/update/tasks/cancel. Anything built against the experimental version needs a rewrite to adopt the extension.
Q: How long do I have before deprecated features like roots and sampling stop working?
At least twelve months from the July 28, 2026 publication date, and removal requires a separate spec proposal after that — this isn’t a hard cutoff on a fixed date.
Q: Does this change how OAuth works in Claude Code’s /mcp panel?
Not from a user’s perspective. The six auth hardening changes tighten what conformant servers must validate (issuer checks, application type, redirect URIs). Claude Code’s existing oauth.clientId/oauth.scopes/oauth.callbackPort config fields are unaffected.
Q: Where can I verify Claude Code’s own MCP client support timeline for this spec? Anthropic’s post says support is rolling out across Claude products but doesn’t publish a Claude-Code-specific version number as of this writing — check code.claude.com/docs/en/changelog for the current state.