The spec is final. The traffic isn’t.

What actually changed

Five things matter, and only one of them is mostly invisible to merchants.

• The core is stateless. MCP moved from a bidirectional stateful protocol to a request/response model. The initialize handshake and protocol-level sessions are gone; every request carries its own version and capabilities. Any request can land on any instance, so servers can be load-balanced, autoscaled and deployed on serverless or edge infrastructure like ordinary HTTP services.
• Extensions became a framework. A thin core plus optional, opt-in extensions, negotiated per request and governed by a proposal process. Tasks and MCP Apps ship as the first official extensions — long-running work through a durable task handle the client polls, and server-rendered interactive UIs.
• Routing metadata moved into headers. Requests now carry Mcp-Method and Mcp-Name, so a load balancer can route without parsing the JSON-RPC body.
• Caching became part of the protocol. Responses can carry ttlMs and cacheScope.
• There is now a deprecation policy, and Roots, Sampling and Logging are deprecated under it.

For a commerce catalog, the fourth item is the one that changes the work. Everything else is infrastructure hygiene we already had by accident: our server has never held session state between calls, because a read-only catalog has no state to hold.

Why the caching metadata is the interesting part

A catalog server has a freshness problem a filesystem server does not. Some of what it serves is stable — what a product is, which brand it belongs to, which category, which merchant sells it. Some of it is a photograph that starts ageing the moment it is taken: price with a specific variant selected, stock right now, whether it ships to a given country by Thursday.

Until this revision there was no standard way to say which was which, so every server invented its own answer. We invented ours: a provenance.fetched_at on anything that is a snapshot, an authority_mode on every offer declaring whether the number is federated-index truth or merchant-live truth, and a fields=summary projection so an agent can screen candidates cheaply before pulling detail.

ttlMs and cacheScope are the standard version of the same idea. That is worth saying plainly, including the uncomfortable half: a standard field beats a bespoke one, and where the spec now covers what we invented, the right move is to converge on the spec rather than defend our own vocabulary. The part the spec does not cover — that a cached value needs to declare not just how long it lives but whose truth it is — remains ours to carry.

What the handshakes say

We began recording the protocolVersion a client declares on 24 August 2026 at 08:28 UTC. That is the honest limit on everything below: this is a four-day window, not a trend, and we cannot say what clients declared before that date because we were not recording it.

Over those four days, excluding our own internal probes, 1,402 handshakes carried a declared version.

Three things stand out.

The field is dominated by a revision two generations old. 2025-06-18 accounts for 85% of declared handshakes and the widest client base by far, 33 distinct names. The current spec accounts for 0.7%.

One client declares a version that does not exist. There is no MCP revision dated 2026-03-26. Seven handshakes carry it. It is almost certainly a transposition of 2025-03-26 in someone’s configuration, and it is a compact reminder that a declared version is a claim, not a capability.

Nobody speaking the new spec is buying anything. The two clients declaring 2026-07-28 are mcp2-research/1.0 and hultra-link/1.0. Between them they have made 20 handshake calls to our server and zero domain calls — no search, no product lookup, no merchant listing. They initialize, list the tools, and leave. That is the signature of a registry crawler, not a shopper.

This is not a criticism of those clients; cataloguing servers is a legitimate job. It is a caution against reading version adoption as commerce adoption. They are different curves, and on our surface only the first one has started moving.

The wider ratio says the same thing more bluntly. Over the last thirty days, excluding internal probes, our public surface received 27,056 handshake and monitoring calls from 733 distinct addresses, against 2,008 domain calls from 106. Thirteen census-takers for every shopper.

What our server declares, and why

The endpoint measured throughout this article is the KaliCart Global federated commerce server, https://global.kalicart.com/mcp-public (the same server is also reachable at https://dashboard.kalicart.com/mcp-public, which is the address registered in the MCP registry as kalicart-global). It is public, keyless and read-only. It is not KaliCart MCP, which is a separate plugin exposing WordPress editorial content and has nothing to do with the catalog figures above. That server currently negotiates 2025-11-25. Offer it 2026-07-28 and it answers 2025-11-25; offer it an older revision and it mirrors that back. We say this here because we have just corrected our own documentation, which claimed 2025-03-26 — a version the server had already moved past. An article explaining a new spec while misstating its own is not worth reading.

There is a second version in this story, and it is ours too. The Bridge plugin running on each merchant’s own WooCommerce store exposes its own MCP endpoint, and its discovery document declares protocol_version: 2025-06-18 — verifiable on any live merchant, for example possedoni.it. So the single most common version in the handshake table above is also the one our own merchant-side plugin speaks. We are part of the 85%, not observers of it.

The gap between a spec going final and a server speaking it is not laziness, it is the SDK layer. The Tier 1 SDKs shipped support on publication day, but coverage across the wider ecosystem is uneven, and a public server with real consumers does not chase a revision before the clients calling it can negotiate one. The traffic above is the argument: migrating today would serve two crawlers.

What a merchant should take from this

If someone tells you your WooCommerce catalog needs to be on the newest MCP revision this quarter, ask them which of your buyers speaks it. On the evidence we can see, the answer is currently none of them.

What does matter now is the thing the new spec formalises rather than invents: an agent needs to know how long a value is good for and whose value it is. A price without a timestamp and an authority is not data, it is a rumour with a currency symbol. That was true under 2025-11-25 and it is true under 2026-07-28, and it is a catalog problem, not a protocol problem.

We will publish this measurement again when the window is months rather than days. If the ratio has not moved, that is worth knowing too.

Method note

Figures are drawn from the public usage log of the KaliCart Global federated MCP server at global.kalicart.com/mcp-public. Internal test traffic is excluded at the source. Version capture began 24 August 2026 08:28 UTC; no claim is made about declarations before that date. Our HTTP and MCP surfaces were only measured together from 27 August 2026 06:22 UTC, so the thirty-day totals are reported as a single combined figure rather than as a trend across that boundary.

Sources

• The 2026-07-28 Specification — Model Context Protocol blog
• The 2026-07-28 MCP Specification Release Candidate — stateless core, Extensions, Tasks, MCP Apps, authorization hardening
• Bringing MCP 2026-07-28 to Claude — Anthropic
• Related: WebMCP and server-side MCP: two doors, not two rivals · One week of real agent traffic on a federated catalog