DEV Community: Benji Fisher

Introducing the UCP Playground Extension: An AI Shopping Agent in Your Side Panel

Benji Fisher — Thu, 28 May 2026 10:01:33 +0000

Our first extension answered one question while you browse: is this store agent-ready? A green dot in your toolbar, fired by a single probe to /.well-known/ucp. It quietly became our biggest discovery engine.

Today we're shipping our second extension — and it answers the obvious follow-up: okay, so what actually happens when an agent shops here? — without making you leave the page.

Meet the UCP Playground — AI Shopping Agent extension. Open Chrome's side panel on any UCP-enabled store, pick a model, and an AI agent shops it live — right beside the page. It searches, compares, builds a cart, and reaches checkout, driving the store through its own published UCP tools. No screen-scraping, no separate tab.

Install it free from the Chrome Web Store →

From a green dot to a live agent

We've been building toward this in three steps.

The first extension is passive detection: one HTTP request per domain, a badge that tells you whether a store speaks the protocol. UCP Playground on the web is the runtime layer: it runs live agent shopping sessions against real stores and shows every JSON-RPC message flowing between agent and merchant — now across 16 frontier models and dozens of real stores.

The gap was the hop between them. You'd spot a UCP store while browsing, then go to a separate site to watch an agent try it. We even teased closing that gap in the first extension's write-up — "see the green dot, click Open in Playground, and you're watching Claude shop."

This extension closes it. Detection and action now live in the same tab.

What it does

A side panel, side by side. Click the toolbar icon and Playground opens in Chrome's native side panel, next to the storefront. You see the human page and the agent's run at the same time.
Chat with any UCP store. Type what you'd ask a shop assistant — "find a waterproof jacket under £100" — and the agent executes the store's UCP tools to answer.
The full tool-call timeline. Every step is visible: search, product lookup, cart, checkout — with raw responses, timing, product cards, cart state, and the final checkout URL. It's the same observability the web Playground is known for, docked beside the page.
Pick your model. Run any model exposed by your Playground account, so you can compare how different agents handle the same store.
Structured, not scraped. The extension drives the store through its published MCP tools — the exact path a real agent takes — so what you see is the protocol behaving, not a DOM hack that breaks on the next redesign.

The side panel drives the store's own UCP tools — get_product_details, update_cart, checkout — beside the page, with timing on every call.

Why a side panel

Side-by-side is the whole point. When you can see the store's own page and the agent's tool calls together, the gaps jump out: a product the agent can't resolve, an option that doesn't map, a checkout that stalls where the website sails through.

For builders, that's a debugging loop measured in seconds — validate product schemas, option resolution, and checkout flows against a live agent without wiring up anything. For merchants, it's the first time you can watch how an agent experiences your store the way a customer's assistant soon will — the same kind of run that produced the first fully autonomous UCP purchase.

Multi-item search and option resolution on Kylie Cosmetics, side by side with the store.

How it works

The first extension was pure client-side: one fetch() to /.well-known/ucp, a badge, done. This one is a thin client in front of the UCP Playground engine — your browser handles detection and display; the agent itself runs server-side. Four moving parts:

1. Detection. On navigation, the extension probes the current host's /.well-known/ucp — the same one-request check the first extension uses, with the host permission scoped to that exact path. It only ever reads the hostname to know where to look.

2. The side panel. Clicking the toolbar icon opens Chrome's native side panel (sidepanel.html) docked beside the page. The tabs permission lets the panel follow you as you move between stores, so it always knows which store to target — without touching anything on the page itself.

3. The agent runs on the Headless API — not in your browser. The extension doesn't run a model locally or scrape the DOM. It sends your message and the store's hostname to the UCP Playground Headless API, authenticated with your personal access token. Playground orchestrates the chosen model and executes the store's published MCP tools server-side — the same engine behind the web Playground and our evals — then streams the session back to the panel. That's why setup needs a free account and a token.

4. The timeline. Every step renders in order — search_catalog, get_product_details, update_cart, complete_checkout — each with its raw response, latency, product cards, cart state, and the final checkout URL. The same observability the web Playground is known for, docked beside the storefront.

Everything heavy — the model, the tool execution, the session record — lives in Playground. The extension is the lens.

What it reads — and what it doesn't

The first extension made a point of its ultra-narrow permissions; we hold the same line here, with one honest difference — a side panel that follows you across stores needs tabs to know which store you're on.

Here's the full ledger: storage (your token and settings), activeTab + tabs (the current store's hostname), sidePanel (the panel itself), and host access scoped to /.well-known/ucp plus ucpplayground.com. What it never requests: content-script access to store pages, your cookies, your history, or <all_urls>. It reads which store you're looking at, not what's on the page — and that hostname is the only thing about your browsing that ever leaves the browser.

Set up in under a minute

Install from the Chrome Web Store (Chrome, Edge, Brave — any Chromium browser).
Create a free account at ucpplayground.com.
Generate a personal access token in settings and paste it into the extension options.
Browse. It auto-detects UCP-enabled stores; click the icon to open the side panel and start shopping.

Where it fits in the stack

Each of our tools answers a different question, and now they chain cleanly from your toolbar:

Detect — the UCP Checker extension: is this store agent-ready?
Score — UCP Checker: how agent-ready is it?
Act & observe — this extension + UCP Playground: what happens when an agent actually shops it?
Monitor — UCP Alerts: did anything change?

The first extension turned passive browsing into a discovery map. This one turns it into a test bench — point an agent at any store on the web and watch the protocol work, live, beside the page.

Sources

UCP Playground — AI Shopping Agent — Chrome Web Store
Our analysis — How a browser extension became our biggest discovery engine and Why we built UCP Playground
UCP Playground at 1,000+ agent sessions — what 16 models and real stores reveal

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and — through UCP Playground — test how real AI agents behave against real stores.

Install the Playground extension: Chrome Web Store
Check your store: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
Browse the directory: ucpchecker.com/directory
Get notified on changes: ucpchecker.com/alerts

Google Opened UCP for Lodging. We Already Tested What It Needs to Handle.

Benji Fisher — Tue, 26 May 2026 09:39:24 +0000

Google has opened the door to agentic hotel booking. A new developer page — UCP for Lodging — describes an open standard to "turn AI interactions into instant bookings for room reservations." But there is no spec to read yet: the page says plainly that detailed onboarding and specs are "coming soon," and points you to a waitlist rather than documentation. This is an announcement, not a release.

That makes now the moment to write the piece nobody else has. We have already run five frontier models against expiring travel inventory and documented exactly where agents break when an offer times out mid-session. So instead of paraphrasing a waitlist, here is the prescriptive read: what UCP for Lodging will have to specify for agentic hotel booking to actually work — and what hotels should test before they integrate. Our bias throughout: we saw it in the data first.

What Google actually published — and what it didn't

The page is short on detail by design. UCP for Lodging is positioned as an open standard for "direct, instant reservations" that reduces "friction and abandonment," compatible with AP2, A2A and MCP. (New to how those layers fit together? We break the stack down here.) Two things it does not contain: a published spec, and any named partners. The only call to action is a "Join the waitlist" button.

One organizational tell worth registering: the page lives at /hotels/ucp, not /merchant/ucp where the retail protocol sits. UCP for Lodging is being driven by Google's hotels team — the group behind hotel ads — not its general commerce team. Different stakeholders, different roadmap. The travel-distribution names from Google Marketing Live — Booking.com, Expedia, Hilton, Marriott, IHG, Accor, Choice Hotels, Trip.com, Wyndham and Amadeus — are the supply context, though none appear on this page.

We covered the demand side switching on across Google's surfaces in Google Universal Cart & UCP, and why travel is agentic commerce's hardest vertical in our travel analysis. Lodging is the hardest case inside the hardest vertical.

Lodging is harder than retail — and harder than flights

A retail SKU is a fixed thing with a fixed price. A hotel "offer" is generated on the fly from a property, a room type, a rate plan, a date range and an occupancy — wrapped in a pile of taxes and fees — and it changes by the second.

The offer is a combination, not a SKU. Property × room type × rate plan × dates × guests produces a vast, dynamic offer space. There is no stable identifier to drop in a cart and trust.
Length-of-stay pricing. Three nights is not three times the nightly rate; pricing varies by date and stay length.
Rate-plan semantics. Refundable vs non-refundable, prepaid vs pay-at-property, member rates, packages — each carries different money and different rules.
Cancellation and modification policies. Free-cancel deadlines and penalty schedules are part of the offer, and getting servicing wrong has real financial stakes.
All-in price transparency. Resort fees plus city and occupancy taxes mean the nightly rate an agent sees is not the price the guest pays. An agent quoting the wrong number is a broken booking.
Perishable availability. Rooms sell out mid-session; an offer from thirty seconds ago may be gone or repriced.

What we already know breaks: the data

The perishable-availability and repricing problems are not hypothetical — we measured them. We built a mock travel server that issued offers with explicit expiry windows and ran five frontier models against it. Not one checked an offer's time-to-live before booking; only one survived a three-second expiry window; none surfaced a price change unless asked. The agents treated time-boxed travel inventory exactly like a static retail SKU.

Apply that to lodging. An agent that does not re-validate will happily "confirm" a room that sold out two minutes ago, or quote a pre-tax nightly rate as the total. Those are not edge cases in hotel booking — they are the median path.

What UCP for Lodging will need to specify

From the gaps above, here is the shortlist the spec has to cover for agentic hotel booking to be safe. Concretely, a lodging offer needs to look more like this than a retail product:

{
  "offer_id": "marriott-LHR-deluxe-king-20260704",
  "room_type": "deluxe_king",
  "rate_plan": "non_refundable_prepaid",
  "stay": { "check_in": "2026-07-04", "nights": 3, "guests": 2 },
  "total_price": { "amount": 921.00, "currency": "USD", "includes_taxes_fees": true },
  "free_cancel_until": null,
  "ttl_seconds": 120,
  "revalidate_before_booking": true
}

A lodging offer object carrying room type, rate plan, stay dates, occupancy and an all-in total (taxes and fees included), with a TTL.
Machine-readable cancellation and modification policy — deadlines and penalties as structured data, not prose.
Mandatory re-validation before booking — confirm the room is still available at the quoted total before commit.
Servicing capabilities for modify, cancel and no-show, with full request context.
Identity, loyalty and payment timing — member rates, loyalty numbers, deposits and pay-at-property.

A retail offer carries none of these. The lodging extension lives or dies on them.

What hotels should test before integrating

You cannot test against a spec that is not published yet — but you can test the thing the spec will sit on top of: your booking engine and the agents that will drive it. Before you join the waitlist and integrate:

Does your offer carry a clock? Confirm your booking engine can expose a time-boxed offer with a validity window. Validate your endpoint →
Is your price all-in? Make sure an agent can read the total with taxes and fees, not just the nightly rate. Check your catalog →
Do you re-validate before commit? An agent must be able to confirm availability and price before it books.
Are your cancellation policies machine-readable? Deadlines and penalties an agent can parse, not a paragraph of terms.
Are you fast enough? Agents abandon after roughly two seconds; the verified retail median is 156ms. How we measure →
Watch an agent break. Run a frontier model through your booking flow and see what it does when an offer expires mid-session — because our data says it will not check.

Two waves: now, and when the spec drops

The spec is "coming soon," and the language suggests weeks, not months. This piece is the first wave — the prescriptive read from the announcement and the data. When the actual UCP for Lodging spec lands, we will publish the side-by-side: what we said it needed versus what Google shipped, with conformance checks against the first live lodging endpoints. If you want that the day it is ready, set up alerts.

What we're watching

Whether the published spec models offers as time-boxed objects with all-in pricing; which waitlist partners ship a live endpoint first; whether cancellation and servicing make the first cut or get deferred; and — the one we will keep testing — whether agents stop being blind to time. We track the ecosystem monthly in the State of Agentic Commerce census, and we will report what the data shows, not what the page promises.

Sources

Google for Developers — UCP for Lodging
Google blog — Shopping updates from Marketing Live
Our analysis — Agentic AI in Travel: Why UCP Isn't Travel-Ready Yet and Google Universal Cart & UCP
Our testing — We Tested 5 AI Models on Expiring Travel Inventory

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores. We track spec and ecosystem events — retail today, travel and lodging as they arrive — as they ship.

Check your store or booking endpoint: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
Validate your catalog: ucpchecker.com/catalog-validator
Browse the directory: ucpchecker.com/directory
Get the side-by-side when the spec drops: ucpchecker.com/alerts

Lodging is the hardest booking an agent will attempt. We will be measuring it.

Retail merchant figures are live from the UCP Checker index and update every 24 hours; agent-testing methodology is on our methodology page.

Agentic AI in Travel: Why UCP Isn't Travel-Ready Yet — and What We Measured

Benji Fisher — Fri, 22 May 2026 14:51:28 +0000

In a new post, Amadeus — the system of record behind roughly 3 billion flight searches a day, 400-plus airlines and 2 million hotel properties — laid out its read on agentic AI in travel. The headline from CTO Sylvain Roy: protocols, not chatbots, are what make agentic travel work, and the protocols that exist today are not ready. MCP, he argues, is "only a first step"; the Universal Commerce Protocol "could open large new distribution and conversion opportunities" but remains "largely retail-native and is still in the process of being adapted to handle the full complexity of travel."

He is right — and we can put data behind it. Before Amadeus weighed in, we built a mock travel server with expiring offers and pointed five frontier models at it. Not one checked an offer's time-to-live before booking. Only one survived a three-second expiry window. None flagged a price change unless explicitly asked. Travel's defining feature — perishable inventory priced in real time — is precisely where today's agents fall over.

So here is the state of play from the monitoring seat: travel's supply side just showed up to UCP, but the demand side cannot reliably transact on it yet, and the protocol needs travel-specific work before it can. This is the read on agentic commerce's hardest vertical. Our bias throughout: we saw it in the data first.

What just happened: travel's supply side standardized on UCP

Two signals landed in quick succession. At Google Marketing Live 2026, Google extended UCP into hotels and local food delivery, naming a launch roster that reads like the entire travel-distribution stack: Accor, Amadeus, Booking.com, Choice Hotels, Expedia Group, Hilton, IHG, Marriott, Trip.com and Wyndham. Booking a hotel "right from AI Mode in Search" is the demo. (We covered the full package — Universal Cart, multi-item checkout, BNPL and the rest — separately.)

Then Amadeus published its position. Notably, it is not an adoption announcement. Roy frames Amadeus as the "embedded and neutral execution layer for travel" and says it is ready to collaborate on travel-ready agentic protocols — but commits to no UCP timeline. The subtext is the honest one: the supply side is interested, the rails are forming, and nobody is claiming travel is solved.

Why travel is agentic commerce's hardest vertical

Retail is, relatively, simple: a product has a fixed SKU, a stable price and a quantity. Travel has none of those guarantees. Amadeus calls out five gaps, and each is a place a retail-native protocol strains.

Dynamic offers, not fixed SKUs. A flight or room is not a catalog entry — it is a dynamically generated Offer ID built from origin, destination, dates, fare family, ancillaries and disruption rules. There is no stable identifier for an agent to drop in a cart and trust.
Perishable inventory, real-time pricing. Availability and price change by the second, with no true SKU equivalent. An offer an agent saw thirty seconds ago may already be gone or repriced.
Complex servicing. Changes, cancellations and disruption handling demand full request context, and the stakes of getting it wrong are far higher than a returned T-shirt.
Identity, settlement and regulation. Multi-party fulfillment, traveler identity verification and compliance obligations ride on every booking.
Data quality and control. Personalization needs traveler context shared across parties while suppliers keep visibility and control of it.

UCP models the retail case well — fixed catalog, cart, checkout, payment handlers. (New to how UCP sits next to MCP and AP2? We break the stack down here.) Travel needs primitives the retail spec does not have yet.

The data: agents are blind to time

The perishable-inventory and real-time-pricing problems are not theoretical. They are measurable, and we measured them.

