If you sell on Shopify, you already run a Model Context Protocol (MCP) server — Shopify put it there for you. On July 28, 2026, MCP ships what its own maintainers call the largest revision of the protocol since launch. That’s not just developer plumbing: MCP is the transport layer agentic shopping runs on, so this is the kind of infrastructure change that’s worth understanding even if you’ve never written a line of code for it.

What MCP is, in one sentence

MCP is the open protocol that lets an AI agent (ChatGPT, Claude, Gemini) call tools exposed by a server — search a catalog, look up a product, place an order — instead of scraping a web page and guessing. It’s the shared substrate underneath the checkout protocols merchants hear more about, like Google’s Universal Commerce Protocol (UCP): Shopify implements UCP’s product discovery and checkout as two MCP servers, a Catalog MCP (tools search_catalog, lookup_catalog, get_product) and a Checkout MCP, both served from a per-store endpoint (/api/ucp/mcp) that requires each request to carry an agent’s UCP profile (Shopify Catalog MCP docs). Put plainly: if you’re on Shopify and UCP is enabled for your store, an MCP server for your catalog and checkout is already running today.

What actually changes on July 28

The release candidate locked on May 21, 2026, giving SDK maintainers a ten-week validation window before the spec finalizes on July 28 (MCP blog — the 2026-07-28 Release Candidate). The headline items:

  • Stateless core. MCP drops the initialize/initialized handshake and the Mcp-Session-Id header. Every request now carries its own context, so “a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer” — a real operational simplification for anyone hosting an MCP server at scale.
  • Three primitives deprecated: Roots, Sampling and Logging, replaced by tool parameters, direct LLM API calls, and OpenTelemetry respectively. A new formal deprecation policy gives each a 12-month minimum window before removal is even eligible.
  • MCP Apps and Tasks. MCP Apps let servers ship sandboxed-iframe HTML UIs that hosts can prefetch and security-review ahead of execution; Tasks graduates to a governed extension so a tools/call can hand back a task handle the client polls instead of blocking.
  • Auth hardening. Six proposals bring MCP in line with OAuth 2.0/OIDC practice, including iss validation per RFC 9207.

The part that should reassure you

None of this breaks what’s live today. Beta SDKs for Python, TypeScript, Go and C# are already out, and the maintainers are explicit that “the specification’s publication date is not a switch-off for any implementers relying on the current protocol version” — new clients fall back to the legacy handshake against older servers automatically (MCP blog — SDK betas for 2026-07-28). So a Shopify store’s existing /api/ucp/mcp endpoint doesn’t stop working on July 28. What it does mean:

  • If you (or your agency) run a custom MCP server — a bespoke agent integration, not the platform-managed Shopify one — you’re the one who has to track this migration and re-test before pinning a new SDK version.
  • If you’re relying on Shopify’s built-in implementation, the platform carries the upgrade burden — one more reason platform-native UCP/MCP support is worth checking for, rather than assuming a “readiness” plugin replicates it.

Why this matters for AgentReady’s thesis

MCP is transport, not proof of purchase. A store can expose a perfectly spec-compliant Catalog MCP server and still fail the moment an agent tries to resolve a variant or complete checkout, because the underlying product data or checkout flow isn’t there. That’s the gap an AgentReady scan checks — not whether the pipe exists, but whether an agent can actually buy through it.

Sources

As of July 2026. The spec is still in its validation window — check the MCP blog for the finalized July 28 release before making implementation decisions.