'We speak MCP' just stopped being a differentiator and started being table stakes. The interesting news for a dev marketer isn't the stateless core — it's the deprecation clock now running under every server you've launched.
The Model Context Protocol shipped its biggest revision yet on July 28, and the headline — the protocol core went stateless — is the least interesting part for anyone marketing a developer tool. The interesting part is who lined up behind it, and the clock it just started on the MCP server you may have launched last quarter.
How it works, in one paragraph
Until this release, an MCP client and server opened a conversation: an initialize handshake, a session ID carried in a header, state held on both ends for the life of the connection. That made every server a stateful thing you had to pin a client to. The new spec throws the handshake out. There’s no initialize step and no Mcp-Session-Id header; each request carries the client’s identity, protocol version, and capabilities inline (in a _meta field), so any server instance can answer any request. In plain terms: an MCP server is now an ordinary HTTP workload. You can put it behind a round-robin load balancer, run it on serverless or the edge, and scale it like any other stateless API — no session affinity, no shared session store. Long-running work moves to a new Tasks extension (the server returns a task ID, the client polls) instead of holding a socket open.
The evidence it’s real, not just loud
The spec change is real; the more useful signal is the backing.
All four Tier-1 SDKs — TypeScript, Python, Go, and C# — shipped support on day one, with a Rust SDK in beta. The project reports “close to half-a-billion downloads a month” across those SDKs, with TypeScript and Python each past a billion total pulls. And the release landed with public statements of support from AWS, Cloudflare, Figma, Google Cloud, Microsoft, and Netlify, among others. Anthropic said MCP 2026-07-28 support is “being rolled out across Claude products,” pitching the stateless core exactly as an operations win: servers “can now deploy on serverless and edge infrastructure.”
Read those numbers honestly. Download counts are SDK pulls — a supply-side number, not deployed servers and not agent traffic. The hyperscaler list is statements of intent, not shipped integrations, and Anthropic’s own client rollout is “soon,” not done. So what’s proven here is the standard and its backers, not end-user adoption. That’s still the meaningful shift: MCP now has the shape of settled infrastructure — one operating model, four maintained SDKs, and the cloud vendors publicly committed — rather than a promising protocol with one sponsor.
The migration clock
The same release deprecated a stack of things you may be running: the old HTTP+SSE transport, Dynamic Client Registration (DCR), and the Roots, Sampling, and Logging features. Auth hardens in their place — RFC 9207 issuer validation to close authorization-server mix-up attacks, and Client ID Metadata Documents (CIMD) replacing DCR. The deprecated pieces keep working for at least twelve months; the independent Agentic AI Foundation migration write-up reads the removal window as opening July 28, 2027, and advises new implementations to “avoid them where practical” starting now.
That’s the line a dev marketer should underline. If your product already ships an MCP server, you have roughly a year to move off stateful transport and DCR before you’re on borrowed time — and how you run that deprecation is a customer-facing event, not a backend chore.
The marketing angle
Three things follow for anyone selling a developer product.
Positioning: “MCP support” just became table stakes. A year ago, shipping an MCP server was a differentiator you could put in a launch post. With four SDKs, six named platforms, and a stateless core that removes the last infrastructure excuse not to run one, that claim is converging on table stakes fast. The differentiator moves up a layer: not whether you speak MCP, but the quality of what your server exposes and how safely an agent can act through it — the same “agent-safe by design” axis this desk covered on July 26. The window to be early is closing; the window to be good is the one that stays open.
Docs and DX: your auth page is now agent-facing. With client identity and capabilities arriving per request and CIMD as the registration path, the thing an agent reads to connect to you is your integration and auth documentation. The guide’s §02 already argues a growing share of your readers are machines; MCP makes the auth flow part of that front door. A quickstart an agent can follow but an auth step it can’t complete is still a closed door.
Migration is a trust event. You have a year to move integrators off HTTP+SSE and DCR. The teams that treat that as a comms problem — a dated changelog, a codemod, a stated window, a migration guide an agent can parse — will look like adults. The teams that let it lapse quietly will generate exactly the kind of broken-integration story developers screenshot. This is the “deprecation that didn’t burn anyone” discipline (§04), pointed at a protocol you don’t control the calendar for.
What to watch next
Three open questions. Whether the stateless cutover produces a visible migration horror story — a serverless MCP deployment that silently drops state, or an integrator stranded on the old transport — the way pricing meters produce bill-shock threads. Whether “MCP-native” is still sayable as a differentiator by the end of the year, or has fully commoditized. And whether any devtool reports real agent-driven usage through its MCP server with an actual number attached — the demand-side proof the download counts don’t yet give us. When the first of those lands, the maturity story stops being about the spec and starts being about the market.