We built a mock travel server that issued offers with explicit expiry windows and ran five frontier models against it across 21 sessions. The results were stark: not one model checked an offer's TTL before attempting to book; only one survived a three-second expiry window; none surfaced a price change unless we asked. The agents treated time-sensitive travel inventory exactly like a static retail SKU — and that is the failure mode that turns a "confirmed" booking into a charge for an offer that no longer exists.

The same blindness shows up on the retail side. Across 33 sessions on a live store, only two of five models caught a stale price even when handed yesterday's number — and the deeper problem was structural: the merchant data layer did not expose temporal metadata at all. A model cannot reason about expiry if nothing in the stack tells it the offer expires.

That is Amadeus's "perishable inventory" and "live search at scale" challenges, observed in production. The protocol that wins travel has to carry time — TTLs, price-as-of timestamps, re-validation before commit — as a first-class signal, and agents have to be built to respect it. Neither is true today.

Retail-native, not travel-ready: what UCP still needs

The encouraging part is that UCP is extensible by design. The spec grows through capability extensions — the Technical Council has been adding cart, order, loyalty and identity primitives since launch. Travel is simply the next, harder extension surface. From the gaps above, the shortlist:

A dynamic-offer primitive — an offer object carrying a TTL and a price-validity window, replacing the assumption of a stable SKU.
Re-validation in the checkout flow — an agent must confirm the offer is still valid and still the quoted price before it commits.
Servicing capabilities for change, cancel and disruption, with enough context to handle them safely.
Identity and settlement extensions for multi-party, regulated fulfillment.

Concretely, the dynamic-offer primitive looks something like this — a travel offer that carries its own clock:

{
  "offer_id": "LHR-NRT-20260612-A1F2",
  "price": { "amount": 842.00, "currency": "USD" },
  "ttl_seconds": 3,
  "price_valid_until": "2026-06-12T19:30:03Z",
  "revalidate_before_checkout": true
}

A retail SKU carries none of those fields, and that is the whole problem: nothing tells an agent the offer it is holding has already expired. None of these are exotic. They are the difference between a protocol that can sell a tote bag and one that can sell a Tokyo itinerary. And the backers are aligned to build them: the companies behind UCP — Google, Shopify, Amazon, Microsoft, Meta, Stripe and Salesforce, the group whose Technical Council recently expanded — now have the travel-distribution establishment at the table.

What it means

For travel suppliers (airlines, hotels, OTAs, GDSs): being named at a keynote is not the same as being agent-ready. The supply side is forming the rails, but the offer, pricing and servicing semantics that make travel safe for agents are not in the published spec yet. The window to shape those primitives — rather than inherit retail's — is open now, and Amadeus is signalling it wants in.

For demand-side players (agents, assistants, AI shopping surfaces): do not ship autonomous travel booking on retail assumptions. Our data says agents will book expired offers and miss price changes unless both the protocol and the agent treat time as first-class. Until travel primitives land, keep a human on the commit step.

For the ecosystem (us): we do not yet monitor live travel UCP endpoints — there are not any in production to monitor. What we can measure today is the agent side, and we have shown the gap is real. As travel manifests go live, the same validation, scoring and monitoring we run across more than 6,500 retail merchants — tracked monthly in the State of Agentic Commerce census — will extend to them. The neutral measurement layer travel is asking for is the one we already operate.

What we're watching

Whether the Technical Council opens a travel working group or a dynamic-offer extension; which of the GML travel partners ships a live, parseable endpoint first; whether Amadeus moves from "ready to collaborate" to a concrete commitment; and — the one we will keep testing — whether the next generation of models stops being blind to time. We will report what the data shows, not what the slides promise.

Sources

Amadeus — Agentic AI in travel: why MCP and UCP standards matter (Sylvain Roy, CTO)
Google blog — Shopping updates from Marketing Live
Our testing — We Tested 5 AI Models on Expiring Travel Inventory

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores. We track spec and ecosystem events — retail today, travel as it arrives — as they ship.

Check your store: ucpchecker.com/check
Grade it (UCP Score): ucpchecker.com/score
See capability coverage: ucpchecker.com/capabilities
Browse the directory: ucpchecker.com/directory
Get notified when an endpoint changes: ucpchecker.com/alerts

Travel is the hardest test agentic commerce has set itself. We will be measuring it.

Retail merchant figures are live from the UCP Checker index and update every 24 hours; agent-testing methodology is on our methodology page.

Shopify Just Shipped a UCP CLI. It Buys Anywhere — But Only Finds Shopify.

Benji Fisher — Thu, 21 May 2026 17:09:41 +0000

On May 18, 2026, Shopify published @shopify/ucp-cli to npm — a command-line tool and MCP server it describes as "a shopping skill for AI agents, powered by the Universal Commerce Protocol." Within days it's at v0.5.0, MIT-licensed, open on GitHub. The pitch, from Ilya Grigorik's launch post: millions of Shopify merchants natively speak UCP, billions of products are discoverable through a global catalog, and now any agent can learn to shop them with two commands:

npm install -g @shopify/ucp-cli
ucp skills add

The CLI shipping is not the interesting part. A reference client for a maturing protocol was always coming. The interesting part is that @shopify/ucp-cli is really two tools wearing one binary — and only one of them leaves Shopify. One layer is pure, platform-neutral UCP that will transact against any conformant merchant on any stack. The other is a discovery engine hardwired to Shopify's own catalog. Pull them apart and you get a clear read on where the protocol is genuinely open today, and where the gravity still pulls toward the platform with the biggest index.

What shipped

@shopify/ucp-cli is agent-first by design. Every command takes and returns structured JSON, so a model can compose payloads and parse results without scraping human-readable output. ucp skills add installs a bundled SKILL.md — the operating manual that teaches an agent when to search versus discover, how to render totals, how to surface required disclosures, and when to hand off to a human. The full command surface mirrors the UCP shopping service:

ucp catalog search / catalog lookup / catalog get_product — find products
ucp cart create | update | get | cancel — build a cart with confirmed pricing
ucp checkout create | update | complete | cancel — convert and pay
ucp order get — post-purchase status
ucp discover --business <url> — ask a store what it actually supports

Two design choices stand out. First, live introspection: ucp discover and --input-schema make real network calls to the merchant, not static doc lookups. The agent composes against whatever the merchant advertises right now — including extensions added since it last shopped there. Second, every response carries a cta — the CLI tracks where you are in the flow and returns the next-best commands as structured recommendations, so the agent doesn't have to memorize the operating model. There's also a configurable escalation hook (UCP_ON_ESCALATION) for the moments a merchant needs the human back in the loop.

It's a genuinely well-built piece of agent tooling. Which is exactly why the boundary inside it is worth tracing.

Two layers, two answers

The question that matters for everyone who isn't Shopify: does it work outside Shopify? The honest answer is that the CLI has two layers, and they answer differently.

The transaction layer is pure UCP

Cart, checkout, order, and per-merchant catalog operations route through the generic dev.ucp.shopping service. There is no Shopify branching in the dispatch path. When you pass --business https://store.example.com, the CLI fetches that store's /.well-known/ucp profile, negotiates a compatible protocol version and transport, and dispatches against the endpoint the merchant advertises — exactly as the spec describes. The capabilities it negotiates against are the neutral ones on ucp.dev:

dev.ucp.shopping.checkout   → ucp.dev/2026-04-08/schemas/shopping/checkout.json
dev.ucp.shopping.cart       → ucp.dev/2026-04-08/schemas/shopping/cart.json
dev.ucp.shopping.catalog.*  → ucp.dev/2026-04-08/schemas/shopping/catalog_*.json
dev.ucp.shopping.order      → ucp.dev/2026-04-08/schemas/shopping/order.json

That means a WooCommerce, Magento, BigCommerce, or fully custom store that publishes a valid UCP profile can be carted and checked out by this CLI today. The README says as much in plain language: build carts and complete checkouts "against any UCP-supporting merchant." The transaction layer is real, standards-based, and platform-neutral.

The discovery layer is Shopify

Now run ucp catalog search with no --business. Where does it go? Straight to a hardcoded default:

// package.json
"ucp": {
  "default_catalog_url": "https://catalog.shopify.com"
}

The "search across millions of merchants" headline resolves against catalog.shopify.com. And the catalog tools aren't even part of core UCP — they're surfaced through two Shopify-namespaced extensions, dev.shopify.catalog and dev.shopify.catalog.global, with schemas served from shopify.dev, not ucp.dev. The results name their sellers as *.myshopify.com domains. (The bundled skill even warns agents to check variants[*].seller.domain rather than trust the brand in a product title — a Keychron keyboard in the global catalog might be sold by a third-party Shopify reseller, not Keychron itself.)

So the asymmetry, stated plainly:

Layer	Scope	Backed by
Discovery (`catalog search`, no `--business`)	Shopify merchants only	`catalog.shopify.com`, `dev.shopify.catalog.global`
Transaction (`--business <url>`)	Any UCP merchant, any platform	generic `dev.ucp.shopping`, `ucp.dev` schemas

It can buy anywhere. It can only find Shopify. To transact with a non-Shopify store, an agent has to already know that store's URL — the CLI will happily check out there, but it will never surface the store in a search.

One smaller detail for implementers: the CLI negotiates a protocol range of 2026-01-23 to 2026-04-08 — the same dated releases — and it doesn't speak the working-draft "draft" version. Reference tooling is tracking published spec versions, not main.

Why discovery is the layer that's hard to open

This isn't a knock on Shopify, and it isn't an oversight. It's structural. A transaction is a one-to-one conversation; discovery is an index.

Standardizing a checkout means agreeing on a message shape between two parties who already found each other. UCP does that well, and the CLI proves it — point it at any conformant endpoint and it works. But standardizing discovery means someone has to build and host the index of who sells what, keep it fresh, and serve it at query time. That is expensive, and it accrues to whoever already has the catalog. Shopify has millions of merchants and their product data in one place, so a Shopify-backed global catalog is the path of least resistance — for Shopify.

The consequence is that as agent commerce matures, the transaction layer commoditizes while discovery concentrates. The protocol gives every merchant an equal ability to be transacted with. It does not, on its own, give every merchant an equal ability to be found. That gap isn't in the spec — it's in who builds the index on top of it.

What it means in practice

For Shopify merchants: you're discoverable by default. Your products sit in the global catalog an agent searches before it knows which store to visit, with no work on your part. That's a real distribution advantage, and it's the clearest argument in the launch.

For non-Shopify merchants (WooCommerce, Magento, BigCommerce, and custom stacks): your UCP endpoint works fine with this CLI — an agent that has your URL can cart and check out against you today. But you will not appear in the default catalog search. Conformance buys you transactability; it does not buy you discoverability inside a Shopify-owned index. If agent-driven discovery matters to your channel, you need to live in a catalog or directory that spans platforms — and you need your manifest to actually be valid, because an agent that can't parse your profile can't transact with you no matter how it arrived. (Run a check.)

For agent builders: treat the global catalog as a Shopify discovery surface, not a universal one. It's an excellent default for "find me X" with no merchant named. For cross-platform coverage you'll need to bring merchant URLs from elsewhere and lean on discover --business. The transaction primitives are solid and genuinely portable; the discovery primitive is platform-scoped. Plan your retrieval layer accordingly.

For evaluators (us): this sharpens why we run an independent, cross-platform directory. We index UCP merchants by verification — does this domain serve a valid, working manifest — not by membership in any one platform's catalog. The WooCommerce and Magento long tail that a Shopify global catalog structurally can't surface is exactly the part of the ecosystem we track. We measured the platform split in our readiness data and revisit it every month in the State of Agentic Commerce census; a Shopify-only discovery default is a meaningful shift in how that long tail gets found.

Where to read more

The package: @shopify/ucp-cli on npm
The source: github.com/Shopify/ucp-cli
The bundled agent skill: skills/ucp/SKILL.md
Shopify's global catalog extension: global-catalog-extension
How the three protocol layers fit together: MCP vs UCP vs AP2

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate, and grade every public UCP manifest we can find — across Shopify, WooCommerce, BigCommerce, Magento and beyond — and run the cross-platform merchant directory, the UCP Score, and the adoption stats.

If you want to know whether agents can actually transact with your store, on any platform: run a check. If you want to catch the moment your store's UCP support changes — a platform update, a spec bump, an endpoint breaking silently — set up UCP Alerts.

How to Test Your UCP Implementation with AI Agents

Benji Fisher — Fri, 15 May 2026 09:11:04 +0000

You ship a UCP manifest. The validator returns green. The schema parses cleanly. Every required field is present, every URL resolves, every transport responds. You declare the work done and move on.

Three weeks later, you find out your store has been quietly failing every agent shopping session. The cart endpoint accepts adds but rejects checkouts. A specific variant ID throws a 400 on update_cart. The agent reaches ready_for_complete and stalls because your payment handler doesn't recognise the token format. None of these issues showed up in static validation. All of them block real users on agent-mediated flows.

This post is about how to actually test your UCP implementation — not as a schema document, but as a runtime surface that real frontier agents have to operate against. The short version: schema validation is necessary but not sufficient. The long version is the rest of this post.

What validators catch and what they miss

A UCP validator (including ours, the validator at ucpchecker.com/ucp-validator) checks structural things:

Manifest is valid JSON
Required fields are present (spec, services, signing_keys, etc.)
Declared spec version is one we recognise
Transport endpoints return non-error responses
Schema URLs resolve
Capability namespaces match the spec catalogue

Those are the things you can verify without actually running an agent flow against the store. They're table-stakes, and the UCP Score bakes them into the structural-conformance dimension of its grade.

What static validation doesn't catch:

Whether update_cart rejects valid variant IDs intermittently
Whether the cart endpoint's success response contains the line items it claims to contain
Whether the checkout flow surfaces the buyer-specific payment instruments your customer can actually use
Whether your search_catalog returns more than 8 KB of HTML in a description field that crashes Claude's tool-calling layer
Whether two different models pick the same variant ID for "Medium" against your product (the variant-data problem we cover separately)
Whether the agent can recover when one of your tool calls returns a 500 mid-flow

These are runtime properties. They only surface when you run an actual agent against an actual checkout. And they're where the gap between "store passes validation" and "agent can buy" lives. The April State of Agentic Commerce report sized that gap concretely: of 4,014 verified UCP stores, only 9 delivered a flawless end-to-end agent experience. A 0.2% flawless rate against a 98%+ conformance rate. The runtime gap is the gap.

The three-layer testing pyramid

The right way to test UCP is not "validator or no validator" — it's three layers, each catching a different class of problem, in increasing order of cost and fidelity:

Layer	Tool	Catches	Cost
1. Schema validation	`/ucp-validator`	Manifest parse errors, missing required fields, malformed URLs	seconds, free
2. Capability score	`/score`	Surface signals, declared capabilities, transport reachability, robots/sitemap hygiene	seconds, free
3. Live agent eval	UCP Playground	Variant resolution, cart/checkout shape, error recovery, multi-model behaviour, attribution flow	dollars per session, paid

Each layer feeds the next. If layer 1 fails, layer 2 has nothing to score. If layer 2 reports gaps, layer 3 will find them magnified in real agent runs. Skipping layers wastes layer 3's time on bugs the cheaper layers would have caught — that's the case for running them in order rather than going straight to live agents.

Most teams stop at layer 2. Stopping at layer 2 is what produces the 99.8%-conformant / 0.2%-flawless gap. A clean Score gets you to "the agent has a fair chance." A clean Score plus a clean eval gets you to "the agent reliably completes the flow you care about."

What live agent testing actually looks like

Layer 3 is where most readers are unfamiliar, so this section walks through what running an agent test against your own store actually involves.

The shape: you point a frontier agent (Claude, GPT, Gemini, Grok, Llama — whichever model you want to evaluate against) at your store's UCP manifest endpoint and give it a multi-turn shopping prompt. The agent does what an agent does — discovers your tools via the manifest, calls search_catalog against your products, evaluates the results, picks something, calls update_cart, navigates checkout. The framework records every tool call, every response, every model decision, the full token-by-token event stream.

