↓ Skip to main content
  1. Articles/

Claude Code Now Speaks MCP 2026-07-28 by Default. Here's What That Does to Your Servers

·926 words·5 mins·
Florent Clairambault
Author
Florent Clairambault
CTO & software engineer — writing daily about spec-driven development and agentic coding

Claude Code Now Speaks MCP 2026-07-28 by Default. Here’s What That Does to Your Servers

The stateless MCP spec stopped being a roadmap item a while ago. We covered the July 28 release when it landed. What changed this month is that Claude Code now uses it by default, which means your MCP servers are being probed with the new protocol whether or not you’ve read the migration notes.

I haven’t run a before/after test against my own servers for this piece. What follows comes from the Claude Code changelog and the official MCP release post, and I flag where the sources stop.

What Claude Code changed
#

Per the Claude Code changelog:

  • v2.1.292 (Oct 6): local (stdio) MCP connections negotiate protocol 2026-07-28 by default on every install, Bedrock, Vertex and Foundry included. Set MCP_PROTOCOL_NEGOTIATION=legacy to opt out.
  • Startup behavior: stdio servers that ignore the newer protocol check are handled gracefully. After one slow connect, Claude Code remembers them for 7 days and connects the older way.
  • v2.1.295 (Oct 8): claude.ai connectors negotiate the same version by default, with the same opt-out.
  • Also in 2.1.292: MCP tools with names over 128 characters used to break every request. They are now left out, and an error names the offender.
  • Also in 2.1.295: a WebSocket MCP message over 16 MiB closes the connection, and servers that repeat a pagination cursor are no longer queried up to 20 times on connect.

The practical read: a well-behaved server that doesn’t know the new protocol should keep working, at the cost of one slow connect. The risky ones are servers that half understand it, or that depend on session state.

What the new protocol actually removes
#

The official release post describes the core change as a move to “a request/response stateless protocol”:

  • The initialize/initialized exchange and the Mcp-Session-Id header are retired. Each request carries protocol version, client identity and capabilities in _meta.
  • server/discover is a new, optional RPC for learning server capabilities up front.
  • Server-initiated elicitation/create, sampling/createMessage and roots/list are replaced by Multi Round-Trip Requests: the server returns resultType: "input_required", and the client retries with answers in inputResponses.
  • Streamable HTTP requests must carry Mcp-Method and Mcp-Name headers so gateways can route without parsing bodies.
  • tools/list, prompts/list, resources/list and resources/read responses carry ttlMs and cacheScope.
  • Roots, Sampling and Logging are deprecated but “keep working for at least twelve months.” Legacy HTTP+SSE gets a year-long offramp.

The post says the SDKs ship “detailed migration notes for the breaking bits,” and that developers who depended on session identifiers face the most migration cost. TypeScript, Python, Go and C# speak the new version; Rust is in beta.

Who should check their servers this week
#

Servers that stash state per session. If your server keeps a shopping cart, an open database cursor or an auth context keyed on Mcp-Session-Id, the new protocol takes that key away. The release post’s suggested replacement is explicit: mint a handle from a tool and have the model pass it back as an argument. That is a design change, not a flag.

Servers that call back into the client. Anything using sampling or elicitation over a held-open stream needs to move to the input_required retry pattern. These still work for now under the deprecation window, but new code shouldn’t adopt them.

Gateways and proxies. If you front MCP servers with a gateway, the Mcp-Method and Mcp-Name headers are what it should be routing on. A gateway that parses bodies still works; it just forgoes the point of the change.

Homegrown stdio servers. These are the most likely to hit the “ignore the check” path. The graceful fallback means they won’t break, but you’ll pay the slow first connect once per week unless you update the SDK.

A five-minute audit
#

  1. Update to a Claude Code build at or above 2.1.296 and start a session with your usual servers.
  2. Watch for slow first connects. A server that stalls once and is fast afterwards is probably on the 7-day “older way” cache.
  3. If something misbehaves, set MCP_PROTOCOL_NEGOTIATION=legacy to confirm the protocol is the cause. Treat that as a diagnostic, not a fix.
  4. Upgrade your server SDK to a version that speaks 2026-07-28, then remove the override.
  5. Grep for Mcp-Session-Id, sampling/createMessage and elicitation/create in your own code. Each hit is a migration item.

This is also a good moment to write down, in a spec, what each of your servers is supposed to do. A server with a clear contract is easy to port. A server whose behavior lives in someone’s head is the one that quietly breaks.

Why this is the right call
#

Making the new version the default, with an opt-out and a fallback, is how protocol migrations should work. The old approach, where clients wait for the ecosystem and the ecosystem waits for clients, is how SSE transports lingered for years. The 12-month deprecation windows give teams real runway; the default flip makes sure they start using it.

It also fits where the platform is heading: stateless servers scale behind a plain round-robin load balancer, which is what you want when agents fan out to many parallel subagents. Hook and MCP changes in the same releases (see our look at onFailure: "block") point the same way: fewer implicit assumptions, more explicit contracts.

What I couldn’t verify
#

  • The changelog doesn’t say how Claude Code detects “ignores the check,” only that the result is cached for 7 days.
  • I haven’t measured the slow-connect penalty.
  • The release post doesn’t list every breaking change; the SDK migration notes do. Read those before upgrading a production server.

Sources
#

Related