MCP v2 removes state: three signals we read in the spec

First, what happened. On July 28, 2026, the MCP v2 specification was released. Its biggest change fits in one sentence: the protocol goes from stateful to fully stateless. The initialize handshake and session headers are gone, and every request carries its own version, identity and capability information. Cloudflare published a post at the same time describing its part in this version. We read the spec and that post, and came away with three things that matter in practice for small and mid-sized businesses in Taiwan.

Signal one: deployment costs are falling, and the barrier to entry with them

A v1 MCP server has to maintain connection state, so it needs an environment that can remember things. With v2 stateless, it can run anywhere that answers HTTP, including the cheapest serverless platforms. Cloudflare says so plainly: servers can move from Durable Objects to ordinary Workers, which cuts complexity and cost at the same time. An evaluation used to involve connection management and choosing a host that could hold state. Now a read-only endpoint can go on the cheapest environment available, and the operational burden shrinks with it.

What this means for small and mid-sized businesses: offering an MCP endpoint is turning from an architecture project into a small job. We saw how little effort the consuming side takes when we connected Search Console to our AI workflow. With v2, the providing side gets easier too. If your systems are going to be read by AI, the technical excuses are running out.

Signal two: agent traffic becomes a first-class citizen of infrastructure

v2 adds HTTP headers such as Mcp-Method so gateways can identify the request type without parsing JSON, and it adds fields for caching hints. These design choices allow only one reading: the protocol's authors expect agent traffic to grow large enough that it needs to be cached, routed and billed. The MCP server for Cloudflare's own API already handles thousands of requests per second.

The history of search engines is a close parallel: first came crawlers, then robots.txt, then a whole SEO industry. Agent traffic is at the early stage of the same path, and how well your content and data are organized decides whether this traffic understands you or skips you. It is the same data foundation we talk about in our case studies.

Signal three: a deprecation policy means the protocol is maturing

v2 also introduced a formal feature lifecycle: deprecated features are kept for at least 12 months, and the old dynamic registration mechanism is scheduled for removal in summer 2027. Vendors such as Sentry and Linear had it in production before the spec was finalized.

When a protocol starts managing how it retires old features, that is the point at which it deserves a place in your plans.

With an early-stage protocol, the risk is rewriting everything next year. With a protocol that has a deprecation policy, changes come with timelines and migration windows. For companies still watching from the sidelines, this is a signal that it is reasonable to connect now. Not because the technology is new, but because the risk has become manageable.

Our view: do not chase versions, build readiness

To be clear about the limits: MCP v2 is not a reason for small and mid-sized businesses to start building right now. Most companies have not opened an API or written documentation, and their data still lives in spreadsheets. However much the protocol improves, it cannot read what is not there. The right order is to do the parts that will not go out of date first: structure your data, write clear documentation, think through permissions. The protocol will keep getting cheaper; readiness will not build itself. The three signals add up to a single conclusion: the direction is set, a timeline has appeared, and the price of entry is not technology. It is whether your data is in order.

Three self-checks for business owners

1. Does your product or service data have an outlet that machines can read today: an API, an export, or at least structured documentation?
2. If you had to offer a read-only MCP endpoint tomorrow, would most of the time go into engineering, or into cleaning up the data first?
3. When a vendor pitches AI integration, can you tell genuine protocol support from marketing talk?

Describe your current systems and the state of your data, and we will tell you which part to organize first, so you are ready to connect when the protocol's benefits arrive.

Book a free 30-minute intro call →