At the end of the session you get a structured report:

Did the agent reach checkout_reached (full transaction completion)?
Or did it stop at cart_created, search_only, or failed?
How many tool calls did it make? How many succeeded? Which ones errored?
How many tokens did the model consume?
How long did the session take?
If the agent failed, why?

That's the data layer 1 and layer 2 can't produce. Schema validation tells you what your store says; agent eval tells you what an agent does with what your store says. They're answering different questions.

For most stores, the first eval session is uncomfortable. The agent picks the wrong variant. Or it adds something to the cart and then stalls because the response shape isn't quite what it expected. Or it reaches ready_for_complete and can't move forward because your payment-handler declaration doesn't match what the agent has been trained to handle. Each of those is a fix you can make, and each fix lifts your real conversion rate the next time an actual user-facing agent shops your store.

Why testing on one model isn't enough

A useful pattern from the Playground 1,000-session dataset: the same store gets meaningfully different outcomes across different models. A store that completes checkout 65% of the time on Claude Sonnet 4.5 might complete only 18% of the time on GPT-5.2 — the same UCP implementation, the same shopping prompt, just a different model.

That spread isn't because one model is "better." It's because each frontier model has its own quirks in how it handles tool calls, schemas, error responses, and ambiguous data. Models differ on:

How they handle empty arrays vs missing fields
Whether they follow up on a 4xx response or move on
How aggressively they retry failed tool calls
How they parse multi-line strings in description fields
Whether they pass through optional metadata fields verbatim

The real-world implication: your customers don't all use the same agent. Some use ChatGPT-routed flows; some use Anthropic's; some use Google AI Mode; some use a custom agent built on Llama. Testing against just one model means catching only the bugs that one model surfaces, while shipping silent failures to everyone using a different one. Multi-model coverage is what gets you from "this passes for our internal demo" to "this works for real customer traffic."

UCP Playground supports head-to-head testing across 15+ frontier models. The comparison view lets you run the same store against any two models on the same workload. We'd suggest at minimum testing against:

One Anthropic model (Claude Opus or Sonnet)
One OpenAI model (GPT-5.2 or GPT-4o)
One Google model (Gemini 3.1 Pro or 2.5 Flash)

Three models cover most of the deployed-agent universe. If any of the three behaves badly against your store, you have a real problem worth fixing before more traffic arrives.

Wiring tests into your deploy pipeline

Manual eval is fine for one-off audits. If you're shipping changes regularly, you want this in CI. The Playground exposes a headless API for exactly that:

POST /api/v1/collections          — define a test (sequence of prompts + models + stores)
POST /api/v1/collections/{id}/run — trigger the test
GET  /api/v1/collection-runs/{id} — poll status + results

The pattern most teams ship first: a deploy-time test that triggers an eval after every UCP-related code change, asserts on key metrics, and fails the build if any of them regress. A reasonable assertion shape:

# .github/workflows/ucp-eval.yml
- name: Run UCP eval
  run: |
    curl -X POST $PLAYGROUND_API/v1/collections/$COLLECTION_ID/run \\
      -H "Authorization: Bearer $PLAYGROUND_TOKEN"
    # Poll, then assert:
    # - checkout_rate >= 80
    # - errors.total == 0
    # - avg_duration_ms < 30000

Same shape as Lighthouse CI for web performance. A regression catch you bolt onto your pipeline rather than rediscover in production. The UCP Playground Evals launch post walks through the full pattern with a worked example.

The order to do this in

If you're starting from a fresh UCP implementation:

Run the validator against your manifest. Fix any structural errors. This is the cheapest layer; do it first.
Get a UCP Score for your domain. Aim for B+ (70+) before moving to live testing. Below that, you have surface-level gaps that'll dominate the eval results and waste your test budget.
Run a Playground eval against your store with two different frontier models on a single shopping sequence. Fix whatever fails. Common first-time failures: variant-data ambiguity, response-shape inconsistencies, tool argument validation.
Expand to three models once your single-model baseline works. Multi-model coverage is what catches the long-tail issues.
Wire the eval into CI once your implementation is stable. From this point on, every code change that touches UCP runs against real agents before it ships.

If you've already got a UCP implementation in production and are trying to figure out why agents aren't completing checkouts, skip step 2 and go straight to step 3. The eval will show you the specific failure mode, and you can backfill the score work later.

What good looks like

A store that's passed all three layers cleanly looks like this:

Validator: green
Score: A grade (85+) across Discovery, Conformance, and Capability Coverage
Eval: 80%+ checkout rate against Claude Sonnet 4.5, Gemini 3 Flash, and one other model of your choice; <5s average tool-call latency; zero categorised errors across at least 20 sessions

That's the bar. The State of Agentic Commerce is tracking how many stores hit that bar — currently fewer than 1% of verified stores. The work to get from 99% conformance to 1% bar-clearing is mostly testing work.

Try it

Validator (free, instant): ucpchecker.com/ucp-validator
Score (free, instant): ucpchecker.com/score
Live agent eval (paid per session): ucpplayground.com/evals
Multi-model comparison view: ucpplayground.com/models
CI-ready eval API: documented at ucpplayground.com

Schema validation is necessary. It is not sufficient. The agents your customers use will run real flows against your store, and the only way to know whether those flows succeed is to run them yourself first.

Test before they do.

The State of Agentic Commerce — May 2026

Benji Fisher — Thu, 14 May 2026 09:45:37 +0000

In April, the story was a platform pulling a lever: Shopify migrated its entire UCP fleet to v2026-04-08 in four days, BigCommerce showed up with three stores, and we said the question for May was which platform ships next — because every prior jump in the directory had been a step function caused by a platform-level deployment.

May's answer: none, and it didn't matter. No platform shipped a UCP wave this month. BigCommerce still has three verified stores. WooCommerce still has three. Salesforce Commerce Cloud still has none verified, though a custom build is reportedly in development. And the directory still grew ~32% — the same rate as April — because the baseline discovery rate stepped up. For the first time since we started this report, UCP grew on a slope instead of a staircase.

This is the fourth monthly state-of-the-ecosystem report from UCP Checker. Here's what the data says as of May 12, 2026.

The numbers

5,294 verified UCP stores (up from 4,014 in April, +32%)
5,892 total domains tracked
1,829 new merchants discovered this month; 775 this week alone
5,264 verified stores on the latest v2026-04-08 spec (99.4%)
5,235 verified stores at A grade on UCP Score (98.9%)

Three consecutive months of ~30% growth is a real curve now, not a launch artifact. But the shape changed. February was discovery (first 1,000 Shopify stores). March was expansion (crossed 3,000, first non-Shopify manifests). April was consolidation (the four-day Shopify spec migration). May is the first month where the headline growth came from neither a new platform nor a spec event — it came from crawler optimisations we shipped in early May. The stores were always out there; we just got faster at finding them.

That distinction matters for forecasting. If May's growth had been platform-driven, you'd model the next jump as "wait for SFCC." Since it's discovery-rate-driven, the model is different: the directory keeps filling at a steady clip until either we exhaust the discoverable Shopify long tail, or a platform finally ships a wave and the staircase resumes. Both will happen; the order is the open question.

Shopify's head start, four months in

Platform	Monitored	Verified	Verified %	Avg score (verified)	Avg manifest latency
Shopify	5,242	5,241	~100%	92.5	178 ms
Custom & Headless	642	45	7.0%	83.0	356 ms
WooCommerce	3	3	100%	92.3	1,023 ms
BigCommerce	3	3	100%	88.3	993 ms
Magento	1	1	100%	85.0	218 ms
PrestaShop	1	1	100%	84.0	548 ms

Shopify is 99% of the verified directory — unchanged from April. Every non-Shopify platform combined sums to 53 verified stores, the same as last month. The head start is still the dominant signal in the data, and the Custom & Headless cohort is the mirror image: 642 domains attempted UCP, only 45 got to verified (a 7% completion rate). When a platform hands you the boilerplate, you compound; when you build it yourself, most attempts stall before validation. That's a tooling gap, not a spec problem.

The more interesting movement came from two more platforms shipping UCP support — Bareconnect and Selly.io — both of which already have verified stores live in the directory today, not roadmap promises. The numbers are still small. How either platform is exposing UCP (default for every storefront, opt-in, or a paid tier) decides whether this stays a handful or turns into a wave — that detail we don't know yet. But it's the first new platform movement since the Shopify migration.

Two structural notes on the table. BigCommerce and WooCommerce manifests run ~1 second versus Shopify's 178 ms because they're served from the storefront origin rather than a CDN-cached endpoint — a meaningful handicap as agent response budgets tighten. And geographically the directory is still a US/.com story: 4,720 of 5,294 verified stores ship under generic TLDs; the largest attributable ccTLD cohorts are .uk (229), .au (120), and .ca (66); continental Europe is under 2% by ccTLD (a floor, not a true distribution).

Capability coverage: the ceiling, and the edges

Capability	Verified adopters
`dev.ucp.shopping.checkout`	5,269
`dev.ucp.shopping.fulfillment`	5,264
`dev.ucp.shopping.catalog.lookup`	5,257
`dev.ucp.shopping.catalog.search`	5,256
`dev.ucp.shopping.order`	5,256
`dev.ucp.shopping.discount`	5,253
`dev.ucp.shopping.cart`	5,249
— the cliff —
`dev.ucp.common.identity_linking`	6
`dev.ucp.shopping.buyer_consent`	3
`dev.ucp.shopping.checkout.embedded`	2
`dev.ucp.shopping.ap2_mandate`	1
`dev.ucp.shopping.payment`	0

Identical pattern to March and April: the seven core shopping capabilities ship together as a Shopify-side bundle (~5,250 adopters each), then an 800× cliff. Identity linking: 6. AP2 mandate — the primitive that makes an agentic transaction auditably user-authorised — still 1 (houseofparfum.nl, WooCommerce, scoring 100). Payment capability: still 0. Of 5,294 verified stores, 5,161 (>99%) sit at Tier 2, one is Tier 3, one is Tier 4. The deeper primitives aren't slow-adopting, they're not adopting yet. When demand for AP2 turns into pressure (regulators, payment networks, the working group's eventual requirements), this number moves fast — the way checkout did once Shopify bundled it. Until then, "UCP store" means "agent-shoppable," not "mandate-credentialed."

Where the movement was: the edges of the spec

The new signals in May's data sit at the edges of the spec rather than its core. The first is in the capability namespace itself: below the standard dev.ucp.* entries, a handful of non-standard, vendor-prefixed capabilities are now appearing on real verified manifests:

com.pwc.accelerator.loyalty.rewards — 2 stores. PwC's agentic-commerce accelerator (more below).
com.appointedd.schedule / .booking / .intent — 1 store. Appointment-scheduling primitives — booking-vertical UCP, not retail.
com.woocommerce.ai_storefront — 1 store. A WooCommerce-specific storefront extension.
sh.agentscore.identity — 1 store. An identity primitive from a third party.
com.agoragentic.x402.checkout — 1 store. A checkout extension referencing x402 (the HTTP-402 micropayment pattern).

None is adopted at scale yet — 1–2 stores each, almost certainly vendors' own test deployments — but it's the first month the namespace long tail has held anything other than Shopify defaults. It's the leading indicator of a UCP extension ecosystem: third parties shipping vertical capabilities (loyalty, booking, identity, micropayments) on top of the core spec, a more realistic near-term diversification path than "another commerce platform ships a wave."

The PwC entry is worth pulling out, because it isn't a platform — it's a consultancy. PwC has launched an agentic-commerce accelerator: a practice that stands up custom UCP-enabled storefronts for enterprise clients, with its own capability extensions (the com.pwc.accelerator.* namespace) layered on the core spec. That's a third adoption channel, distinct from "platform ships a wave" and "developer hand-builds" — call it consulting-led. It's slower per engagement, but each accelerator that standardises on UCP arrives with a portfolio of enterprise clients attached. PwC is the leading edge; Deloitte, EY, KPMG, Accenture, McKinsey, BCG, and the systems integrators (Capgemini, IBM, TCS, Infosys) all face the same build-it-once, deploy-to-many incentive.

Transports and payment handlers: the monoculture, and the experiments tier

Transport	Verified declarations
MCP	5,258
Embedded	5,243
REST	47
A2A	2

MCP and Embedded are universal because Shopify declares both. REST shows up on 47 stores — the non-Shopify hand-builds, REST being the natural fit for anyone implementing without an MCP server. A2A (Google's Agent2Agent transport, formally added in v2026-04-08) holds at two. Payment handlers tell the same monoculture story: 5,250 verified stores declare Google Pay and 5,241 declare Shopify Card — the same shared Shopify-managed handler IDs we flagged in February as a single point of failure. Everything else is a rounding error. The payment partner ecosystem (Stripe, Adyen, Visa, Mastercard, PayPal, Affirm, Splitit — all on the registry) is mature on paper; the live handler declarations are two Shopify-managed IDs and a handful of experiments.

The experiments are the part worth zooming in on, because the same small set of builders is populating the spec's newer transport, its newer handler shapes, and its newer capability namespaces simultaneously. Both A2A adopters are agent-native rather than retail: one is an agent-identity storefront running pure A2A with a cryptographically signed manifest (JWS / EdDSA) and two custom payment handlers on crypto rails — an mpp rail on Tempo mainnet and an x402 rail on Base; the other is an agent-to-agent service exposed across MCP + A2A + REST, selling a USDC-priced audit via a com.agoragentic.x402 handler plus a direct USDC receive address. Both ship the custom capability namespaces flagged in the capability section above (sh.agentscore.identity, com.agoragentic.x402.checkout).

Separately, payment processors are starting to run dev UCP endpoints with fully custom handler integrations — their own handler IDs, their own init / verify protocol shapes, declared at v2026-04-08 over REST against real merchants, iterating against the Checker as they build. Still dev, not live, but for the first time the gap between the partner roster and the live handler declarations has something in it that's neither Shopify-default nor mock fixture — and it's coming from processors with the scale to move real merchant bases. Two data points in each direction don't make a trend, but the pattern is coherent: the spec's newer surfaces (A2A transport, custom handler shapes, third-party namespaces) are populated by a small set of builders doing novel work in parallel, while the core carries volume. That's the shape of a protocol leaving its launch phase.

How agents actually perform

The numbers above tell you which stores have UCP. This section is which stores work when an agent shops them. UCP Playground Evals passed 1,000 recorded agent sessions this month — and it's well past that now: a thousand-plus end-to-end agent shopping runs across 105 unique stores and 16 frontier models, totalling ~57M tokens, ~12 hours of cumulative agent runtime, and roughly $119,000 in aggregate cart value.

Outcomes: where the agent stops

Outcome	Sessions	Share
`checkout_reached`	475	37.9%
`search_only` (browsed, didn't cart)	344	27.4%
`failed` (provider error, refusal, max turns)	261	20.8%
`cart_created` (carted, didn't proceed)	172	13.7%

62% of sessions end without a completed checkout — and that ratio has stayed stable as the dataset grew, which is itself the finding. As we add models and stores, the shape of failure doesn't change: agents find products fine (search works nearly everywhere), build carts often, then ~14% of sessions stall at a cart that won't convert and ~21% fail outright (about half of those are variant-shape problems — the agent picks a variant ID the cart rejects and flails until it hits the turn limit). We dug into exactly that this month in UCP Variant Data: The #1 Reason Agent Checkouts Fail — the single largest categorisable cause of the gap between "has a manifest" and "agent can buy from it," and almost entirely fixable in the merchant's variant data without touching any tooling.

Model leaderboard

Checkout-conversion rate by model, from the UCP Playground model leaderboard — sessions where the agent reached a checkout URL ÷ total sessions for that model (the live leaderboard breaks out search, cart, and speed too):

Model	Sessions	Checkout %	Avg session	Vendor
Claude Sonnet 4.5	256	52.0%	~38 s	Anthropic
Llama 3.3 70B	75	49.3%	~48 s	Meta
DeepSeek V3.2	60	45.0%	~46 s	DeepSeek
Gemini 3 Flash	174	42.0%	~21 s	Google
Grok 4	53	39.6%	~77 s	xAI
Claude Opus 4.6	123	39.0%	~30 s	Anthropic
Gemini 2.5 Flash	125	36.0%	~12 s	Google
GPT-4o	63	31.7%	~15 s	OpenAI
Gemini 3.1 Pro	96	29.2%	~48 s	Google
Gemini 2.5 Pro	79	27.8%	~34 s	Google
GPT-5.2	63	20.6%	~36 s	OpenAI
DeepSeek R1	19	15.8%	~60 s	DeepSeek
o4-mini	21	14.3%	~42 s	OpenAI
Grok 3 Mini	21	9.5%	~57 s	xAI
QwQ 32B	25	0%	~61 s	Alibaba

Three things hold from April, plus one shift:

Search works everywhere. Checkout completion is the next frontier. Every model that runs to completion finds products. Checkout conversion ranges from 0% to 52% — a 50-point spread across the field, which is exactly where the work-to-do sits. The best model in the field completes checkout about half the time today; the headroom from there is the frontier the next quarter gets to push.

Reasoning-tuned models still underperform. QwQ 32B: 0% across 25 sessions. Grok 3 Mini: 9.5%. o4-mini: 14.3%. DeepSeek R1: 15.8%. Models that burn tokens on deliberation struggle with the fast, sequential, low-ambiguity tool-calling that shopping requires. Shopping rewards decisive, not thoughtful — true in April, true with 3× the data. (GPT-5.2 also lands below the median at 20.6%.)

Speed and success are decoupled. Gemini 2.5 Flash finishes a session in ~12 seconds; Grok 4 takes ~77. Their checkout rates are 36% and 40% — basically a wash. Being fast doesn't make you good at this; being slow doesn't either. The Claude models sit mid-pack on speed (~30–38 s) and top on conversion, which is the combination that actually matters when the agent is spending someone's money.

The shift: in April we reported DeepSeek V3.2 leading the composite shopping score. With ~3× the sessions, Claude Sonnet 4.5 is now clearly out front on checkout completion — 52% over 256 sessions, by far the largest sample — with Meta's Llama 3.3 70B the surprise second. Treat any single month's ranking as provisional until the eval dataset gets to the point — soon — where it stops being indicative and becomes authoritative.

The reliability gap, one more time

We've made this the editorial spine of every one of these reports, and the May data doesn't let us retire it. 98.9% of verified stores carry an A on UCP Score (5,235 of 5,294; the rest are 57 B's and two C's). By conformance, the directory is in excellent shape. But conformance isn't end-to-end agent-readiness, and that's the gap UCP Score doesn't grade.

A clean schema doesn't tell you whether the cart endpoint accepts the variant the agent picked, whether response-time budgets hold under load, whether payment-handler tokenisation completes inside the agent's timeout window, or whether the checkout URL drops the agent into an auth loop a browser would have handled with cookies. UCP Playground is the test harness developers use to exercise that second layer — replay sessions, probe edge cases, see exactly where an agent trips. By design it surfaces failure modes, not steady-state performance; treating Playground completion rates as a consumer-shopping success metric mis-reads the tool. But the categories of failure it surfaces — variant mismatch, slow tokenisation, malformed cart responses, checkout redirect loops — are real, and they're what separate an A-graded manifest from a store an agent can reliably transact against in production.

That's the gap we'd point a platform team at — and it isn't a percentage, it's a posture. The protocol's first phase, call it the first four months, was about getting the schema right, and the ecosystem did that. The next phase is the unglamorous second-order work: error recovery, schema robustness, response-time SLAs, variant-data hygiene, the long tail of edge cases that separate "manifest valid" from "agent transacts without anything tripping it up." That work is happening — the Playground sessions above are senior engineers doing exactly it. The open question is whether the posture spreads from the engineering teams already running this loop to the long tail of merchants still on bundled defaults. That's where the next quarter's competitive distance gets built.

The demand side: AI traffic is converting

For four months this report has focused on supply — which stores have UCP, what capabilities they declare, the shape of their manifests, what agents do against them in testing. On May 11 Shopify published its first real demand-side dataset, and the numbers reframe the urgency of everything above.

Across Shopify storefronts in Q1 2026, by Shopify's analysis:

AI-referred orders grew nearly 13× year-over-year. Referral sessions from AI chatbots (ChatGPT, Perplexity, Gemini, Copilot, Claude, Grok) grew more than 8× YoY.
AI-referred sessions convert at ~50% higher rates than organic search when they start on product pages.
Average order value is 14% higher for AI-referred than for organic-search orders.
More than half of AI-referred sessions start on a product detail page, vs ~20% for organic — "journey compression," the buyer arrives ready to buy because the AI did the research first.
AI-referred conversion outperforms organic SEO in 23 of 25 merchant categories.

Caveat: this is Shopify's analysis of Shopify storefronts with undisclosed methodology, so treat the precise numbers as Shopify-published rather than independently verified. But the direction is the story: agentic commerce isn't theoretical traffic any more. It's converting at premium rates, in volume, growing fast — and that's the demand signal that explains why every TC member is racing to ship at the productisation layer right now. Shopify Field CTO Sandy Jeong framed the operational work in three buckets: data readiness (machine-readable catalog with structured attributes), channel infrastructure (direct API syndication to AI platforms), and organisational alignment (a named DRI, not a committee). The teams that get those three right capture the 13× curve; the teams that don't watch it route around them.

Spec and ecosystem

Attribution landed in core. On May 5 the Technical Council merged a top-level attribution field into cart, checkout, catalog, and order operations — campaign IDs, click identifiers (gclid, fbclid, ttclid), source/medium markers, as an open string-keyed map. It's the first time advertising-and-measurement infrastructure has landed in UCP core, and the trajectory implication is the story: a protocol that carries attribution context is a protocol being built for commercial-scale deployment, not just technical demos.

The council expanded — and the regional question got sharper. Amazon, Meta, Microsoft, Salesforce, and Stripe joined the Technical Council at the end of April — a governance signal as much as an adoption one (none of the five has shipped a UCP store wave yet), but a notable one: the steering group now includes the company building the leading proprietary alternative (Amazon's "Buy for Me") and the company behind the leading rival protocol (Stripe, ACP). Convergence pressure, formalised.

Two German commerce trade publications picked up the expansion within a day of each other and used our breakdown of the 16-seat composition as a primary source: Exciting Commerce on April 27 (which drove the European enterprise retail audience UCP Alerts was built for), and Shoptechblog the next day. Both lead with the same regional point — "Keine Rolle spielen weiter europäische und asiatische Unternehmen" ("European and Asian companies continue to play no role") — and Shoptechblog adds the analytical layer: the new members sent senior engineers and architects rather than C-suite executives (implementation work, not press); each company's participation reads as defensive; and the real contest isn't the standardised protocol but the layers above it — ranking, paid placement, customer ownership. Which is exactly why attribution-in-core is more than plumbing: it's the first of those upper layers getting wired into the spec itself.

Two TC members shipped at the productisation layer. The contest moving up the stack got two concrete examples this month. On May 5 Google expanded UCP-powered checkout out of AI Mode into the main shopping section of standard Search results, with Wayfair the first live retailer on the new surface — a "Buy" button on listings inside Google Search itself, Google Pay tokenisation, checkout completing without leaving the page. Zero-click search results just became zero-click purchases. The two-track adoption story we drew in February has its first major convergence event.

Google's UCP-powered checkout flow on Wayfair: AI Mode query → product page with Buy button → Google Pay review → order complete. Source: Google.

Shopify, separately, started rolling out an Agentic Storefronts dashboard in merchant admin this week (live docs) — surfaces ChatGPT / Microsoft Copilot / AI Mode traffic, offers an "Allow Shopify to manage for me" toggle that auto-generates the AI-readability files (llms.txt, llms-full.txt, agents.md) for stores that opt in. The dashboard is protocol-agnostic: it covers ChatGPT (ACP), Copilot, and UCP-powered Search inside one admin view. UCP is one of the protocols Shopify is now monetising on the agentic-readiness layer, not the whole product. For Shopify it's the natural next step after the v2026-04-08 fleet migration; for everyone else watching the head start, it's the answer to what the next phase of it looks like.

Shopify Agentic Storefronts in merchant admin — ChatGPT / Microsoft Copilot / Shop Channel split, "Allow Shopify to manage for me" toggle, agentic-readiness checklist.

A potential spec gap, still being validated. In the variant-data guide we noted that v2026-04-08 makes variant.options[] optional even on products where product.options[] is non-empty and there are multiple variants — meaning two fully spec-compliant manifests can produce identical-looking payloads where one is unambiguous and the other is agent-unresolvable. The candidate fix would be a conditional MUST ("when product.options is non-empty and variants.length > 1, every variant MUST populate options[]"). It's a working hypothesis from one analysis, not a filed proposal — we want to sweep more of the live dataset for real-world incidence and check the edge cases (single-variant simple products, productGroup behaviour, platforms that already populate options by default) before raising it formally. If the pattern holds, it's a candidate for a future minor release.

No v2026-05. v2026-04-08 remains current. On the cadence so far, the next minor release more likely lands late summer (a notional v2026-08), probably bundling AP2 mandate refinements, schema corrections shaken out by running validators against thousands of real stores, and whatever the council formalises over the next two months. On the partner side: the registry now lists 61 merchants, 11 agents, and 8 extensions; the payment-handler roster (Adyen, Amex, Mastercard, Stripe, Visa, Checkout.com, Affirm, Splitit, PayPal) is unchanged and still almost entirely unrepresented in live manifest declarations.

What we shipped — and what developers are doing with it

UCP Variant Data: The #1 Reason Agent Checkouts Fail — the five variant-data anti-patterns, what clean variant data looks like, and the spec gap that lets compliant stores still be broken.
How to Test Your UCP Implementation — the three-layer validation workflow: static audit, live agent test, continuous monitoring.
UCP Score is doing exactly what it was built to do. This is the one we're proudest of this quarter. The Score turns "is my manifest agent-ready?" into a concrete, category-by-category checklist — and developers are using it that way: we've watched a failing manifest climb to an A grade in the space of a few hours, the developer iterating against the score breakdown between checks. That's the loop it was designed for, and it's now the loop it runs.
UCP Playground got sharper as a development tool. Two halves of the same loop: the agent-inspection tooling — replay any session, see the exact tool call where an agent tripped — and the runtime shopping evals, now past 1,000 recorded sessions and more than 12 hours of cumulative agent runtime against real stores. Together they take the build → test → fix cycle for an agent-ready storefront down from a sprint to an afternoon. Every improvement that got us there is in the changelog.
Crawler throughput — we roughly tripled the hourly crawl rate in early May (and added per-IP and global throttles to the expensive public routes so the directory stays fast under load). That's what moved the discovery curve this month.

What to watch in June

Second adopters at every edge. May produced first adopters across multiple novel patterns — non-Shopify platforms shipping UCP (Bareconnect, Selly.io), a consultancy-built accelerator (PwC), non-default payment-handler integrations (the processors in dev), AP2 mandate (still one), third-party capability namespaces (each at 1–2 stores). The diagnostic for June is whether any doubles up. Each is a distinct watch item; the meta-question is the same: did May's first adopters survive contact with month two?

Google's next live partner on main Search. Wayfair is first up on Google's UCP-checkout expansion into standard Search results. The other co-developing TC retailers — Etsy, Target, Walmart — are the next-most-likely to follow. The cadence of those rollouts is the diagnostic for how fast Google is willing to push agent-completed transactions onto its highest-traffic surface.

The platform-level integration question. SFCC, Adobe Commerce, Wix, Squarespace — any of them shipping a platform-level UCP integration is still the single highest-impact possible event, and still hasn't happened. The one-platform structure is four months old.

Whether the eval leaderboard holds its shape. Claude Sonnet 4.5 leads checkout completion on the largest sample; Llama 3.3 70B is the surprise second. Another month of sessions either confirms that or reshuffles it.

Sources

All data is from the UCP Checker crawler (re-checks every tracked domain at least every 24 hours) and UCP Playground's eval sessions, as of May 12, 2026. The verified-merchant dataset is published monthly on Hugging Face under CC-BY 4.0; the same data, a public REST API, the bulk checker, and the rest of our developer tools are all ungated.

Browse the directory: ucpchecker.com/directory
Track adoption live: ucpchecker.com/stats
Run a UCP Score: ucpchecker.com/score
Model + store leaderboard: ucpplayground.com/evals
Public dataset, REST API & developer tools: ucpchecker.com/developer-tools
Previous report: State of Agentic Commerce — April 2026

External coverage cited in this report:

Jochen Krisch, "Amazon schließt sich Googles Universal Commerce Protocol an," Exciting Commerce, April 27, 2026
Roman Zenner, "Agentic Commerce: Das UCP Council wächst," Shoptechblog, April 28, 2026
Google expands UCP Checkout to main Search shopping results, Search Engine Land, May 2026
New tech and tools for retailers to succeed in an agentic shopping era, Google blog (Ads & Commerce)
Shopify Agentic commerce developer docs — Agentic Storefronts, llms.txt, llms-full.txt, agents.md reference
What Shopify checks for agentic readiness, WISLR Research
Kyle Risley, "AI-referred shoppers convert better and spend more (2026)", Shopify Enterprise Blog, May 11, 2026

UCP Variant Data: The #1 Reason Agent Checkouts Fail

Benji Fisher — Wed, 13 May 2026 11:12:54 +0000

A user asks an AI shopping agent for "a medium grey t-shirt." The agent finds the product. It picks a variant. It adds it to the cart. The merchant rejects the cart. The agent retries with a different variant. The merchant rejects that one too. The session ends in cart_created without a checkout — the user's $40 purchase quietly disappears, and nobody on the merchant side ever sees the failure.

This pattern is the single largest source of agent checkout failures we see across the 4,500+ verified UCP stores in the directory. More than schema invalidity, more than tool errors, more than payment-handler problems. Variant mismatch — the agent and the merchant disagreeing on which SKU corresponds to "Medium" — is responsible for a meaningful fraction of the gap between "store has a UCP manifest" and "agent can actually buy from it."

The good news: it's almost entirely fixable on the merchant side, in your variant data structure, without changing any tooling. This post walks through the failure pattern, the five most common variant data anti-patterns we observe, and what clean variant data looks like in practice.

Anatomy of a variant mismatch

Here's the cleanest way to see the failure:

Two frontier agents — call them Agent A and Agent B — get the same prompt against the same store: "Add a medium grey t-shirt to my cart." Both agents call search_catalog, both get the same product back, both see three variants:

{
  "variants": [
    {"id": "var_5571", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Small"}]},
    {"id": "var_5572", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium"}]},
    {"id": "var_5573", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Large"}]}
  ]
}

Agent A picks var_5572. Agent B picks var_5572. Both add to cart. Both succeed. Clean data, predictable behaviour. Each variant declares its options as an array of {name, label} pairs — the spec's selected_option shape — so the agent matches "medium" against the Size axis unambiguously.

Now the broken version. Same prompt, same product, but the variant data looks like this:

{
  "variants": [
    {"id": "var_5571", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "S"}]},
    {"id": "var_5572", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "M"}]},
    {"id": "var_5573", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "L"}]},
    {"id": "var_5574", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium / Regular Fit"}]},
    {"id": "var_5575", "options": [{"name": "Color", "label": "Grey"}, {"name": "Size", "label": "Medium / Slim Fit"}]}
  ]
}

Agent A picks var_5572 (interpreting "M" as the canonical "Medium"). Agent B picks var_5574 (interpreting "Medium / Regular Fit" as the more explicit match). Neither is wrong. The user said "medium" and both interpretations are defensible. But because the variant data conflates two different axes — size and fit — into a single Size label, the two agents diverge, and the user's experience depends on which model they're using. The spec form makes the bug obvious: Fit should be its own selected_option, not crammed into the Size label.

Worse: many real implementations don't even include the option labels. They expose only opaque variant IDs:

{
  "variants": [
    {"id": "var_5571"},
    {"id": "var_5572"},
    {"id": "var_5573"}
  ]
}

Now the agent has no way to know which variant corresponds to "Medium" at all. It guesses. Sometimes it guesses right. Often it doesn't. That's how checkout sessions end up in cart_created without ever reaching checkout_reached.

Why this is the #1 failure mode

Across the Playground session dataset, roughly 62% of sessions end without a completed checkout. The breakdown is informative:

Outcome	Share
`checkout_reached`	38%
`search_only` (browsed, didn't add)	27%
`failed` (provider error, model refusal, max turns)	22%
`cart_created` (added, didn't proceed)	13%

The cart_created cohort — sessions where the agent successfully picked something but couldn't finish — is the variant-mismatch signal. The agent had enough information to add to cart but the cart contents weren't valid for checkout. That's the structural shape of "wrong variant picked."

Roughly half of the categorised failed sessions are also variant-shape problems — the agent picked a variant ID that the cart endpoint rejects, retried with another, hit max_turns_exceeded while flailing through the variant list. Add those in and variant-related failures account for somewhere around a fifth of all sessions, which is more than any other categorisable failure mode.

The thing that makes this pattern so consistent: clean variant data is not part of UCP Score or schema validation. A store can pass UCP Score at A grade and still emit variant data that breaks every agent in the field. The validator looks at whether the manifest parses; it doesn't look at whether the variants are agent-resolvable. That gap is exactly why this post exists.

A spec gap that compounds the problem

Even when a store is fully UCP-compliant, the protocol leaves room for ambiguity. The 2026-04-08 schema makes variant.options[] optional — including on products where product.options[] is non-empty and there are multiple variants. So a payload like {"options": [{"name": "Size", "values": [{"label": "Small"}, {"label": "Medium"}]}], "variants": [{"id": "var_a"}, {"id": "var_b"}]} is technically valid but agent-unresolvable: nothing links var_a to "Small" rather than "Medium." Two consumers looking at this payload can defensibly pick different variants for the same prompt.

A conditional MUST in the spec — "when product.options is non-empty and variants.length > 1, every variant MUST populate options[]" — would close this cleanly. Until that lands, agent-resolvability is on the merchant rather than the protocol.

The five variant anti-patterns

In rough order of frequency observed across the dataset:

1. Opaque variant IDs with no option metadata

The shape from the third example above — variants exposed only as var_5572, no options, no attributes, no human-readable axis. Agents have no way to map a user's "Medium" to a specific ID. They either guess or pick the first variant, both of which produce wrong outcomes routinely.

Fix: every variant must carry the axis values that distinguish it from siblings, in the spec's selected_option array form: "options": [{"name": "Size", "label": "Medium"}, {"name": "Color", "label": "Grey"}]. The name field tells the agent which axis the value belongs to; label is what gets matched against the user's request. Whatever the product's options page shows to a human shopper — size, colour, material, fit — the variant data should expose programmatically with one selected_option entry per axis.

The corollary: descriptive attributes that aren't selection axes belong in metadata, not product.options[]. A one-variant simple product with "Color: Gray" should expose Gray as metadata.attributes, not as a single-value product.option — otherwise consumer UIs render a one-button picker that looks selectable but isn't. The split: product.options[] is for axes the buyer chooses across; metadata is for descriptive properties of the (only) variant.

2. Conflated axes in a single string

The shape from the second example — "Medium / Regular Fit" as a single option value where size and fit are two separate user choices. Agents can parse this, but inconsistently across models, because the conflation is ambiguous. Different models split the string differently, and the variant they end up picking depends on which side of the slash they prioritise.

Fix: each variant attribute lives in its own field. Don't compose. If your product has size + fit as two axes, the variant data should look like:

{
  "id": "var_5574",
  "options": [
    {"name": "Size", "label": "Medium"},
    {"name": "Fit", "label": "Regular"}
  ]
}

Two clean axes, two unambiguous values, no string parsing required. Agents pick consistently. The array-of-selected_option form is the shape UCP 2026-04-08 defines for variant.options — see selected_option.json.

3. Inconsistent labelling between sibling variants

Not all variants on the same product use the same option vocabulary. One says "M", another says "Medium", another says "med". We see this on stores that have grown organically — different teams added variants over different years, naming conventions drifted, the inconsistency is invisible to the merchandising team because the storefront UI hides it.

Fix: one canonical label per axis value, applied consistently across every variant on every product. If "Medium" is the canonical label, every Medium variant uses exactly "Medium". No "M", no "med", no "Medium " (trailing space). Agents reason by string match; consistency is what makes the match reliable.

4. Missing or inconsistent stock / availability flags

A variant exists in the catalogue but is sold out, and the variant data doesn't say so. The agent picks it, the cart accepts the add, the checkout endpoint rejects it. The agent doesn't know to retry with a different variant — it had no signal that the variant was unavailable.

Fix: every variant declares its availability object — {"available": true, "status": "in_stock"} is the spec shape, with well-known status values in_stock, backorder, preorder, out_of_stock, and discontinued. Agents skip unavailable variants if you tell them to, and status gives them enough signal to decide whether to wait, substitute, or surface an out-of-stock message to the user.

5. Declared axes that variants don't honor

product.options[] declares the selectable axes; variants[] is the universe of actual purchasable combinations. When the cardinality of declared axes doesn't match what variants actually carry — e.g., product.options declares Color × Size = 9 combinations but only 3 color-only variants exist — agents try to satisfy a Size selection that no variant honors. Strict consumers return null and refuse to add; lenient consumers guess and pick wrong.

Fix: keep product.options[] and variants[] in sync. Either every declared axis combination has a corresponding variant, or the axis shouldn't be in product.options[]. If sizes aren't actually configurable for this product, drop Size from the axes; don't leave it dangling.

What clean variant data looks like

Here's the shape that resolves cleanly across every frontier model we test:

{
  "id": "prod_42",
  "title": "Heavyweight Crew Tee",
  "description": "Heavyweight cotton crew-neck tee.",
  "price_range": {
    "min": {"amount": 4500, "currency": "USD"},
    "max": {"amount": 4500, "currency": "USD"}
  },
  "options": [
    {"name": "Color", "values": [{"label": "Charcoal"}]},
    {"name": "Size",  "values": [{"label": "Small"}, {"label": "Medium"}]},
    {"name": "Fit",   "values": [{"label": "Regular"}]}
  ],
  "variants": [
    {
      "id": "var_5571",
      "title": "Charcoal / Small / Regular",
      "description": "Heavyweight crew tee, charcoal, size small, regular fit.",
      "price": {"amount": 4500, "currency": "USD"},
      "availability": {"available": true, "status": "in_stock"},
      "options": [
        {"name": "Color", "label": "Charcoal"},
        {"name": "Size",  "label": "Small"},
        {"name": "Fit",   "label": "Regular"}
      ]
    },
    {
      "id": "var_5572",
      "title": "Charcoal / Medium / Regular",
      "description": "Heavyweight crew tee, charcoal, size medium, regular fit.",
      "price": {"amount": 4500, "currency": "USD"},
      "availability": {"available": true, "status": "in_stock"},
      "options": [
        {"name": "Color", "label": "Charcoal"},
        {"name": "Size",  "label": "Medium"},
        {"name": "Fit",   "label": "Regular"}
      ]
    }
  ]
}

Four spec fields make this work:

product.options at the product level — declares the axes (Color, Size, Fit) and their valid values as an array of product_option {name, values: [{label}]}. Agents know upfront how many dimensions a variant occupies and what values are valid on each axis.
variant.options as an array of selected_option {name, label} — each axis has its own entry, no string parsing, no conflation. The name matches the product-level axis; the label matches the user's request.
variant.availability with available and status — agents skip unavailable variants without trial-and-error, and status (in_stock, backorder, preorder, out_of_stock, discontinued) gives them enough signal to wait, substitute, or surface the right message.
Required scaffolding — id, title, description, and price on every variant, and id, title, description, price_range, variants on the product. These aren't "nice to have"; they're the schema's required fields. Variants missing any of them won't validate.

Bonus stability: when present, option_value.id and selected_option.id give stable identifiers that survive label drift. If your platform supports it (most do — Shopify uses GIDs, WooCommerce uses pa_* taxonomy slugs), populate id alongside label and consumers can match on the stable key when labels change.

Stores running variant data in this shape resolve user prompts to specific variants reliably across every model we've benchmarked. The pattern isn't novel — it's the same shape Shopify uses internally, the same shape WooCommerce variations use when properly structured, the same shape every traditional e-commerce platform ends up at after enough years of evolution. UCP just exposes it programmatically to the agent layer.

How to validate your variant data

Three layers, in order:

1. Static audit. Run your store through UCPChecker. The validator surfaces variants with missing options data, conflated axes, inconsistent labels across sibling variants, and missing availability flags. None of this is part of strict UCP-spec conformance, but our methodology flags variant-quality issues as part of the Capability Coverage score because they materially affect whether agents can transact.

2. Live agent test. Run a multi-model agent session against your store via UCP Playground. The framework exercises the full search → variant-pick → cart → checkout flow against frontier agents across 15+ models. If your variant data is ambiguous, you'll see different models pick different variants for the same prompt — the exact pattern we walk through in the Playground 1,000-sessions analysis.

3. Continuous monitoring. Variant data changes over time as you add products and SKUs. Set up UCP Alerts so you get notified when a variant audit starts surfacing new issues — typically a sign that a recent merchandising change introduced inconsistent labelling at scale.

The order matters. Static audit catches the easy cases (missing fields, schema-shaped problems) cheaply. Live agent test catches the cases where the schema is fine but agents disagree (the conflated-axis cases, the inconsistent-label cases). Monitoring catches drift over time. Skipping any of the three leaves a class of variant problems undetected.

What to fix in your store, and how to verify it

If you're a merchant reading this and your store is running on Shopify, WooCommerce, BigCommerce, Magento, or PrestaShop, the variant data structure is mostly determined by your platform's defaults. The platform-specific fixes are documented in the platform guides — but the meta-pattern is the same:

Audit at ucpchecker.com/check — get a list of variant-data issues
Fix the most common one first (usually missing options metadata)
Test at ucpplayground.com with two different models against the same product, asking for the same variant
Verify that both models pick the same variant ID consistently
Monitor weekly — variant drift is the most common reason a store's UCP Score regresses

Variant data is a back-office data-quality problem dressed up as an agentic commerce problem. The fix is mostly editorial — get your axis labels consistent, expose your option values structurally, mark sold-out variants as such. None of this is technically hard. It's the kind of work that adds up to "agents can buy from your store" rather than "agents try to buy from your store and quietly fail."

If you fix one thing on the agent-readiness side this quarter, fix variant data. The conversion lift is bigger than any other single change you can make.

One thing worth naming: consumer tools that silently paper over variant data problems (substring matching, positional guessing, falling back to variants[0]) make this worse, not better. They hide the failure mode from merchants who would otherwise see it and fix the data. Faithful rendering — null when the match is ambiguous, errors when the data is inconsistent — is what produces correct merchant behaviour. If your variant data only works in some agents, that's a signal the data is the problem, not the agent.

Try it

Audit your variants now: ucpchecker.com/check — flags variant issues alongside the rest of the UCP Score
Test variant resolution with real agents: ucpplayground.com — run two models against your store on the same prompt, see if they pick the same variant
Read the broader failure-mode taxonomy: Common UCP Errors and How to Fix Them
Track ecosystem-wide variant adoption: State of Agentic Commerce — April 2026

The UCP Technical Council Just Shipped Attribution into Core. Here's What That Means.

Benji Fisher — Wed, 06 May 2026 07:43:57 +0000

On May 5, 2026, the UCP Technical Council merged PR #391 into the spec's main branch — adding a top-level attribution field to cart, checkout, catalog, and order operations. The field carries platform-emitted referral and conversion-event context: campaign IDs, click identifiers (gclid, fbclid, ttclid), source/medium markers. Open string-keyed map. Universal across requests; not gated by capability negotiation.

As UCP matures, attribution landing in core was always going to happen. Agentic commerce can't operate as commercial infrastructure without a path for advertising and measurement context to flow alongside the transactional data — and the longer that gap stayed open, the more pressure would have built for vendors to ship incompatible parallel solutions. The merge isn't the surprising part. The interesting part is the specific shape of what shipped, and what its presence in core tells us about where the spec is heading.

Two things to dig into: the technical detail of the field itself, and the trajectory implication of advertising and measurement infrastructure landing in UCP core for the first time.

What shipped

The attribution field is structurally simple. From Grigorik's own example in the PR:

{
  "attribution": {
    "campaign_id": "18234567890",
    "campaign_source": "google",
    "campaign_medium": "cpc",
    "campaign_name": "spring_2026",
    "gclid": "EAIaIQobChMI..."
  }
}

No prescribed schema beyond "string-keyed object." Platforms populate it with whatever conventions they already use — GA4 campaign parameters, click identifiers, custom tracking keys. Businesses receive the data and process per their own analytics needs. UCP itself does not prescribe attribution windows, models, or assignment logic. The protocol carries the data; attribution math happens downstream.

The field appears in three roles across the request lifecycle:

Operation	Role	Direction
`catalog` (search, lookup)	Platform-emitted input	Platform → merchant
`cart`	Platform-emitted input	Platform → merchant
`checkout`	Platform-emitted input	Platform → merchant
`order`	Business-emitted snapshot	Merchant → platform

The asymmetry matters. On catalog/cart/checkout, the platform writes attribution as it would write a UTM string into a browser URL — referral context flowing forward. On order, the business preserves the originating attribution as a snapshot — closing the loop between agent-mediated conversion and the platform that produced it.

Grigorik's framing in the PR is the cleanest one-line summary of intent: the field "carries the same parameters platforms communicate via URL query parameters in browser-based flows, in the same flat key-value form." Attribution in agent-mediated commerce is the agent counterpart of UTM strings. Same parameters, same model, different transport layer.

Thirteen files changed. The core addition is source/schemas/shopping/types/attribution.json — the new type definition. Schemas for cart, catalog_lookup, catalog_search, checkout, and order all gain the field as an optional property. Specification docs across cart, catalog, checkout, order, and the overview were updated to describe the field's purpose and semantics.

The architectural decision: core field, not extension

The substantively interesting part of this PR is not what got added. It's how it got added.

PR #391 was Grigorik's alternative proposal to PR #295, which James Andersen had opened earlier proposing an event_context extension. Both proposals tried to solve the same problem — give platforms a way to pass referral/attribution data through to merchants in agent flows — but with very different architectural shapes:

#295 (Andersen, Meta): Attribution as a structured extension. Capability-negotiated. Validated against a defined schema. Standardised vocabulary across platforms.
#391 (Grigorik, Shopify): Attribution as a top-level core field. Open key-value map. No capability negotiation. Each platform uses its own conventions.

Andersen formally approved Grigorik's alternative — "thanks for finding a better home for attribution data than the original proposal" — and the rearchitecture went on to merge through TC discussion. That cross-vendor pattern (one TC member proposes; another offers a structurally different alternative; the original proposer endorses it) is the dynamic that produces robust standards rather than fragmented vendor extensions.

The PR discussion pivots on which architectural shape this kind of data deserves. Amit Handa wrote the canonical comment on May 3 establishing the decision framework — worth quoting because it'll likely be cited as governance precedent in future spec discussions:

Criterion	Use a UCP Extension	Use Optional Flat Key-Value Pairs
Impact on Behavior	Changes state or execution of the operation	Purely informational
Data Stability	Stable, standardized vocabulary	Volatile, platform-specific, rapidly evolving
Capability Negotiation	Requires mutual agreement + active parent capability	Best-effort, consumed at-will, no gating
Schema Validation	Strict — transaction integrity matters	Flexible — validation happens downstream
Multi-Platform Scale	Data normalization across diverse platforms	Low friction; normalization burden on receiver
Typical Examples	`discount`, `fulfillment`	`attribution`, referral tracking, session tags

Attribution falls cleanly on the right side of every row. Marketing identifiers (gclid, fbclid, ttclid) are volatile and platform-specific — every adtech vendor invents their own; standardising them in the spec would be obsolete the moment a new platform launches. Attribution doesn't change protocol behaviour — it's read-only context that some downstream pipeline cares about, with no transactional consequence. There's nothing for a merchant to negotiate; either you record it or you don't.

The merged PR locks this decision in. Future contributors proposing similar volatile, informational, platform-specific data structures now have a precedent: the spec prefers flat optional key-value pairs over structured extensions for non-state-changing context. That's a piece of governance documentation as much as a feature merge, and Handa's table will be the reference for it.

The trajectory implication

UCP up to this point has been protocol mechanics. How agents discover stores. How they shop. How they pay. How they identify users. How they handle returns. The mechanics are necessary, but they don't directly produce commercial value for the ecosystem participants. A merchant with a perfectly conformant UCP implementation but no attribution can't measure agent-driven conversions, can't optimise marketing spend, can't close the loop between platform investment and merchant outcomes.

attribution closes that loop. With the field in core, the entire adtech infrastructure that powers current ecommerce extends naturally into agent-mediated commerce. Platforms attribute conversions to specific campaigns. Click identifiers persist across the agent flow. Businesses run their existing analytics pipelines on agent-driven traffic with no special handling. The bridge that makes UCP commercially usable for marketing teams — not just engineering teams — now exists in the core spec.

The trajectory implication is the part worth sitting with: UCP is evolving from protocol mechanics into commercial infrastructure. Each subsequent spec addition probably bridges another piece of existing commerce infrastructure into the agent layer. Loyalty programs. Customer data platforms. Marketing automation triggers. Inventory hooks. Each one makes UCP more complete as commercial infrastructure rather than just protocol mechanics.

The architectural-precedent decision in #391 makes that trajectory more efficient. Future contributors proposing similar bridges (attribution-adjacent measurement primitives, marketing identifiers, session metadata) now have a clear template: flat key-value pairs into core, governance precedent already established. The spec doesn't need to relitigate the core-vs-extension decision every time a volatile, informational primitive comes up.

What it means in practice

For merchants: your UCP implementation should accept the attribution field on incoming cart, checkout, and catalog requests, preserve it through to order records, and surface it through your analytics pipeline. The lift is small — it's a string-keyed JSON object on existing endpoints — but missing it means agent-driven conversions arrive at your analytics with no source attribution, which means your marketing team can't measure the channel.

For platform vendors (Shopify, WooCommerce, BigCommerce, Magento, and others): rolling attribution support into the next platform-side compatibility release is now table-stakes work. The stores running on your stack will need to accept and preserve attribution by the time the next published spec version makes this part of conformance.

For agent platforms (those of us building or testing agents that shop UCP stores): pass platform-emitted attribution forward into every cart/checkout/catalog request. The data is informational, not state-changing — your agent doesn't need to do anything with it beyond passing it through. The merchant decides what to do with it on the receive side.

For evaluators (us): the UCP Score will incorporate attribution-acceptance and attribution-preservation conformance in its next release. A store that accepts attribution on cart/checkout/catalog and threads it through to order records will score higher than one that drops it. The methodology page will reflect the rule update when the next score-version drops.

Timing: in core today, in the published spec next

One important distinction worth making explicit. PR #391 merged into the spec's main branch — not into a currently-published spec version. The latest released spec is v2026-04-08, which does not include attribution. The field lands for conformance purposes in whatever the next published spec version ships (no fixed cadence; expected in the next few months). Until then, attribution sits in the working draft on main — implementers can adopt it ahead of the release if they want, but it's not yet part of conformance for the published spec.

That distinction shapes how we're rolling out support across our tools:

UCP Playground will adopt attribution support when the next spec version drops — agents will pass platform attribution through to merchants.
The UCP Score will incorporate attribution-acceptance and attribution-preservation rules in the score release that aligns with the next published spec.
The validator will support the new field as soon as the next spec ships, and the bulk checker will surface attribution conformance per-merchant after that.

The architectural certainty is already here — the schema is locked, the field is documented, the design pattern is settled. The spec drop is the conformance trigger, not the design moment. Implementers who start work today against the working draft are operating against a known target.

Where to read more

The PR itself: #391 on Universal-Commerce-Protocol/ucp
The merge commit: 76a3539
The new schema type: source/schemas/shopping/types/attribution.json
Updated authoring guidance: docs/documentation/schema-authoring.md

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate, and grade every public UCP manifest in the open web, run the merchant directory and the UCP Score, publish the leaderboard and adoption stats, and track major spec events like this one as they ship.

If you're building on UCP and want to know whether your store is ready for the next spec version: run a check. If you're tracking the spec's evolution professionally: subscribe to our weekly digest — we cover spec changes like this one within a week of merge.

UCP Playground at 1,000+ Agent Sessions: What 16 Models and 97 Real Stores Reveal About AI Shopping

Benji Fisher — Tue, 05 May 2026 09:11:37 +0000

Two and a half months ago we published Why We Built UCP Playground, which closed on 114 agent sessions and an honest acknowledgement that the dataset was thin — most models had single-digit sample sizes, store coverage was uneven, and the headline rates moved meaningfully with every new run. A month later we crossed a different threshold: the first fully autonomous AI agent purchase through UCP — a Gemini agent searching, adding to cart, linking identity, paying, and completing checkout at houseofparfum.nl without a human past the initial prompt.

Eighty days on from the first post, and roughly forty days after that autonomous purchase, the dataset is in a different shape:

Over 1,000 agent shopping sessions captured end-to-end with full tool-call timelines and replayable event streams
16 frontier models — every major lab, plus a reasoning-tuned subset
97 distinct UCP-enabled stores across Shopify, WooCommerce, BigCommerce, Magento, PrestaShop, and custom stacks
$96,032 of agent-driven cart value generated, primarily in USD with a long tail across EUR, GBP, INR, ILS, PKR
80 days of run history since Feb 14, 2026

That's the reference dataset for this post. Eight findings emerge from it. Most of them survive being scrutinised at the new sample size; one or two reverse the early-data narrative.

Finding 1 — Claude Sonnet 4.5 leads on aggregate checkout rate

With sample sizes now large enough to take seriously, the per-model checkout-rate leaderboard looks like this:

Model	Share of dataset	Checkout rate	Avg tokens	Avg duration	Fail rate
Claude Sonnet 4.5	20.7%	50.8%	71,195	38.1s	17.2%
Llama 3.3 70B	6.4%	49.3%	57,676	47.7s	14.7%
DeepSeek V3.2	5.1%	45.0%	32,502	46.0s	21.7%
Gemini 3 Flash	12.5%	44.6%	46,520	21.8s	15.5%
Grok 4	4.5%	39.6%	34,297	77.1s	9.4%
Claude Opus 4.6	10.2%	38.8%	44,611	29.7s	25.6%
Gemini 2.5 Flash	9.9%	36.8%	32,394	11.8s	23.1%
GPT-4o	5.2%	29.5%	32,811	14.7s	24.6%
Gemini 3.1 Pro	7.9%	29.0%	30,971	48.7s	28.0%
Gemini 2.5 Pro	6.4%	27.6%	31,566	34.4s	22.4%
GPT-5.2	4.7%	23.6%	30,585	37.4s	27.3%
DeepSeek R1	1.4%	17.6%	35,360	61.4s	29.4%
o4-mini	1.4%	12.5%	64,055	38.1s	37.5%
Grok 3 Mini	1.7%	10.0%	58,386	55.6s	35.0%
QwQ 32B	2.0%	0.0%	25,525	63.9s	50.0%

Claude Sonnet 4.5 leads on aggregate checkout rate at 50.8% on the largest single share of the dataset — a sample large enough that the rank ordering is no longer noise. Llama 3.3 70B sits a fraction below at 49.3% on a smaller but still meaningful share. The two are statistically tied; both are operating in a different regime than the rest of the field.

The most interesting result on this table is GPT-5.2, which at 23.6% lands in the bottom third despite being one of the most capable frontier models on essentially every public benchmark. The gap between its performance on standard reasoning benchmarks and its performance on transactional shopping flows is the single largest delta in the leaderboard. We dig into why in the development notes below.

One caveat worth flagging up-front: GPT-5.2's 23.6% figure reflects performance across the full 80-day window, including the period before our cursor-stripping fix landed mid-dataset. Sessions after that fix show GPT-5.2 performing meaningfully more competitively. We'll publish the longitudinal split in the August update — the aggregate number above is the worst-case read.

Finding 2 — Reasoning-tuned models continue to underperform

The cohort of reasoning-tuned models (DeepSeek R1, o4-mini, Grok 3 Mini, QwQ 32B) sits unambiguously at the bottom of the leaderboard. Three of them are in the bottom four overall. QwQ 32B has yet to record a single completed checkout across its share of the dataset.

The pattern was visible in the original four-session sample report shipped with the eval-framework launch in April; it has only sharpened as the dataset grew two orders of magnitude. The pattern is consistent across labs and across architectures (chain-of-thought variants, exploratory reasoning, distilled-from-frontier models — all underperform on shopping flows compared to their non-reasoning counterparts from the same lab).

The working hypothesis remains: shopping requires fast tool-use rhythm, not deliberation. The decisions in a shopping sequence — search this term, add this item, proceed to checkout — are individually shallow but happen in series. A reasoning model that pauses to deliberate at each step burns clock time and tokens on decisions that don't reward deliberation. Combined with reasoning models' tendency to over-question their own outputs, the result is sessions that hit max_turns_exceeded before completing.

Worth noting what isn't in this hypothesis: reasoning models are not bad at commerce in general. They may be excellent at higher-stakes flows — disputed transactions, multi-step contractual reasoning, regulatory edge cases — that the current eval workload doesn't probe. The benchmark says: when the workload is "shop normally," fast non-reasoning models win. Other workloads will tell different stories.

Finding 3 — Speed and accuracy aren't correlated

Gemini 2.5 Flash finishes the average shopping session in 11.8 seconds — the only model in the field under 15s. Its checkout rate is 36.8% — middling. Claude Sonnet 4.5 takes 38.1s on average and lands a 50.8% checkout rate — the highest on the leaderboard, at more than triple Flash's clock time.

Two real surfaces: latency-bound use cases (voice agents, mobile commerce, conversational checkout where the user is waiting in real time) effectively must use Gemini 2.5 Flash or Gemini 3 Flash, and pay for the latency win with lower closed-checkout rates. Throughput-bound use cases (batch agents, scheduled buying, autonomous shopping where wall-clock time is mostly hidden) should use Claude Sonnet 4.5 or Llama 3.3 70B and accept the latency cost for the conversion lift.

The naive intuition merchants reach for — "the better model is faster and more accurate" — doesn't survive contact with this data. The two axes are essentially independent within this corpus. That's a finding nobody can extract from a single-model demo or a vendor benchmark.

Finding 4 — The failure mode taxonomy is dominated by tool errors, not model refusals

Across the 256 failed sessions in the dataset, the categorised error taxonomy is:

Error type	Sessions	% of categorised failures
`openrouter_error` (provider-side)	51	56%
`model_refused`	22	24%
`max_turns_exceeded`	18	20%

The single-largest categorised failure mode is provider-side errors — the routing layer between the agent and the model returning a non-200 before the session can complete. This is a cost of operating at scale across 16 models and reflects the still-maturing infrastructure underneath frontier-model API access, not anything specific to UCP.

The second-largest, model refusals, is more interesting. Twenty-two refusals across the dataset is a refusal rate of roughly 2%. We see refusals concentrated in two situations: (1) sessions against demo stores with unusual product names that pattern-match a model's safety filters, and (2) sessions where the user prompt contains adversarial content seeded by us as part of a prompt-injection eval. We've recorded 6/6 prompt-injection resistance across the dedicated injection-eval runs to date, so the model_refused category is partly capturing models doing exactly what they should.

The third, max_turns_exceeded, is concentrated in the reasoning-model cohort and is the empirical signal for the over-deliberation pattern in Finding 2.

The remaining 165 failures don't carry a categorised error_type — typically these are sessions where the model abandoned the flow without raising an explicit error. That's a tagging gap in the framework that we're closing in the next iteration.

Finding 5 — Store implementation explains most of the cross-store variance

The benchmark's most strategically important finding doesn't come from the per-model column. It comes from the per-store one.

Across the 97 stores in the dataset, the same model produces dramatically different outcomes. Between the most agent-friendly and least agent-friendly implementations at meaningful sample sizes, the checkout-rate spread exceeds 60 percentage points — wider than any model-versus-model gap on the leaderboard. No model in the field, at any sample size, produces a 60-point spread purely on its own merits. Almost all of that variance is store-side, and the rigorous run history across thousands of sessions makes the pattern hard to attribute to anything else.

The cleanest predictor we've found is whether the store's MCP implementation is stateless or stateful, and how it handles the boundary between them.

Stateless implementations treat every tool call as self-contained. Cart state lives in the agent's context, or in opaque tokens the agent threads through. Identity is established once and re-asserted on each call. The agent doesn't have to remember anything the server is also remembering, because the server isn't remembering anything. Stores running stateless implementations cluster at the high end of the checkout-rate distribution — frontier agents work well against them because there's no hidden contract; what's in the response is the entire state.

Stateful implementations persist server-side session, cart, and auth across calls, exposed to the agent through session IDs, cookies, or scoped tokens. When this works, it works well. When it breaks — session expiry mid-flow, cart drift between a read and a subsequent write, identity tokens that silently lose scope between tool calls — it produces the failure modes that cluster at the bottom of the per-store distribution. The agent calls a tool the server has quietly desynced from, and the flow fails in ways that don't surface until checkout.

The hybrid case is the most error-prone: stores that are stateless in some tools and stateful in others, without making the boundary explicit in the manifest or the tool response shapes. Frontier agents have no way to infer which category any individual call falls into and tend to default to the stateless assumption — which is exactly the wrong default for the calls that aren't.

Beyond the state axis, the rigorous testing surfaces a consistent set of secondary trip-wires: variant IDs without human-readable axis labels, description strings exceeding 8K tokens for a single product, tool responses including nested HTML in fields agents expect to be plain text, cart endpoints returning success codes for failed mutations. None of these break UCP Score validation. All of them break agent flows.

These are merchant-side fixes, not model-side ones. The strategic implication for any team operating a UCP-enabled store: fixing your manifest and tool responses produces more conversion lift than choosing the right model. That's load-bearing — it's why the integrated Score → Check → Eval workflow exists, and it's where we'd point a team starting from zero on UCP.

Finding 6 — Cart value generated is concentrated in USD and high-AOV verticals

Of the 1,000+ sessions, 96 produced a non-zero cart value. The breakdown:

Currency	Sessions	Total cart value	Avg cart value
USD	85	$95,647.23	$1,125.26
INR	2	₹3,845.00	₹1,922.50
PKR	2	₨4,490.00	₨2,245.00
EUR	5	€296.74	€59.35
ILS	1	₪189.60	₪189.60
GBP	2	£47.99	£24.00

USD cart value totals $95,647 across 85 sessions with an average cart value of $1,125. That figure is heavily skewed by a small number of high-AOV sessions against electronics and high-end apparel stores; the median session cart value is closer to $240. We don't yet have the granularity to break out cart value by store type or model — that's a feature in the eval reporting roadmap.

The cross-currency long tail (EUR/GBP/INR/PKR/ILS) is small but informative. It tells us the framework is handling multi-currency stores correctly end-to-end, including currency-aware variant pricing and locale-correct checkout flows. Worth noting because it's a class of bug that doesn't surface until you actually transact.

Finding 7 — Session volume is now meaningful enough to reveal trajectory

Plotted week-over-week, session volume has three distinct phases over the 80-day window:

UCP Playground weekly session volume, mid-February through late April 2026Trend line showing three phases: a small founding wave in mid-February, a steady-state oscillation through March and mid-April, and a sharp acceleration in late April that produces the largest single week of the dataset.Feb 14Apr 27

Founding wave (mid-February). A small launch surge coinciding with the Why We Built UCP Playground post — first publishers running first sessions, signal that the framework worked end-to-end against real stores.

Steady state (March through mid-April). Weekly volume oscillating in a tight band as more frontier models came online and the eval framework matured. Some weeks heavier than others, but the median stayed roughly flat — characteristic of a tool finding its operational rhythm.

Acceleration (late April). The largest single week of the dataset, driven mostly by a batch of eval-collection runs against stores onboarded after the council expansion announcement. The line bends upward at the end of the window.

The trajectory matters mostly because it lets us start tracking model drift. With several thousand more sessions accumulating over the next quarter, we'll be able to observe how the same model performs against the same store between Q2 and Q3 — the loop that turns the framework from a one-shot benchmark into an actual reliability record.

Finding 8 — The 0.2% flawless-end-to-end rate has improved, slightly

The April State of Agentic Commerce report flagged that of 4,014 verified UCP stores, only 9 delivered a flawless end-to-end agent shopping experience. That's the 0.2% figure that's been quoted around the launch posts — measured by static validation across the full directory.

Eighty days later, with 97 stores tested directly through the eval framework, roughly 0.5–0.7% reach the same bar. That's a higher rate, though the comparison isn't apples-to-apples: direct testing surfaces issues that static validation misses (most of the failure modes in this post fall into that category), and the sample composition has shifted toward more deliberately UCP-aware merchants over the period. The honest read is that the rate looks better and the comparison's loose enough that we'd want a same-methodology re-run on the full directory to call it a real improvement.

What we can say cleanly: for every store running a clean, agent-friendly UCP implementation, there are still 100+ that pass conformance but stumble somewhere in the agent flow. The gap continues to be on the merchant side. We haven't yet seen a model-side improvement large enough to close meaningful ground on it.

Why Playground stays neutral

Every finding above hinges on one design choice: the system prompt and the orchestration loop are generic. Same for every model. Same for every store. No store-specific scaffolding, no model-specific workarounds. That's what makes the framework work as a testing environment.

The temptation to add a workaround when a particular model trips on a particular store is real — there's almost always a one-line patch that would push that store's checkout rate up by ten points against that one model. We don't ship those patches, on principle. The moment we do, the results stop being comparable across the matrix and we're not benchmarking anymore — we're tuning. Vendor stacks already do that work, in vendor-flavoured ways, with vendor-shaped numbers.

Independence here means a specific thing: the orchestration is neutral, the protocol layer is full-featured. Stores get the tools they declare. Identity linking works. Payment handlers pass through. Multi-turn context flows the way the spec defines. What stays generic is the harness around that — the prompts, the turn discipline, the success criteria, the error-handling rhythm.

The reason that design choice matters can be put in two sentences:

If a model doesn't follow the checkout flow, that's signal about the model.
If a store returns the wrong status, that's signal about the store.

Both signals are useful. Both are visible because the orchestration didn't paper over either one. Hiding either defeats the purpose of running the test.

Companies building their own internal infrastructure to evaluate agent behaviour against their own stores is expected, and good. Every serious commerce platform will eventually have something like that running in CI against its own merchants — and the Score → Check → Eval workflow is exactly the surface they should plug into. But the comparison layer — the one that asks how Anthropic's frontier model performs against the same workload Google's, OpenAI's, xAI's, DeepSeek's, and Meta's are also running, against the same stores — has to sit outside all of those organisations. Vendors can't credibly benchmark themselves; the platform layer has the same problem one level down. Independence is the only way the comparisons aggregate into a record anyone can quote.

That's the niche this layer occupies. The leaderboard, the failure-mode taxonomy, the store-side variance pattern in this post only hold up if the orchestration stays neutral. The moment it doesn't, the framework loses the property that made any of it worth publishing.

What we learned building this

The framework didn't ship in May the same shape it shipped in February. Eighty days of running it against real stores produced a steady stream of bugs and surprises that drove the development work — many of them documented in the public changelog. Five worth surfacing.

Cursor stripping unlocked GPT-5.2 search. Through February we had GPT-5.2 at a 0% search success rate on Shopify stores. The cause was a model-side tic: GPT-5.2 always included the optional after cursor parameter on search_shop_catalog calls, filling it with placeholders like "", "null", or "__NONE__" — values Shopify always rejects. A server-side sanitizer that strips invalid placeholders before the call leaves Playground pushed GPT-5.2's search success from 0% to 100% overnight. The model wasn't bad at search; it had a tool-calling habit nobody had isolated yet.

Failed tool calls used to inflate conversion metrics. An earlier version of step detection counted a failed update_cart as a cart_created completion. That bug inflated the cart and conversion numbers on every report we'd published before mid-March. Fixed in 0.9.3 by gating step detection on the tool response's isError flag, plus the same gate on cart-data extraction. The per-model checkout rates in this post are computed under the corrected logic; older snapshots from before that fix may read 5–10 points high on the conversion-side metrics.

REST-only stores forced a transport rework. The v2026-04-08 spec drop in early April brought new tool names (search_catalog replacing search_shop_catalog), new response shapes (price as {amount, currency} objects, descriptions as {plain, html} objects), and a wave of WooCommerce stores that exposed REST-only endpoints rather than MCP. The 0.10.x release line was mostly absorbing that — REST-only store support, a REST tool-call adapter, response-format normalization across spec versions. Pre-04-08 sessions and v2026-04-08 sessions are both in the dataset and tagged appropriately, which is what lets the longitudinal data hold together across a non-trivial spec change.

The GPay token wall built ECP. In a February session, Claude Sonnet 4.5 reached ready_for_complete correctly — and stalled, because the merchant's checkout required a Google Pay payment token the agent couldn't produce. That's the genuine limit: agents shop through the protocol layer cleanly but stop at the secure-credential boundary. The Embedded Commerce Protocol shipped in 0.8.0 to hand control to the merchant's checkout UI at exactly that boundary and resume agent control once the user completes the credential step. A feature directly driven by a finding the framework couldn't have surfaced any other way.

A Playground session became a spec proposal. A live test against houseofparfum.nl exposed a different gap: an identity-linked buyer with a wallet balance hit the checkout, the OAuth flow completed cleanly, the buyer object came back populated — but the wallet was nowhere the agent could see it. payment.instruments was empty, the only declared handler (dev.ucp.delegate_payment) didn't accept the wallet, and the session escalated to the merchant's continue_url every time. Authenticated checkout was provably blocked, by spec. We wrote it up and submitted Proposal #358 to the UCP spec repository — payment.available_instruments, a per-buyer per-session list of usable payment methods (wallet, saved cards, loyalty, gift cards) resolved at runtime from the identity-linked session. Submitted by Benji Fisher (@appdrops) and co-authored with Almin Zolotic (@zologic) of UCPReady, who'd seen the same wall from the merchant side. Currently submitted to the UCP technical council for review. That's the loop the framework is built to feed: multi-store, multi-model testing surfaces a structural gap; the gap goes back into spec governance as a concrete proposal; the next spec drop closes it.

Methodology, briefly

Each session is a real frontier-model agent shopping run against a real UCP-enabled store, captured end-to-end via MCP tool calls. Sessions are initiated either through the public Playground UI (user-initiated, ad-hoc prompts) or through the Evals framework (scripted multi-turn sequences across pre-selected store/model matrices).

Outcomes are tagged at session close: checkout_reached (full transaction completion), cart_created (added items, didn't proceed), search_only (browsed, didn't add), failed (provider error, model refusal, or max-turn exceeded), or info_provided (informational query, no transactional intent).

Every session has a clickable replay link in its source ULID. If you want to audit any single number in this post, the underlying session data is the artifact. That's intentional — independent reproducibility is the point.

Try it

Three concrete next steps:

Run a benchmark against your own store. Create a collection at ucpplayground.com/evals, pick a sequence, pick two models, and compare your store's per-model performance against the aggregate above.
See where individual models stand. Each model on the leaderboard has its own shopping profile with detailed performance data, known issues, and store-by-store breakdowns.
Compare two models head-to-head. The comparison view lets you pit any two models against each other on the same workload — useful before you commit to a primary model for a deployment.

The next data update — likely 2,000+ sessions, refreshed model lineup, and a fuller error-tagging surface — drops in early August.

UCP Requirements: What Your Store Needs Before Going Live

Benji Fisher — Mon, 04 May 2026 12:23:16 +0000

What do you need for UCP? There are two levels of UCP readiness. The first is the minimum viable manifest — the bare requirements to pass validation and appear in the UCP directory. The second is the agent-ready setup — what it actually takes for an AI agent to browse, cart, and check out at your store without friction.

Think of this as your UCP checklist — the minimum requirements plus the recommended prerequisites that separate stores agents can find from stores agents can actually shop. Most guides only cover the first level. This one covers both, grounded in data from 4,024 verified merchants and hundreds of agent testing sessions.

Minimum requirements (pass validation)

These are the fields required to produce a valid UCP manifest on the current v2026-04-08 spec:

1. A JSON file at /.well-known/ucp

The manifest must be publicly accessible at https://yourdomain.com/.well-known/ucp, served with Content-Type: application/json, and reachable without authentication.

Platform notes:

Shopify: handled automatically
WooCommerce: manual publish via plugin or custom route
BigCommerce: manual, served from storefront origin
Magento: manual, typically via custom module

Full publishing guide with code examples: /.well-known/ucp developer reference.

2. ucp.version (required)

A string identifying which spec version the manifest is written against. Current latest: "2026-04-08".

99.4% of verified stores are on this version. If you're starting fresh, use it. If you're on an older version, the spec update post walks through the migration.

3. ucp.services (required)

At least one service entry declaring a transport (mcp, rest, a2a, or embedded) and an endpoint URL. This tells agents where to send requests.

MCP is the dominant transport — ~100% of verified stores declare it. If you're building from scratch, start with MCP. See the transport comparison for the tradeoffs.

4. ucp.payment_handlers (required)

A map of payment handler namespaces. Can be an empty object {} if your store uses checkout-link redirects instead of tokenized payments (common on WooCommerce).

If you declare handlers, use reverse-domain namespaces like com.stripe.card or dev.shopify.card. See the payment handlers directory for examples.

5. signing_keys (required, at root level)

An array of JWK objects at the document root (not nested inside ucp). An empty array [] is valid if you're not signing payloads yet, but the key must be present.

This field moved from ucp.signing_keys to the root in v2026-04-08 — the most common validation warning we see is stores that still nest it.

Recommended setup (agent-ready)

Passing validation gets you into the directory. The requirements below determine whether agents can actually shop your store — the difference between a B+ grade and an A grade in our benchmarks.

6. Capabilities declaration

The ucp.capabilities field is optional per spec but strongly recommended. Without it, agents know your store exists but not what it can do.

Declare every capability you support:

checkout — 99.5% adoption across verified stores
cart — 99.1% adoption
catalog-search — required for product discovery
identity-linking — 3 stores, massive first-mover opportunity
payment — 0 stores, the frontier

Full list: capability registry.

7. Clean variant data

Variant mismatches are the #1 failure mode in agent shopping sessions. Every variant needs a stable ID, a clear name, and consistent representation across discovery and checkout. This is the single highest-impact fix you can make.

8. Responsive MCP endpoint

Latency matters. The average Shopify store responds in ~130ms. BigCommerce stores average ~890ms. Agents have timeout budgets — if your endpoint is slow, sessions drop silently. Target under 500ms for tool responses.

9. robots.txt allowing AI crawlers

Make sure /.well-known/ucp is explicitly allowed in your robots.txt. Some WAFs and CDN configurations block well-known paths by default. Check the common errors guide for the fix.

10. Supported_versions for backward compatibility

Declare supported_versions in your manifest listing both the current and previous spec version. This lets agents that haven't migrated yet still find a valid endpoint:

"supported_versions": {
    "2026-04-08": "https://yourstore.com/.well-known/ucp",
    "2026-01-23": "https://yourstore.com/.well-known/ucp/2026-01-23"
}

The UCP readiness checklist

Requirement	Required?	% of stores that have it
Manifest at /.well-known/ucp	Yes	100% (by definition)
ucp.version	Yes	100%
ucp.services with transport + endpoint	Yes	100%
ucp.payment_handlers	Yes	100%
signing_keys at root	Yes	~97% (rest have it nested)
ucp.capabilities	Recommended	~99% (Shopify default)
Clean variant data	Recommended	Unknown (runtime issue)
Latency < 500ms	Recommended	~95% (Shopify), ~30% (others)
robots.txt allows /.well-known/ucp	Recommended	~99%
supported_versions	Recommended	~70%

Validate your setup

Not sure if you pass? Start with Is My Store UCP Ready? — it walks through the full diagnostic in 60 seconds. Or jump straight to the tool:

Run a live check on your domain — it tests every requirement above in seconds. For runtime issues (variant mismatches, checkout failures), test with real agents in Playground. For ongoing monitoring, set up alerts.

Once you're verified, make sure your listing on UCP Registry is accurate — that's what agents see when deciding which stores to route customers to. And if you're a developer building agents rather than stores, the Build an Agent quickstart covers the other side of the equation.

Check your store now at UCPChecker.com. See how you compare: side-by-side store comparison. Platform guides: Shopify · WooCommerce · BigCommerce · Magento

AI Commerce Needs MLPerf — and Here's an Early Attempt

Benji Fisher — Fri, 01 May 2026 12:07:45 +0000

Validating a UCP manifest takes a second. Scoring it for agent-readiness takes another. Neither of those answers the harder question: when a real frontier agent — Claude or GPT or Gemini, picked by a user three weeks from now — walks up to your store with an ordinary shopping prompt, does it actually complete a checkout? Compared to the next implementation? Across the models people are actually using?

Today there's no shared way to find out. AI commerce has the same coordination problem ML had before MLPerf, web performance had before Lighthouse, and coding models had before HumanEval — and the cost of not solving it is the same: every claim a vendor makes about agent-readiness is currently unverifiable by anyone outside that vendor.

This post is about what we've been building to close that gap.

The pre-benchmark moment

Every category that grew up around AI has gone through a pre-benchmark moment.

Machine learning before MLPerf was a pile of vendor-flavoured numbers. NVIDIA reported one set of throughput claims, Google another, AMD a third — and none of it was directly comparable, because nobody was running the same workload, on the same input, on the same harness. MLPerf — submitted to, run by, and audited across the whole industry — fixed that. Buyers could finally compare. The category matured.

Web performance before Lighthouse was the same. "Fast website" was vibes. PageSpeed Insights gave one number, WebPageTest another, internal RUM dashboards a third. Lighthouse — graded, reproducible, open — fixed it. Today nobody ships a serious site without checking their score.

Coding models before HumanEval were even worse. Every lab benchmarked against its own preferred problems and reported its own preferred metrics. HumanEval, then MBPP, then SWE-bench, then LiveCodeBench, gave the field a shared evaluation surface. Comparisons stopped being marketing.

Agentic commerce is in exactly the place those categories were before their benchmarks landed. The standard has converged — UCP is the open spec the industry is building against, and the public directory tracks 4,500+ verified stores. Major retailers and platforms ship UCP implementations almost weekly. The recent tech council expansion brings in most of the rest. But there is still no neutral, reproducible way to evaluate how well any of those implementations actually work when a real frontier agent tries to shop them.

You can't get this from inside a vendor. Shopify cannot credibly benchmark Shopify stores. OpenAI cannot credibly benchmark OpenAI agents. Even when their numbers are honest, the methodology is theirs, the test conditions favour their stack, and nobody else can rerun it. AI commerce has the same coordination problem ML had before MLPerf, and it solves the same way: a shared evaluation layer, run by a third party, that anyone can audit and reproduce.

Agentic commerce can't mature without that layer. We've built a first credible attempt at one.

What UCP Playground Evals does

UCP Playground Evals is a benchmark framework for agentic commerce. You define a multi-turn shopping conversation, pick the stores and the models you want to evaluate against it, and get back a structured comparison report — funnel matrix, per-session token and duration metrics, error classification, replayable session links, downloadable PDF.

The point isn't the report format. The point is the three properties underneath, because those determine whether a benchmark is worth trusting.

1. Standardised, multi-turn sequences

Agentic commerce is conversational, not single-prompt. A real shopping session looks like "Show me products under $60" → "Add both to my cart" → "Proceed to checkout", with full context carried across turns. That's the unit an eval has to operate on.

Each eval is a scripted sequence of turns. Every turn gets its own orchestrator round (up to 8 internal tool-calling sub-turns) and the full conversation history is preserved across the sequence — so the agent's choices on T2 are conditioned on what it actually saw on T1, the way real user behaviour conditions on real responses. Four collections ship today: Browse & Buy (4 turns, generic shopping journey), Multi-Item (3 turns, multi-product cart composition and checkout), Price Constrained (3 turns, budget-anchored reasoning across a single purchase), and Custom for user-defined sequences.

2. Cross-store comparability

The sequences are intentionally generic. Not "Find Nike Air Max 90 in size 10" but "Show me products under $60". That distinction is load-bearing: it's what makes the same test valid against any store running UCP, and it's what makes results from one store directly comparable to results from another. Without it, every benchmark is apples-to-oranges and nothing aggregates.

The eval runner discovers MCP endpoints automatically from each store's /.well-known/ucp manifest, so any UCP-conformant store works without per-store wiring — Shopify, WooCommerce, BigCommerce, Magento, PrestaShop, and Custom & Headless stacks all work the same way.

3. Multi-model coverage

The same sequence runs against any of 15 frontier models currently wired up — every major lab, plus a reasoning-tuned subset:

Model	Provider	Type
Claude Opus 4.6	Anthropic	Frontier
Claude Sonnet 4.5	Anthropic	Frontier
GPT-5.2	OpenAI	Frontier
GPT-4o	OpenAI	Frontier
Gemini 3.1 Pro	Google	Frontier
Gemini 3 Flash	Google	Frontier
Gemini 2.5 Pro	Google	Frontier
Gemini 2.5 Flash	Google	Frontier
Grok 4	xAI	Frontier
DeepSeek V3.2	DeepSeek	Frontier
Llama 3.3 70B	Meta	Frontier
DeepSeek R1	DeepSeek	Reasoning
QwQ 32B	Alibaba	Reasoning
Grok 3 Mini	xAI	Reasoning
o4-mini	OpenAI	Reasoning

The model is part of the test matrix. Same store, different models, same sequence — directly comparable behaviour, with model-level differences surfaced rather than averaged away. Any two can also be compared side-by-side outside the eval framework, on the same workload.

The math is straightforward

stores × models × sequences = sessions. Two stores × two models × one sequence = four sessions. Each one is a full agent shopping run, captured end-to-end, replayable, and rolled up into the report.

Standardised, reproducible, vendor-neutral. The three properties that make a benchmark worth trusting. Everything else in the framework is built to defend those three.

What the framework actually surfaces

The clearest way to show what evals do is to walk through one. Below is a multi-item checkout report we ran across two stores and two Gemini models in March:

Download the full multi-item checkout report (PDF) →

Two-page report covering the funnel comparison matrix, per-session performance breakdown, evaluator configuration, auto-generated recommendations, and clickable session-replay IDs for every run.

Two stores (oakywood.shop, ugmonk.com). Two models (Gemini 3 Flash, Gemini 3.1 Pro). One sequence (multi-item checkout: search → add → checkout). Four sessions total. The headline numbers:

100% checkout rate across all four sessions
95,513 average tokens per session
48.3s average duration
0 errors across the matrix

That's the boring summary. The interesting parts are in the per-session table.

Store	Model	Tokens	Duration	Turns	Cart value
oakywood.shop	Gemini 3.1 Pro	85,614	93.4s	7	EUR 82.75
oakywood.shop	Gemini 3 Flash	154,294	34.7s	12	—
ugmonk.com	Gemini 3.1 Pro	46,084	35.1s	6	USD 77.00
ugmonk.com	Gemini 3 Flash	96,058	29.9s	11	—

Same sequence, same stores, two models. Gemini 3.1 Pro completes the run in fewer turns and roughly half the tokens of Flash on the same store, but its latency is meaningfully higher when the store itself is slower to respond. That isn't a fact you can extract from a vendor benchmark or a single-model demo. It only shows up when the same scripted run hits multiple models head-to-head, with both numbers landing in the same row.

The auto-generated recommendations point at where the real engineering work is, and they're grounded in the actual run data:

Average token usage is 95,513 — above the 40K baseline. Product descriptions may be inflating context. Consider truncating descriptions in MCP responses.

Average session duration is 48.3s — above the 15s target. Optimise MCP endpoint response times, especially initial search calls.

Those are concrete merchandising actions. They land because the evidence is right there in the per-session breakdown.

The deeper signal shows up across runs against richer stores. In a separate eval against a single shop, two models picked different variant IDs for "Medium" — one mapped Medium to one variant ID, the other to a different one, and neither is provably correct because the store doesn't expose a human-readable size axis in its variant data. That isn't a bug in either model. It's a gap in how the store represents its product axes, and it only becomes visible when two models walk the same path. This is the kind of behavioural divergence between frontier models that evals surface — and that vendor-internal benchmarks can't credibly report.

The same run logged 6/6 prompt-injection resistance across every session, against benchmark prompts seeded in product descriptions and review fields. Useful by itself; more useful as a baseline that future runs can regress against.

What's on the evals roadmap

This is v1. A few things on the roadmap, in priority order.

More eval collections. The four built-in sequences cover the core shopping flow. The next batch is more diagnostic: single-item flow (the simplest path), variant selection accuracy (the size-label gap above, formalised), prompt-injection resistance (already running, becoming its own collection), escalation handling (requires_escalation compliance), attribution accuracy (UTM and referrer handling at checkout hand-off), return policy surfacing.

Public benchmark leaderboards. Same pattern as the UCP Score leaderboard — by-store and by-model rankings against the standard sequences, refreshed on schedule, indexed and shareable. The categories that matured around shared benchmarks (ML, web perf, coding models) all developed public leaderboards — and the leaderboards turned out to be most of the forcing function.

Headless API and CI/CD integration. Already shipped. The full automation surface:

POST /api/v1/collections          — create
POST /api/v1/collections/{id}/run — trigger
GET  /api/v1/collection-runs/{id} — poll status + results
GET  /api/v1/collection-runs/{id}/pdf — download report

The first integration we expect anyone to ship is a deploy-time check: trigger an eval after every UCP manifest deploy, assert checkout_rate >= 80, errors.total == 0, avg_duration_ms < 30000, fail the build otherwise. Same shape as Lighthouse CI for web performance — a regression catch you bolt onto the pipeline rather than rediscover in production. Full developer documentation — authentication, rate limits, and a worked GitHub Actions example — lives at ucpchecker.com/developer-tools, alongside the rest of the public API surface.

Scheduled runs and version tracking. Also shipped. Collections auto-increment versions when their config changes, runs snapshot the config they used, and a cron field on each collection lets you run the same eval on a regular cadence — same Monday-9am sequence every week, before-and-after comparisons whenever the underlying UCP implementation changes. This is how a benchmark becomes a tracking record instead of a one-shot demo.

Cloning and team scoping. Public collections can be cloned into any team workspace; quotas are scoped per team. The intent is community sharing — well-known sequences turning into shared, reusable yardsticks the way SWE-bench problem sets did for coding models.

How evals fit the broader development cycle

Evals don't sit alone. They're the runtime testing surface in a development loop that starts earlier in UCP Checker — manifest validation, agent-readiness scoring, capability coverage analysis. The web performance world solved the same shape with three tools used in sequence: Lighthouse to grade pages, PageSpeed Insights to drill into specific issues, synthetic monitoring to verify behaviour over time. UCP implementations follow the same arc: validate the manifest at /check, score it against agent-readiness criteria with the UCP Score, then run evals against it to see how it actually behaves when a real frontier agent shops it.

Each tool surfaces something different. Score tells you what's missing structurally — which discovery signals, which capabilities, which conformance rules. Check confirms the manifest validates after fixes land. Evals confirms the agent actually behaves correctly when it tries to complete a real flow. None is sufficient on its own; together they're the development feedback loop UCP needs. We've watched developers iterate across the whole thing in a single session — score the implementation, fix the gap server-side, re-check the manifest, then run an eval to confirm the agent now closes a checkout it couldn't before.

If you're starting from zero on a UCP implementation, the natural sequence is: get a Score first to see what's missing, fix the highest-impact issues, run a Check to confirm the manifest validates cleanly, then run Evals to confirm real agents complete the flows you care about. CI covers the long tail — automated scoring on each deploy, scheduled evals weekly, alerts when capabilities regress.

Methodology and verification

Three properties separate a credible benchmark from a marketing claim. UCP Playground Evals are designed around all three.

Every result links to a replayable session. Each eval session generates the same agent_sessions data the public Playground UI produces — full tool-call timeline, model responses, token-by-token event stream, every retrieved page. The session IDs in any report are clickable. Open one and you see exactly what the agent did, turn by turn, on which tool call, with which response. The sample report above lists four such IDs (e.g. 01KMJZM5MG2CA4QN5M983H19E1) and each resolves to a full replay at ucpplayground.com/sessions/{id}. This isn't a marketing claim; it's a verifiable test you can audit.

Every collection is versioned. When the configuration of a collection changes — turns added, models swapped, store list updated — the version increments and every run snapshots the config it ran against. Anyone questioning a result can reproduce the exact methodology used at that moment. The PDF report itself prints the collection version at the bottom of every page; the sample above is Collection v3. Versioning is what stops "we got better results" from quietly sliding into "we changed the test" — the same constraint MLPerf submission rules enforce on hardware vendors.

The methodology is open. The framework configuration shape is documented — the turns, the orchestrator loop, the stop conditions, the success metrics, the PDF schema. Anyone can build the same test, run it against any UCP store, and get back a directly comparable report. If we get a methodology choice wrong, the path to disagreement is technical, not promotional.

That's the credibility floor. Everything else in the product builds on it.

About UCP Checker and UCP Playground

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate, and grade every public UCP manifest in the open web, run the merchant directory and the UCP Score, publish the leaderboard and adoption stats, and ship developer tools — the validator, bulk checker, browser extension, public dataset, and a public REST API. The whole dataset is open, indexed, and ungated.

UCP Playground is the agent shopping layer that sits next to it — same data model, same /.well-known/ucp discovery, same replayable session format. UCP Playground Evals is the benchmark surface on top of that. Together they form the third-party scoreboard the ecosystem can build trust on top of — the SSL Labs and Lighthouse of agentic commerce, depending on which side you're looking from.

Try it

The interesting eval gaps are the ones nobody's tested yet. If a result surprises you — your own store, a competitor's, a model you assumed was a clear winner that turns out not to be — let us know.

Three concrete next steps:

Run an eval against your own UCP store. Create a collection at ucpplayground.com/evals, pick a sequence, pick two models, run it. The four-session example above is the shape most first runs take.
Read a public eval report. Sample reports are linked from the framework page. Each has clickable session IDs you can replay end-to-end.
Wire it into CI. The developer tools page covers authentication, rate limits, and a GitHub Actions worked example. The assertion shape is the same one Lighthouse CI uses for web performance — checkout_rate, errors.total, avg_duration_ms instead of LCP and TBT.

Is My Store UCP Ready? How to Check in 60 Seconds

Benji Fisher — Thu, 30 Apr 2026 10:25:51 +0000

The short answer: enter your domain here and you'll know in under 60 seconds. This UCP ready check runs the same validation that AI agents use to decide whether your store is worth shopping.

The longer answer — what "UCP ready" actually means, why it matters, and what to do about the result — is what this post covers.

What UCP readiness means

A store is "UCP ready" when it publishes a valid manifest at /.well-known/ucp that AI shopping agents can discover, parse, and act on. That's the technical definition.

In practice, there are three levels:

Level 1: Verified

Your manifest exists, returns valid JSON, and passes schema validation against the current v2026-04-08 spec. You appear in the UCP directory. Agents can find you.

As of this month, 4,024 stores are at this level.

Level 2: Agent-functional

Agents can actually shop your store — not just discover it. Your MCP endpoint responds, your product data is clean, your checkout flow completes without errors. You score B+ or higher on the Playground leaderboard.

422 stores are at this level. The gap between "verified" and "agent-functional" is where most common errors live.

Level 3: Optimized

Agents complete purchases reliably across multiple models. Your variant data is clean, your latency is low, your capabilities go beyond the defaults. You score A. Only 9 stores are here today.

The UCP requirements checklist breaks down exactly what each level requires.

How to check your store

Step 1: Run the checker

Go to UCPChecker.com/check and enter your domain. When you check your UCP status, the checker will:

Fetch /.well-known/ucp from your domain
Validate the JSON against the current spec
Check your robots.txt for AI bot policies
Inventory your declared capabilities, transports, and payment handlers
Verify your UCP compliance and report every error and warning with specific error codes

The whole process takes about 1 second. You'll get a full diagnostic report on your status page.

Step 2: Read the result

Verified (green) — your manifest is valid. You're in the directory. Agents can find you. Check the warnings section for things to improve.

Invalid (amber) — your manifest exists but fails validation. The diagnostic panel shows exactly which fields are wrong or missing. Most invalid manifests are one fix away from passing — usually a missing required field or a misplaced signing_keys.

Not Detected (grey) — no manifest found at /.well-known/ucp. Your store isn't UCP ready yet. See the requirements post for what to publish.

Blocked (orange) — your robots.txt or firewall is preventing access to the manifest. The diagnostic will tell you whether it's a robots.txt rule or an HTTP-level block.

Step 3: Fix what's broken

The checker tells you what is wrong. Here's where to go for how to fix it:

Platform-specific guides: Shopify · WooCommerce · BigCommerce · Magento
Manifest reference: /.well-known/ucp developer guide
Error-by-error fixes: Common UCP errors
Spec changes: v2026-04-08 update

Step 4: Test with real agents

Schema validation tells you if your manifest is syntactically correct. It tells you nothing about whether an agent can actually buy something from your store. For that, you need UCP Playground — it runs real AI agent sessions against your store and shows you exactly where the flow breaks.

The agent testing data shows that the most common runtime failure is variant mismatches — clean product data matters more than perfect schema.

Step 5: Monitor

Your UCP endpoint is a live API. Platform updates, catalog changes, and CDN reconfigurations can break it silently. Set up UCP Alerts to get emailed the moment your status changes — before agents notice.

How you compare

Once you're verified, see how your store stacks up:

Compare side-by-side with a competitor or partner store — capabilities, transports, payment handlers, latency.
Browse your platform — see all verified Shopify, WooCommerce, BigCommerce, or Magento stores ranked by capability depth.
Check the leaderboard — stores graded A through F on real agent shopping performance.

Why this matters now

UCP adoption is accelerating. 1,400+ new merchants were discovered in April alone. Shopify migrated its entire fleet to the latest spec in four days. BigCommerce, WooCommerce, and Magento stores are appearing every week.

Am I UCP ready? The question isn't whether your store will need UCP. It's whether you'll be ready when agents start shopping — and they already are.

Before you check, it helps to understand the building blocks: capabilities define what your store can do for agents, payment handlers define how agents pay, transports define how agents connect, and product discovery is the flow agents actually run when they shop.

Make sure your listing on UCP Registry is accurate once you're verified — that's how agents find you in the first place.

Check your store now →

Build your own agent: developer quickstart. Understand the protocol stack: MCP vs UCP vs AP2. Monthly ecosystem data: State of Agentic Commerce.