DEV Community: Benji Fisher

The First Fully Autonomous AI Agent Purchase Through UCP

Benji Fisher — Sat, 04 Apr 2026 10:47:23 +0000

An AI agent searched a store, picked a product, linked a customer identity, selected wallet payment, set shipping, and completed checkout — creating a real WooCommerce order. No browser. No card network. No human after “proceed.”

On March 25, 2026, session 01KMJ26KVH7ZZ78DWMHZ5BRK32 on UCP Playground became the first fully autonomous AI agent purchase completed through the Universal Commerce Protocol. Here’s what happened, what broke along the way, and why it matters.

What you’re looking at

The session replay shows Claude Sonnet 4.5 shopping at houseofparfum.nl — a real Dutch perfume store running WooCommerce with the UCPReady plugin by Zologic. The user said:

“Buy me a perfume under 30 euro, pay with my wallet”

Eight turns and 43 seconds later, WooCommerce order #82251 was created. €30.13 debited from the customer’s store wallet. Confirmation email sent. No redirect. No payment form. No human touched it after the initial confirmation.

Replay the full session →

The full tool call sequence

Every step of the purchase is visible in the session recording. Here’s what the agent executed:

ucp_list_products — searched perfumes under €30, found Emanuel Ungaro Intense For Him (€18.95)
User confirms: “yes”
create_checkout — line items added, buyer pre-populated from linked identity (resolved to WooCommerce customer #1), status: requires_escalation
update_checkout — selected_instrument_id: terrawallet-1 rejected (missing fulfillment)
update_checkout — shipping method flat_rate1 set, payment still missing
update_checkout — wallet instrument with handler_id: com.terrawallet.store_credit accepted, status: ready_for_complete
complete_checkout — status: completed, order #82251, wallet balance: €467.32

Every call carried an OAuth bearer token from the linked identity. The merchant resolved it to WooCommerce customer #1, pre-populated name, email, phone, and address. The com.terrawallet.store_credit payment handler surfaced a €490.25 wallet balance with coverage: full — enough to cover the order without any card network involvement.

What had to work

This wasn’t a demo against a mock API. It was a real store with a real product catalogue, real pricing, real tax calculation, and a real wallet debit. For it to complete, every layer of the stack had to function.

Protocol layer

.well-known/ucp manifest with MCP endpoint, capabilities, and payment handlers
tools/list returning all 11 tools (search, product details, cart CRUD, checkout lifecycle, complete, cancel)
Structured validation messages (requires_buyer_input) that the agent could read and act on

Identity linking

OIDC discovery from issuer URL (RFC 8414 — UCPReady uses /.well-known/oauth-authorization-server)
Dynamic client registration via the discovered registration_endpoint
OAuth consent flow with PKCE
Bearer token injected on every MCP request
Merchant resolving the token to identity_customer_id: 1 with pre-populated buyer data

Agent orchestration

System prompt with checkout completion instructions
Auto-nudge when the model stopped after seeing validation errors
Auto-injection of meta.idempotency-key (UUID) on complete_checkout — models consistently fail to format this correctly
Payment handler IDs passed from manifest to system prompt

Payment processing

TerraWallet store credit — entirely server-side, no browser interaction needed
Wallet debit atomic with order creation on complete_checkout
Balance surfaced in checkout response so the agent knows coverage

What broke along the way

We’d love to say this worked first try. It didn’t. Over 24hrs of debugging with Almin from Zologic, we hit and fixed:

Wrong MCP endpoint — our Shopify storefront probe was overriding the manifest endpoint, so OAuth tokens were stored against /api/mcp but MCP calls went to /wp-json/ucpready/v1/mcp
Stale OAuth sessions — merchant-side revocation wasn’t detected; we had to add token validation on connect and auto-clear on 401
Model stringifying meta — Claude kept sending meta: "{\\"idempotency-key\\": \\"...\\"}" instead of a proper object. We fixed it by auto-injecting the key at the orchestrator level
Wallet instrument format — the merchant’s validator checked for dots in handler names; terrawallet-1 (the instrument ID) failed the check while com.terrawallet.store_credit (the handler name) passed

Each of these was a real bug that blocked a real purchase attempt. The session data captured every failure, which is exactly what UCP Playground is built for.

Why protocol matters

Everything we built is protocol-level, not store-specific:

OIDC discovery works for any merchant declaring an issuer
Bearer token injection works for any MCP endpoint with OAuth tokens
Checkout nudge fires for any store returning requires_buyer_input
Payment handler passthrough works for any instrument the merchant advertises
Idempotency key injection works for any complete_checkout / cancel_checkout call

The same Playground code that completed this WooCommerce wallet checkout handles Shopify’s update_cart, classified listings, and B2B procurement flows. The protocol is the abstraction — the store plugs in whatever it supports.

What’s next

This was a single-item purchase with a pre-funded wallet and a known merchant. The conditions were controlled — one product, one payment method, one confirmation. The next milestone is multi-item cart in fully autonomous mode: multiple products, multiple decisions, no human in the loop.

That’s where orchestration, spend limits, and merchant trust become non-optional. An agent selecting three items across two stores, choosing between wallet and saved card, applying a shipping preference — every one of those decisions needs a policy layer that doesn’t exist yet.

The protocol works. Now it needs guardrails.

Try it

Replay the session: ucpplayground.com/s/01KMJ26KVH7ZZ78DWMHZ5BRK32
Run your own: ucpplayground.com/agent — connect to any UCP-compatible store
Check your store: ucpchecker.com/check
Validate your manifest: UCP Validator — paste your JSON and check spec compliance
Monitor your store: UCP Alerts — get notified when your manifest changes
Browse verified merchants: Directory
Read Almin’s perspective: WooCommerce Just Did What Shopify Did — Hours Later

Sources

Session replay: 01KMJ26KVH7ZZ78DWMHZ5BRK32 — UCP Playground
UCPReady Plugin for WooCommerce — Zologic
UCP Now Supports Identity Linking — UCP Checker Blog
Why We Built UCP Playground — UCP Checker Blog
State of Agentic Commerce — March 2026 — UCP Checker Blog
UCP Specification — ucp.dev
WooCommerce Just Did What Shopify Did — Hours Later — Almin Zolotic, dev.to
UCP Playground Changelog

Built with UCP Playground. Session data captured, replayed, and shared — because observability is the foundation of trust in agent commerce.

3,000 UCP Stores, Open Data: Why We're Publishing Our Dataset on Hugging Face

Benji Fisher — Fri, 03 Apr 2026 12:54:26 +0000

We've been crawling UCP manifests since January. For the first few months, the data lived in our own database — feeding the directory, powering the grades, tracking adoption week by week. We published summaries in our monthly state-of-the-ecosystem posts, but the raw dataset stayed internal. There wasn't much to share when the corpus was a few hundred stores.
That changed. We crossed 3,000 verified UCP merchants this week. And when you're sitting on a dataset that didn't exist six months ago, that no one else has, and that the people building agentic commerce tools would genuinely benefit from — it's time to share it.
Today we're publishing the UCPChecker merchant dataset on Hugging Face. Monthly snapshots, CC-BY 4.0 licensed, free to download, free to use.

What's in the dataset

Every row is a verified UCP merchant — a domain where we've confirmed a valid UCP manifest exists at /.well-known/ucp, the manifest passes spec validation, and the store has at minimum a working search capability.
For each merchant you get the domain, verification status, UCP endpoint URL, HTTP status, the spec version the store is advertising, five boolean capability flags (checkout, cart management, identity linking, order, payment token), a capability count, the AI bot policies the store declares, the transports it supports (MCP, REST, embedded), and two timestamps: when we last checked it and when we last got a successful response.

Dataset Schema — 15 columns — UCP Checker Share Embed

That last column matters more than it looks. "First seen" is when this store became agent-ready. It's a timestamp on a real industry transition.
The snapshot releasing alongside this post covers the full corpus — 3,000+ stores across every platform we've indexed, from the Shopify majority to the handful of independent WooCommerce and Magento implementations that have been painstakingly hand-configured.

This is the directory layer — the foundation. If you need more — deeper analytics, operational data, or enterprise-level insight — get in touch. We work with teams building on top of the ecosystem.

If you're a merchant and your store isn't in the dataset, check whether your /.well-known/ucp manifest is live and valid at ucpchecker.com. Once you're verified, you'll appear in the next monthly snapshot automatically.

What you can build with it

The obvious use case is research. If you're writing about agentic commerce — for a conference talk, an analyst report, a blog post — you now have a citable, versioned dataset instead of a hand-waved "thousands of stores." Download the CSV, run your own analysis, publish your own findings. We'll keep releasing monthly snapshots so your comparisons have a time axis.
The less obvious use case is tooling. If you're building a commerce agent, an MCP client, or anything that needs to discover agent-ready stores, this dataset is your starting index. You don't need to crawl from scratch. Every domain in the file has a working UCP manifest right now. Point your agent at any of them and it will find something to buy.
There's also benchmark utility. We've built our own benchmark tooling on top of this corpus — the leaderboard compares how AI models perform across real stores — but the underlying merchant list is the same one we're publishing. If you want to run your own evals against a representative cross-section of real UCP commerce, this is the store list to use.

What's in the open dataset

Open Dataset — CC-BY 4.0 — UCP Checker Share Embed

Why publish it

The ecosystem needs a shared baseline. Right now the people building agentic commerce tools — developers, agent frameworks, platforms — are all working from anecdotal evidence about which stores support what. That slows everyone down.
A public, versioned dataset fixes that. Researchers can cite real numbers instead of guessing. Developers can seed their agents with verified stores instead of crawling from scratch. Platforms can benchmark themselves against the field. The whole ecosystem moves faster when there's a common reference point, and we're in the best position to provide one.

What the data shows

Since we're talking about a dataset, it's worth saying what we actually see in it. The corpus grew fast — from a standing start in January to over 3,000 verified merchants by mid-March.

Dataset Growth — January to March 2026 — UCP Checker Share Embed

Version convergence is essentially complete. 99.8% of stores in the dataset are advertising spec version 2026-01-23. The ecosystem standardized on this version fast — faster than most protocol adoptions we've observed. That's partly Shopify's influence (when Shopify ships a version, 898 stores update in lockstep) but it also reflects that UCP adopters are, by selection, developers who care about spec compliance.
The capability gap is stark. Checkout is nearly universal — 99.96% of verified merchants declare it. But look one capability past that and the numbers collapse. Cart operations drop to 0.07%. Identity linking is at 0.07%. Payment token support is at 0%. The protocol has the capability definitions. The stores mostly haven't implemented them yet.
This is the part of the dataset we expect to move the most over the coming months. As Playground and other agent testing tools give developers concrete evidence that capability depth improves conversion, those numbers will shift. The baseline we're publishing now is a before picture.

Capability Adoption Cliff — 3,000+ UCP stores — UCP Checker Share Embed

The platform breakdown tells a familiar story. Shopify accounts for 898 of the identified stores. Generic (unidentified platform) accounts for 285. The long tail of WooCommerce, Magento, BigCommerce, and custom implementations is real but small compared to the Shopify bloc. This is consistent with what we've written about before — Shopify's platform-level default made UCP table-stakes for their merchants overnight. Everyone else is still climbing.

Go use it

The dataset is at huggingface.co/datasets/UCPChecker/ucp-merchants. Download the CSV, run a notebook, build a tool, write a paper. The license is CC-BY 4.0 — use it for anything, just say where it came from.
We'll cut a new snapshot on the first of each month. If you're tracking adoption over time, watch the Hugging Face page for updates.
If you build something with it — an agent, an analysis, a visualization, a benchmark — we'd genuinely like to know. If you find gaps in the data or coverage you'd expect that isn't there, tell us. And if the base layer isn't enough and you need deeper data for your team, reach out. That conversation is one we want to have.

Download the dataset: huggingface.co/datasets/UCPChecker/ucp-merchants
Check your store: ucpchecker.com
Browse the full directory: ucpchecker.com/directory
Track adoption live: ucpchecker.com/stats

The BigCommerce UCP Guide: The Sleeping Giant of API-First Agent Commerce

Benji Fisher — Thu, 02 Apr 2026 09:07:14 +0000

BigCommerce has very limited UCP adoption in our monitoring dataset — we’ve verified just 2 BigCommerce stores with live UCP implementations, representing under 0.1% of the 2,826 verified UCP merchants we track. The platform’s API-first architecture suggests it should produce clean UCP implementations, and the stores we’ve validated bear that out. With such a small sample, this guide is as much an analysis of what BigCommerce’s architecture makes possible as it is a report on observed data.

That's not accidental. BigCommerce has invested heavily in its API layer and headless commerce capabilities for years. When UCP arrived, the plumbing was already there. Merchants and developers who understand BigCommerce's architecture tend to implement UCP correctly because they're already thinking in terms of APIs, channels, and structured data.

The failure patterns in BigCommerce UCP implementations aren’t random. They cluster tightly around three areas: GraphQL token lifecycle management, channel routing misconfiguration, and headless deployments where the manifest is served from the wrong origin. Know those three failure modes and you’ve covered the most likely production issues.

This guide covers what BigCommerce provides natively, what the manifests actually look like across our monitored stores, where things break, and what it takes to configure your store for reliable AI agent commerce.

What BigCommerce Provides

BigCommerce does not ship native UCP support the way Shopify does. There is no first-party UCP toggle in the control panel. Instead, UCP is delivered through BigCommerce's App Marketplace — merchants install a UCP connector app that integrates with the platform's existing API surface.

This is architecturally different from Shopify's approach, and the difference matters. Because BigCommerce's REST and GraphQL APIs are already well-documented and production-ready, the connector app has a solid foundation to build on. The Storefront GraphQL API handles product discovery and variant resolution. The Management REST API handles order data and store configuration. The MCP transport layer sits on top of both.

Out of the box, a properly installed BigCommerce UCP connector exposes the same core MCP capabilities as Shopify: Checkout (cart management using the Server-to-Server Cart API) and Orders (order status via the V2 and V3 Management APIs). Catalog browsing is part of the UCP spec but is currently in draft status. The quality of each capability depends on which API version the connector uses and whether the relevant API scopes were granted during installation.

BigCommerce's channel-aware architecture is the defining structural characteristic for UCP. Every sales surface in BigCommerce — storefronts, POS, marketplaces, headless frontends — is a channel. Agent commerce is treated as its own channel, which is the correct abstraction. This means a well-configured BigCommerce store can route agent requests to a dedicated channel with its own pricing, catalog visibility, and checkout configuration, completely separate from the standard storefront.

The manifest at /.well-known/ucp is served through BigCommerce's custom pages feature or injected via the Script Manager, depending on how the connector app was configured. Both approaches work. The Script Manager approach is more common in practice and generally more reliable across theme updates.

The Manifest: What We See Across Monitored BigCommerce Stores

BigCommerce manifests are among the more consistently structured in our dataset. The connector app handles manifest generation, and its output is predictable — which makes deviations easier to spot when they occur.

The protocol version declaration is generally current on BigCommerce stores that installed the connector recently. The risk window is stores that have been running UCP for more than a few months without updating the connector app. BigCommerce's App Marketplace doesn't enforce automatic updates, so stores on older connector versions can fall behind the current protocol specification.

The capabilities array on a well-configured BigCommerce manifest should include dev.ucp.shopping.checkout, dev.ucp.shopping.discount, and dev.ucp.shopping.fulfillment at minimum. Stores using BigCommerce's B2B Edition — which adds company accounts, price lists, and purchase orders — should also declare B2B capabilities, but many don't. B2B Edition stores often have manifests that undersell their capabilities, causing agents to fall back to simpler B2C workflows on stores that could support negotiated pricing and purchase order flows.

The transport configuration is where BigCommerce manifests diverge most from Shopify. Shopify manifests reliably declare a single MCP endpoint. BigCommerce manifests can declare multiple transport paths depending on how the connector app routes different request types — some using the REST API, some using the GraphQL Storefront API. This is fine when it's intentional and correctly declared. It becomes a problem when the GraphQL transport endpoint carries an access token that's embedded in the manifest and subject to expiration.

The payment handlers section reflects BigCommerce's broad payment ecosystem. Native support for PayPal, Stripe, Braintree, Square, Adyen, Amazon Pay, and dozens of regional gateways means a well-configured manifest has a rich payment section. When merchants add or remove payment providers without triggering a manifest re-sync, the payment section silently drifts from reality — one of the most common issues we flag on BigCommerce stores.

For stores using Multi-Storefront (MSF), each storefront can and should have its own manifest. A BigCommerce instance running three storefronts — say, a retail brand, a B2B portal, and a regional market — needs three distinct UCP configurations. A common MSF mistake is having only the primary storefront with a current manifest, while secondary storefronts are either missing UCP entirely or serving a manifest copied from the primary with incorrect endpoint URLs.

Common Manifest Issues We Flag

The most common issues we’ve identified in BigCommerce UCP configurations are: expired GraphQL Storefront API tokens embedded in manifest transport declarations (the token was valid at install time but rotates on a schedule the connector app doesn't handle automatically), stale payment declarations after provider changes, MSF storefronts with missing or misrouted manifests, headless deployments where the manifest origin doesn't match the storefront domain, and undersized capabilities arrays on B2B Edition stores.

The GraphQL token issue deserves special mention because it's the failure mode most likely to affect you without warning. The token appears valid when the manifest is fetched — the JSON is well-formed, the endpoint URL resolves — but when an agent attempts a product search using the declared GraphQL transport, the 401 response is silent from the manifest's perspective. Monitoring tools that only check the manifest structure won't catch it. UCP Checker's runtime checks do.

Runtime Performance: Competitive With Shopify, Architecture-Dependent

BigCommerce is a managed SaaS platform, which means its baseline performance profile is comparable to Shopify — and significantly more consistent than self-hosted platforms like Magento or WooCommerce on variable hosting.

Across the 2 BigCommerce stores in our dataset, MCP tool call response times were 729ms and 894ms — significantly slower than Shopify’s median of 146ms. Our sample is too small to draw strong conclusions about the platform’s typical performance range, but both stores run on managed SaaS infrastructure, so the 729–894ms range likely reflects the overhead of BigCommerce’s API routing architecture. The GraphQL Storefront API is generally faster for product discovery, while REST-backed operations like checkout and order management tend to add additional latency.

Headless BigCommerce deployments — those using Next.js, Gatsby, or other frontend frameworks decoupled from the Stencil theme engine — add a layer of variability. The performance of the decoupled frontend itself doesn't affect MCP response times directly, but it can affect manifest availability and origin resolution. Headless stores that serve the manifest from the frontend origin rather than the BigCommerce-managed origin sometimes get different caching behavior than expected.

Tool availability on well-configured BigCommerce stores is high. When we run tools/list against stores with current connector versions and valid API tokens, the core tools are available. The failure mode is specifically those stores with expired GraphQL tokens — they pass manifest validation but fail tool availability checks at runtime.

Checkout completion rates on BigCommerce are competitive, with one important caveat: stores using BigCommerce's Optimized One-Page Checkout (OPC) with custom modifications introduce the same class of problems we see on WooCommerce stores with heavily-modified checkout pages. Standard OPC configurations work correctly with agent checkouts. Custom fields added via checkout scripts can break the automated flow if they're configured as required inputs with JavaScript validation that the MCP checkout tool can't satisfy.

Configuration Checklist

Based on our monitoring data, here are the five steps that separate BigCommerce stores that perform reliably in agent sessions from stores that pass the basic check but fail in production.

First, install the UCP connector app and complete the full API scope grant. Partial installations — where the connector was authorized with a reduced API scope to limit access — are a consistent source of checkout and order tool failures. The connector needs read/write access to carts, checkouts, and orders. Restrictive scope grants will produce a valid manifest with tools that silently fail on specific operations.

Second, check your GraphQL Storefront API token lifecycle. If your UCP connector uses an embedded GraphQL token in the manifest transport declaration, find out how that token is rotated and whether the connector handles rotation automatically. If it doesn't, set a calendar reminder to re-authorize the connector before the token expires. Then run a check at ucpchecker.com/check immediately after rotation to confirm the new token is correctly propagated.

Third, if you're running Multi-Storefront, configure UCP on each storefront independently. Don't copy the primary manifest to secondary storefronts and assume it will work. Each storefront has its own channel ID, its own API endpoints, and potentially its own payment configuration. The manifest for each storefront needs to reflect its specific channel context.

Fourth, test checkout completion on your specific configuration. Run a real agent session from product discovery through to order confirmation. If you have custom checkout scripts, loyalty integrations, or B2B pricing logic, test explicitly with those active. The standard manifest check won't catch checkout-layer failures — only a real session will.

Fifth, set up UCP Alerts. BigCommerce connector app updates, payment provider changes, and API credential rotations can all silently modify your manifest or break your transport. Alerts give you visibility when something changes so you can investigate before agents encounter the failure in a live session.

Multi-Storefront and Channel Considerations

BigCommerce's Multi-Storefront feature is architecturally similar to Magento's multi-store capability in its complexity, but delivered in a managed SaaS context that removes most of the infrastructure headaches. What remains is the configuration challenge: each storefront is an independent UCP surface that needs its own manifest, its own API scope grants, and its own channel routing configuration.

Channel routing is the core concept to understand. In BigCommerce's architecture, every request is associated with a channel. The UCP connector needs to map agent requests to the correct channel — typically the storefront channel the merchant wants agent commerce to flow through. When this mapping is misconfigured, agents may receive responses scoped to the wrong storefront: incorrect catalog, incorrect pricing, incorrect currency, potentially even a test store environment.

Three common channel routing failure patterns can appear in MSF deployments. The first is agents hitting the default channel rather than a configured agent commerce channel, resulting in catalog responses that include items not intended for agent-driven sales. The second is currency mismatch: a storefront configured for EUR pricing routing agent requests through a USD channel, producing pricing responses that agents accept but buyers see differently. The third is the B2B channel problem — agents authenticated as guest users being routed to a B2C channel when the merchant intended them to access B2B pricing.

If you're running MSF, the right approach is to create a dedicated channel for agent commerce and configure the UCP connector to route all MCP requests through it. This gives you explicit control over what agents can see, buy, and pay — and isolates agent traffic from your standard storefront analytics so you can measure it separately.

For headless BigCommerce deployments, the manifest origin question requires explicit attention. If your frontend is served from shop.yourbrand.com but your BigCommerce-managed origin is yourbrand.mybigcommerce.com, agents discovering your store need to find the manifest at the right domain. Typically this means the manifest should be served from the customer-facing domain, not the BigCommerce subdomain. The connector app can usually be configured to support this, but it needs to be set up deliberately.

Common Failure Modes

Four failure patterns come up repeatedly in our BigCommerce monitoring data.

GraphQL Storefront API token expiration. This is the most common and the most invisible. The UCP connector embeds a GraphQL access token in the manifest transport declaration at installation time. When that token expires — and all Storefront API tokens eventually expire — the manifest continues to look valid from the outside. Agents fetch it, parse the transport configuration, and attempt product queries using the embedded token. The 401 response is returned at the API layer, not the manifest layer. Manifest-only validation tools report no problem. Your store silently fails every product discovery request. The fix is to rotate the token and update the connector configuration, then verify the manifest reflects the new token. If your connector doesn't handle this automatically, you need a process to catch it before agents do.

Channel routing sending agent requests to the wrong storefront. This produces some of the hardest-to-diagnose failures we encounter in monitoring. The manifest is valid. The API endpoints respond correctly. Agents complete sessions and produce what look like successful checkouts. But the orders land on a different storefront than expected — a test channel, a marketplace channel, or a secondary storefront — and the fulfillment team never sees them. If your BigCommerce instance has multiple channels, explicitly configure and test the channel your UCP connector routes to. Don't assume it defaults to the right one.

Optimized One-Page Checkout conflicts with custom scripts. BigCommerce's OPC is well-suited to agent checkouts in its standard configuration. The problems arise with custom checkout scripts that add required fields — loyalty membership IDs, company account selectors for B2B stores, custom gift options — that the MCP checkout tool can't populate because they require JavaScript interaction or aren't exposed in the Server-to-Server Cart API. Agents that reach the final checkout step and encounter an unresolvable required field will abort the transaction. Audit your checkout scripts for required fields before going live with UCP.

Headless deployments serving the manifest from the wrong origin. Headless BigCommerce stores — those using Next.js or similar frameworks decoupled from Stencil — sometimes misconfigure which domain serves the UCP manifest. If the manifest is served from the BigCommerce-managed subdomain but agents discover the store at the custom domain, the manifest origin doesn't match the store's public identity. Some agents treat this as a trust failure and won't proceed. Ensure your manifest is served from your primary customer-facing domain and that the transport endpoint URLs in the manifest use the same domain.

Product Feed Best Practices

BigCommerce's product data model is one of the more capable in the market — native support for variants, custom fields, metafields, and the Catalog API's structured product hierarchy means there's no shortage of data to work with. The challenge is exposing it correctly through the UCP layer.

Use metafields for agent-relevant product attributes. BigCommerce's metafields API lets you attach structured key-value data to products, variants, and categories. For agent commerce, this is the right place to put attributes that matter for agent decision-making but don't fit neatly into standard product fields: care instructions, compatibility information, sizing notes, assembly requirements. Agents that can access metafield data make better recommendations and have lower clarification rates. Ensure your UCP connector is configured to expose product metafields in its Discovery tool responses.

Keep variant complexity manageable. BigCommerce supports up to 600 variants per product, which is a product management feature that becomes an agent commerce liability when used carelessly. An agent attempting to resolve a specific variant from a product with dozens of option combinations across three dimensions is doing significantly more work than one navigating a product with a clean, well-structured option set. For your highest-traffic products, audit the variant matrix for clarity — agents and humans alike navigate them better when options are logically structured.

Set accurate stock levels and availability signals. BigCommerce's inventory tracking is granular and reliable when maintained. UCP agents rely on the availability signals returned by the Catalog API to make add-to-cart decisions. Products shown as in-stock that fail at checkout — because the inventory wasn't updated after a bulk sale, or because stock tracking was disabled for a product category — produce failed agent sessions and degraded trust in your store as a reliable agent commerce destination.

Configure multi-currency correctly per channel. Unlike WooCommerce, which requires plugins for multi-currency, BigCommerce has native multi-currency support built into its channel architecture. But it requires explicit configuration per channel. If your agent commerce channel isn't configured with the correct transactional currency — the one you actually want agent purchases denominated in — you'll get currency mismatch issues at checkout. Verify this in your channel settings before enabling UCP agent traffic.

Structured data on storefront pages. For stores using Stencil themes, ensure your product pages include Schema.org Product markup. This creates a secondary discovery path for agents that discover products through web crawling before connecting via MCP. The markup should include product name, description, price with currency, availability, brand, SKU, and image URLs. BigCommerce's Stencil framework makes this straightforward to implement — and it serves double duty as structured data for traditional search engines.

What's Coming

BigCommerce's API-first philosophy positions it well for the next generation of UCP capabilities. Two developments are particularly relevant to BigCommerce merchants planning their agent commerce roadmap.

The first is B2B Edition integration with UCP. BigCommerce's B2B Edition — with its company accounts, price lists, and purchase order workflows — is an underdeveloped UCP surface. Most B2B Edition stores we monitor aren't exposing their B2B capabilities through UCP at all, which means agents are interacting with them as generic B2C stores. As UCP's B2B capability declarations mature and connector apps update to support them, BigCommerce B2B Edition stores have significant upside from exposing negotiated pricing and account-aware purchasing to AI buyers.

The second is webhook-driven manifest updates. BigCommerce's webhook infrastructure is robust enough to trigger automatic manifest refreshes when catalog, pricing, or payment configuration changes. Some advanced implementations already take this approach — manifest changes propagate within minutes of a store update rather than waiting for a manual re-sync or scheduled job. This will likely become standard practice as the connector app ecosystem matures and best practices solidify.

We track emerging capability adoption across all platforms through our stats dashboard. The BigCommerce segment is smaller than Shopify's but its quality distribution is a useful leading indicator of what well-implemented UCP looks like in practice.

Check Your Store

If you're running a BigCommerce store and haven't verified your UCP configuration, run a check at ucpchecker.com. The check validates your manifest structure, protocol version, and capabilities declaration — and our runtime checks will surface GraphQL token issues that manifest-only validators miss.

If you're running Multi-Storefront, run the check against each storefront domain separately. A passing result on your primary storefront doesn't tell you anything about the configuration state of your secondary storefronts.

Once you're in our directory, set up UCP Alerts so you're notified when we detect a change in your manifest. Token rotations, connector updates, and payment configuration changes can all silently modify your manifest. Catching those changes before agents encounter them is the difference between managed UCP health and discovering problems through failed sessions.

And if you want to see how real AI agents experience your BigCommerce store — including whether that GraphQL token is actually working end-to-end — UCP Playground lets you run live agent sessions against your store. It's the fastest way to validate that your channel routing is correct and your checkout flow completes without interruption.

References & Official Resources

Commerce Supports Universal Commerce Protocol — BigCommerce’s parent company endorses UCP at NRF (January 2026)
Universal Commerce Protocol (UCP) Explained — BigCommerce Blog
Commerce Investor Relations: UCP Announcement — Plans to offer buying directly across Google AI surfaces
Google: New Tech and Tools for Retailers in an Agentic Shopping Era
UCP Specification — ucp.dev

Related Platform Guides

Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:

The Magento UCP Guide: What Enterprise Monitoring Data Tells Us About Adobe Commerce Agent Readiness

Benji Fisher — Wed, 01 Apr 2026 09:12:30 +0000

As of our most recent scan across 3,235 domains, we have not verified a single Magento or Adobe Commerce store with a live UCP implementation. Magento UCP adoption is effectively zero today. That doesn’t mean it’s impossible — the platform has the technical foundation for it — but this guide is written based on technical analysis of the platform’s architecture, rather than observed monitoring data from live stores.

The gap between configuration and runtime reality is what we expect will be the defining challenge of Magento UCP deployments. A Shopify store either has UCP working or it doesn’t. A Magento store — given the platform’s infrastructure complexity — can appear to have a valid manifest, pass a surface-level check, and still deliver broken agent sessions at runtime because of Varnish caching, REST API restrictions, or module interceptors modifying response payloads. This guide is written in anticipation of these deployments.

This guide covers what we've learned monitoring Magento and Adobe Commerce stores: what the platform requires, what the manifests actually look like at enterprise scale, where things break, and what it takes to run reliably for AI agents. The audience here isn't a solo merchant toggling a plugin — it's the dev team that owns the platform and needs to understand what UCP compliance means in a heavily customized environment.

What Magento Requires

Magento has no native UCP support. Unlike Shopify, which ships the Universal Commerce Agent capability as a first-party app, Magento requires a Composer-installable module that integrates with the platform's service layer. There is no admin panel toggle, no app store install, no one-click activation.

The module handles three things: registering a custom controller route that serves the /.well-known/ucp manifest, wiring up an MCP transport endpoint through Magento's REST API layer, and exposing catalog, cart, and checkout operations as structured MCP tools. Installing it requires Composer access, a code deployment pipeline, and a developer who understands Magento's dependency injection framework.

Minimum requirement for stable compatibility is Magento 2.4.7. Earlier versions of the 2.4.x line have known issues with the REST API authentication flow that the UCP module depends on, and anything pre-2.4 is not supported. Adobe Commerce Cloud deployments on the current managed stack are generally compatible out of the box.

Beyond the module itself, your infrastructure stack determines how hard UCP implementation actually is. The full Magento production stack — PHP-FPM, MySQL or MariaDB, Elasticsearch or OpenSearch, Redis, Varnish, and optionally RabbitMQ for async processing — has multiple layers that can interfere with how the manifest is served and how MCP requests are handled. Each component needs to be explicitly configured to let UCP traffic through correctly. This is not a concern on Shopify or a basic WooCommerce stack. On Magento, it is the central implementation challenge.

The Manifest: What We See Across Enterprise Monitoring

Your UCP manifest at /.well-known/ucp is the entry point for every AI agent that discovers your store. On Magento, the manifest is generated by the module and served via the custom controller route. What agents actually receive, however, depends heavily on what your infrastructure does with that request before it hits the controller — and on Magento stores, the infrastructure layer is rarely neutral.

The first thing we check is whether the manifest is actually being served dynamically. In a correctly configured Magento stack, /.well-known/ucp bypasses Varnish and is served directly from the application. In incorrectly configured stacks — the most common misconfiguration on this type of infrastructure — Varnish is likely to cache the response. We'll cover this in detail in the failure modes section, but the practical consequence is that manifest updates (new capabilities, key rotations, payment provider changes) don't propagate to agents until the cache expires or is manually purged.

The protocol version field is likely to be more variable on Magento than on any other platform. Because there is no platform-managed update cycle, stores running the UCP module must manually update it to stay current with the specification. We’d expect a wider spread of protocol versions on Magento than on Shopify — stores that install the module and don’t maintain it will fall behind the current spec, which well-implemented agents may reject during version negotiation.

The capabilities array on Magento manifests requires explicit configuration. The module does not infer capabilities from your store's installed feature set the way Shopify's app does. A store with B2B shared catalogs enabled will not automatically declare a B2B capability unless the module is configured to do so. This creates a predictable pattern: Magento manifests that are technically valid but undersell the store’s actual capabilities, causing agents to attempt simpler workflows than the store could support.

The payment handlers section requires manual maintenance. When you add Adobe Payment Services, Braintree, Adyen, or any other payment extension, the UCP module does not automatically detect the change. Someone needs to update the manifest configuration. Stale payment declarations are likely to be the second most common issue after Varnish caching problems.

Finally, for stores using multi-website or multi-store architecture, each storefront needs to declare its own manifest correctly. A single Magento instance running three storefronts with different product catalogs, currencies, and payment methods has three distinct UCP configurations to maintain. We frequently see stores where the default website has a current manifest but secondary store views are serving outdated or incorrectly scoped declarations.

Common Manifest Issues We Flag

Based on the platform’s architecture, the most likely issues to encounter in a Magento UCP deployment are: Varnish-cached manifests (the manifest was correct when deployed but changes haven't propagated because the cache was never purged), stale payment declarations (payment methods added or removed after initial module setup without a manifest update), missing or expired signing keys (particularly on stores that had a security audit requiring key rotation but didn't update the UCP configuration), undersized capabilities arrays (the manifest declares fewer capabilities than the store actually supports), and incorrect transport URLs (the MCP endpoint URL in the manifest points to a path that's been modified by a third-party security extension or WAF rewrite rule).

None of these produce a hard manifest validation error. An agent will fetch the manifest, parse it, and attempt to start a session — only to encounter failures that trace back to the manifest not accurately describing the store's current state.

Runtime Performance: Infrastructure-Dependent

Magento's performance profile is fundamentally different from Shopify's. Shopify stores the infrastructure and its performance profile is relatively consistent across merchants. Magento performance is as variable as the hardware it runs on — which ranges from shared hosting running a decade-old stack to Adobe Commerce Cloud backed by managed Fastly CDN.

Based on Magento’s infrastructure characteristics, we’d expect MCP tool call response times between 600ms and 1,500ms on self-hosted infrastructure — significantly slower than Shopify’s median of 146ms. For agent workflows that execute multiple sequential tool calls, this compounds: a product search → variant resolution → cart add → checkout sequence that takes well under a second on Shopify could take 8–12 seconds on a heavily customized Magento store without full-page cache warming.

Adobe Commerce Cloud deployments should perform substantially better. The managed Fastly CDN layer, optimized PHP-FPM configuration, and managed Elasticsearch should reduce median response times to the 350–600ms range — considerably closer to Shopify territory. If you have the option to migrate to Commerce Cloud and runtime performance for agent sessions is a concern, the infrastructure improvements are well-established.

On self-hosted Magento, the configuration decisions that most affect agent session performance are: Redis for session and full-page cache (dramatically reduces PHP processing per request), Elasticsearch or OpenSearch properly indexed and warmed (product search latency drops from 800ms+ to under 100ms), and PHP OPcache enabled and sized correctly (eliminates per-request compilation overhead). These aren't UCP-specific recommendations — they're standard Magento performance practices — but their absence is directly visible in agent session benchmarks.

Tool availability is likely to vary significantly on Magento. On stores with incomplete ACL permission configurations, agents attempting to call the catalog or checkout MCP tools receive authorization errors even for unauthenticated browsing operations. On stores where a third-party security extension has rewritten API routes, the tool endpoints declared in the manifest don't respond. tools/list returning a complete tool set doesn't mean those tools work — we validate this separately in our benchmark checks.

Configuration Checklist

Based on our monitoring data, here are five configuration steps that separate Magento stores that perform reliably for agent sessions from those that pass manifest validation but break at runtime.

First, exclude /.well-known/ucp from Varnish caching. This is the single most impactful configuration change you can make. Add the path to your Varnish VCL exclusion list and verify the exclusion is active. The check is simple: deploy a manifest change, wait 30 seconds, and fetch the URL directly from an IP that isn't cached — if you see the old manifest, Varnish is still serving it. Our monitoring catches this automatically: if we detect a manifest change lag of more than 5 minutes between deployment and propagation, we flag the store.

Second, audit your REST API ACL permissions. Magento's ACL system controls which API resources are accessible to which user roles. The UCP module requires specific REST API routes to be available for anonymous or token-authenticated access depending on your configuration. After installation, explicitly verify that the MCP endpoint routes are accessible without triggering a 401 or 403. Test from an IP with no prior Magento session — stores frequently work in testing because the tester is authenticated as an admin, but fail for agents that arrive unauthenticated.

Third, verify your manifest at ucpchecker.com/check. Run the check immediately after initial setup and after every deployment that touches payment configuration, API routes, or security settings. Review the capabilities and transport sections specifically. If you're running multi-website architecture, check each storefront URL independently — manifests are per-website, not per-instance.

Fourth, test your MCP endpoints through your WAF and CDN, not just locally. The most common source of "works in staging, broken in production" issues on Magento is a WAF or CDN rule that blocks or modifies the MCP traffic. Agent requests look different from browser requests — different headers, different user-agent strings, different request patterns. Run a validation check from outside your network before declaring the implementation complete.

Fifth, set up UCP Alerts. Magento deployments involve many moving parts — module updates, security patches, payment gateway updates, infrastructure changes. Any of these can silently alter your manifest or break your MCP endpoints. Alerts catch regressions before they compound into sustained agent session failures that affect real transactions.

Multi-Store and B2B Considerations

Magento's multi-website and multi-store architecture is one of its defining enterprise capabilities — and one of the most significant sources of UCP complexity we see in our monitoring data. A single Magento instance can serve multiple storefronts, each with its own domain, product catalog, pricing, currency, and payment configuration. Each of those storefronts is a distinct UCP entity that requires its own manifest.

The practical challenge is that Magento's multi-store architecture was designed for human shoppers navigating a browser. AI agents don't have sessions. They don't follow store-switcher UI. They access a domain, fetch the manifest, and connect via MCP. If your secondary storefronts don't have correctly configured manifests at their respective /.well-known/ucp paths, agents reaching those storefronts get nothing — or get the wrong manifest if Magento defaults to the primary website's response.

A common pattern to watch for: the flagship storefront has a current, valid manifest while the B2B portal on a subdomain serves a stale manifest because the dev team configured the primary instance and assumed it propagated. It doesn’t. Each store view with a distinct domain requires explicit manifest configuration and independent monitoring.

B2B features add further complexity. Adobe Commerce's B2B module supports shared catalogs (different product visibility and pricing per company account), company accounts and approval workflows, and requisition lists that function as persistent carts. These capabilities aren't part of the base UCP specification — agents that encounter them need the manifest to correctly declare what B2B features are available and what they require in terms of authentication. A B2B buyer whose agent tries to add an item to a requisition list that requires company account authentication will get an authorization error with no clear indication of why.

The current best practice for B2B Magento UCP implementations is to declare B2B capabilities explicitly in your manifest if they're enabled, provide clear authentication scope requirements, and test agent sessions with both unauthenticated and authenticated company account contexts. The authenticated path is often where the enterprise GMV lives — if agents can't reliably complete approved purchases through the company account flow, the UCP implementation has limited value for your actual buyer population.

Common Failure Modes

Four failure patterns are likely to appear in Magento UCP deployments, based on the platform’s architecture and infrastructure complexity. Each is distinct from what we observe on other platforms.

Varnish serving stale manifests. This is the most predictable failure mode on Magento infrastructure and the one most likely to catch merchants off-guard. Varnish's default behavior is to cache everything it can, including responses from paths that look like static files. /.well-known/ucp looks like a static resource to Varnish. Without an explicit exclusion in your VCL, every manifest update you deploy will be invisible to agents until the cached response expires — which, depending on your TTL configuration, could be hours or days. It’s entirely possible for a key rotation deployed on Monday to go unnoticed by agents until Wednesday if Varnish TTLs are measured in days. Agents encountering an expired key receive authentication failures with no indication that the manifest itself is the problem.

REST API routes disabled or restricted. Magento's REST API can be restricted at the module level, at the ACL level, and at the server level (by a WAF or reverse proxy rule). The UCP module uses REST as its MCP transport layer. When any of these restrictions unexpectedly blocks MCP traffic, agents receive errors that look like authentication or authorization failures — not like "the endpoint doesn't exist." Diagnosing this requires tracing the request from the agent through your full infrastructure stack, which on a heavily customized Magento deployment can involve six or more layers. The shortest path to a diagnosis is running a raw REST API call to your MCP endpoint from an external IP with no cached credentials and checking the actual HTTP response.

DI interceptors silently modifying response payloads. Magento's dependency injection and plugin/interceptor system allows any installed module to modify the inputs or outputs of any service class without touching the original code. This is a powerful extension mechanism for human-facing commerce features — and a significant source of unpredictable behavior for AI agents. A payment module’s interceptor can add a custom field to the checkout response payload that breaks the MCP tool’s JSON schema validation. The checkout would work fine for human shoppers because browser-side JavaScript would ignore the extra field — but the agent, expecting a strict schema, would fail. Identifying these interceptors requires code-level investigation: run bin/magento dev:di:info for the service classes your MCP module uses and audit every registered plugin for potential payload modifications.

Elasticsearch index lag causing catalog discrepancies. Magento's product search runs through Elasticsearch or OpenSearch. When you update product data — price changes, availability updates, new variants — those changes don't immediately appear in search results. They propagate through an indexing queue, which on a busy store with a large catalog can lag 15–60 minutes behind the source of truth in MySQL. An agent running product discovery through the MCP search tool may find a product at yesterday's price, add it to a cart, and then receive a different total at checkout because the MySQL price was updated in the interim. This isn't a UCP-specific problem — it's a fundamental characteristic of Magento's search architecture. The mitigation is ensuring your indexer is running on a tight schedule (bin/magento indexer:set-mode schedule) and configuring realtime reindex triggers for high-velocity data like price and inventory.

Product Feed Best Practices

Magento's Extended Attribute Value (EAV) data model gives merchants fine-grained control over product attributes — more flexibility than Shopify or WooCommerce. It also means product data quality varies more widely across Magento stores than on any other platform we monitor. Custom attributes are easy to add and easy to leave half-configured. When agents try to navigate that data, the gaps show up immediately.

Here's what matters for agent-readable product feeds on Magento:

Configurable products need complete variant trees. Magento's configurable product type is how most stores handle size/color/material combinations. Each configuration attribute needs to be properly linked to child simple products, with every variant having an explicit SKU, price, and stock status. Agents resolving a "blue size L" request need to follow the configurable → simple product tree cleanly. We see stores where variants were deleted from the admin but not delinked from the parent, leaving the MCP tool returning variant options that point to nonexistent products.

Keep custom attributes typed correctly. EAV's flexibility means merchants add custom attributes without thinking carefully about data type. A numeric attribute stored as a varchar, a boolean attribute that contains "Yes"/"No" strings instead of 1/0, a multiselect attribute whose option values are internal IDs instead of human-readable labels — all of these create parsing problems for agents that expect structured, typed data. Audit your product attribute configuration and ensure the attributes exposed via MCP have predictable, correctly typed values.

Set priceCurrency on every offer. On multi-website Magento setups with multiple base currencies, this is especially important. Each store view may have its own currency and pricing tier. Agents that receive product data without explicit currency context can't reliably present pricing to buyers or compare across session contexts. Every product offer exposed through the MCP catalog tool should declare its currency explicitly.

Filter your MCP-facing catalog to match the public storefront. Magento's attribute set and product visibility settings control what appears on the storefront. The MCP module needs to apply the same visibility filters. Disabled products, products assigned to inactive websites, and products with “Not Visible Individually” visibility settings can surface in MCP catalog responses if the module doesn’t correctly apply visibility filters. An agent that finds a product, adds it to a cart, and receives an error at checkout because the product isn't purchasable is delivering a broken session — and that store is the one the agent won't recommend.

Ensure Elasticsearch index freshness matches your commerce velocity. If you run flash sales, daily pricing changes, or frequent inventory updates, your search index needs to reflect those changes on a timeline compatible with agent session behavior. Agents don't tolerate stale data the way human shoppers do — a shopper who sees a sale price and gets a different total at checkout might complete the purchase anyway. An agent validating totals before confirmation will abort. Run your indexers on schedule mode and monitor for queue backlog during high-traffic periods.

Images need descriptive alt text. This is standard accessibility practice and equally important for agent sessions. "product-image-1.jpg" gives an agent nothing to work with. "Adobe Indigo slim-fit chino — front view — ink blue" gives it everything. On Magento, images are often managed through a bulk import process where alt text is omitted. Review your image metadata, particularly for high-velocity product categories where agents are most likely to be doing visual confirmation before adding to cart.

Structured data on product pages matters for discovery. Agents that discover products through web crawling before connecting via MCP rely on Schema.org Product markup on your storefront pages. Magento's default themes include some structured data but it's often incomplete or misconfigured, especially on heavily customized storefronts. Ensure your product pages include: name, description, price with currency, availability, brand, SKU, image URLs, and if you're running B2B, appropriate organization-level restrictions. This creates a discovery path that doesn't depend on the MCP module being correctly configured before an agent can find your store.

What's Coming

Two developments in the UCP specification are particularly relevant for enterprise Magento deployments. The first is persistent cart and session handoff — the ability for an agent to build a cart that a human buyer can then complete in a browser. For B2B scenarios where purchase approval is required, this is the capability that makes agentic commerce actually practical: an agent qualifies the order and builds the cart, a purchasing manager reviews and approves it, checkout completes with human authorization. Magento's existing quote management system maps well to this model.

The second is identity linking — agents authenticating as known customers and accessing account history, loyalty tiers, saved addresses, and company account context. On Adobe Commerce's B2B module, this is where the real enterprise value is. An agent that can access a company's purchase history, check requisition list contents, and complete a reorder against a negotiated catalog price is dramatically more useful than one that can only browse the public catalog. The infrastructure for this exists in Commerce today — the UCP specification is catching up to it.

We track adoption of emerging capabilities through our stats dashboard and publish deeper analysis in the State of Agentic Commerce reports. Enterprise adoption tends to lag consumer platforms by 12–18 months on new protocol features — but the GMV concentration in enterprise Magento accounts means when adoption does happen, it moves markets.

Check Your Store

If you're running Magento or Adobe Commerce and haven't run a UCP check yet, start there. The check validates your manifest, verifies your MCP endpoints are reachable from outside your network, and surfaces the most common configuration issues. It will tell you things your internal staging environment won't, because it tests from the perspective of an agent arriving at your store cold — no cached credentials, no prior session, no whitelisted IP.

If you're already in our directory, set up UCP Alerts. The failure modes that matter most on Magento — Varnish cache serving stale manifests, REST API routes unexpectedly going offline after a deployment, signing keys expiring — are invisible unless you're monitoring continuously. A valid manifest at launch doesn't stay valid indefinitely on a platform that gets as many security patches and third-party module updates as Magento does.

And if you want to see how AI agents actually experience your store end-to-end — not just whether the manifest validates, but whether agents can complete product discovery, variant resolution, and checkout on your specific implementation — UCP Playground runs real agent sessions against live stores. Enterprise Magento customizations create edge cases that manifest validation can't surface. Real session benchmarks find them before your buyers' agents do.

References & Official Resources

Adobe Commerce Commits to Agentic Commerce Standards — Adobe’s official commitment to UCP, ACP, and AP2
Adobe Commerce Catalog Optimization for AI Agent Discoverability
Google: New Tech and Tools for Retailers in an Agentic Shopping Era
Under the Hood: Universal Commerce Protocol — Google Developers Blog
UCP Specification — ucp.dev

Related Platform Guides

Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:

The WooCommerce UCP Guide: What Our Monitoring Data Reveals About WordPress Agent Commerce

Benji Fisher — Tue, 31 Mar 2026 12:11:35 +0000

WooCommerce UCP adoption is in its very early stages. Our current monitoring dataset includes just 3 verified WooCommerce stores — a small fraction of the broader UCP ecosystem, where Shopify accounts for over 99% of verified merchants. Even with a limited dataset, the patterns we see are consistent with what you’d expect from WordPress-based infrastructure: more configuration complexity, more hosting variability, and more ways for things to silently break.

WooCommerce powers somewhere between 25% and 30% of all e-commerce stores globally, and WordPress’s plugin ecosystem means a UCP implementation can ship as a drop-in extension without Automattic needing to build it into core. That’s exactly the path adoption has started to take — but it’s early, and the infrastructure complexity means getting it right requires more deliberate effort than on managed platforms.

The picture is more complicated than Shopify. WooCommerce gives merchants complete control over their UCP implementation, which means more configuration flexibility — and far more ways to misconfigure it. This guide covers what we've learned monitoring WordPress-based stores: what you need to install and configure, what the manifests actually look like across our dataset, and what breaks in production agent sessions.

What WooCommerce Requires (vs. What Shopify Provides Natively)

The first thing to understand about WooCommerce UCP is that nothing is automatic. Where Shopify generates and serves a UCP manifest the moment you install the Universal Commerce Agent app, WooCommerce requires a dedicated WordPress plugin that you install, configure, and maintain separately from your store.

The plugin handles three things: serving the /.well-known/ucp manifest file, registering a REST API endpoint that acts as your MCP transport, and exposing your WooCommerce product catalog, cart, and checkout flows as MCP tools.

The most established option we've validated in our testing is UCPReady by Zologic, which handles manifest generation, MCP transport, and automatic capability detection.

The installation process is straightforward — activate the plugin, generate your manifest keys, configure your capabilities. What catches merchants is everything after that: cache invalidation, security plugin whitelisting, PHP memory allocation, and making sure your REST API is actually accessible to external agents. Each of these is a WordPress infrastructure concern, not a WooCommerce one, which means the troubleshooting surface is larger than on managed platforms.

There is also no equivalent to Shopify's automatic manifest updates when your payment stack changes. On WooCommerce, if you add a new payment gateway — WooCommerce supports over 100 via extensions — your manifest doesn't automatically reflect the change. You need to resync it manually or configure the plugin to auto-regenerate on gateway change. We flag stale payment handler declarations in our monitoring data, and WooCommerce stores — given the manual update requirement — are more prone to this issue than Shopify stores.

The Manifest: What We See Across Our WooCommerce Dataset

Your UCP manifest is the JSON document at /.well-known/ucp that tells AI agents what your store supports and how to connect to it. On WooCommerce, this file is generated by the plugin and cached — how it is cached, and when that cache is invalidated, is one of the most consequential decisions in your setup.

The first thing we check is whether the manifest is reachable at all. A common issue on WooCommerce stores is the manifest returning a 404 or a cached HTML error page instead of valid JSON. This almost always traces to a caching plugin that has cached the /.well-known/ path as a static HTML page, or a security plugin that blocks direct file access to that path. Both are fixable but require explicit configuration.

The second is the protocol version. WooCommerce UCP deployments show more version fragmentation than Shopify, because plugin updates are not as seamless as platform updates. We see a meaningful share of WooCommerce stores still on 2026-01-11, and a small number on pre-release configurations that declare non-standard version strings. Agents with strict version negotiation will refuse to interact with these stores entirely.

Third is the capabilities array. A properly configured WooCommerce store should declare dev.ucp.shopping.checkout, dev.ucp.shopping.discovery, and — if configured — dev.ucp.shopping.discount. The discount capability is the most variable: WooCommerce handles discounts through a combination of coupon codes, cart rules, and extension-specific logic that doesn't always map cleanly to the UCP discount model. Many stores declare it in the manifest but the actual MCP tool implementation is incomplete.

Fourth is the transports block. WooCommerce stores declare MCP over the WordPress REST API, typically at a path like /wp-json/ucp/v1/mcp. This is correct, but the REST API endpoint must be explicitly whitelisted in your security configuration. We see a significant share of WooCommerce stores where the manifest correctly declares the MCP transport but the endpoint itself returns a 401 or 403 for unauthenticated requests — which is what most agent clients send for initial tool discovery.

Common Manifest Issues We Flag

The most frequently flagged issues across our WooCommerce monitoring dataset: cached manifest serving stale content (the manifest was generated before a configuration change and the cache has not been busted), payment handlers out of sync (a gateway was added or removed without a manifest resync), REST API endpoint blocked (a security plugin or WAF rule is returning a non-JSON response to agent requests), and capabilities declared but not implemented (the discount tool is listed in the manifest but the endpoint returns an error when an agent calls it).

None of these cause a hard failure on a basic manifest fetch. A checker that only validates whether the JSON is well-formed will pass these stores. Our checks simulate what an agent actually does — fetch the manifest, enumerate the tools, call the endpoint — which is why we catch issues that a simple validation pass misses.

Runtime Performance: Hosting Matters Enormously

This is the biggest difference between WooCommerce and Shopify from a performance standpoint: on Shopify, your store runs on Shopify's global infrastructure. On WooCommerce, your store runs on whatever you chose to host it on — and the performance range is enormous.

Across the WooCommerce stores in our dataset, MCP tool call response times ranged from 510ms to 1,593ms, with an average around 980ms — significantly slower than Shopify’s median of 146ms. Our sample is small, but this is consistent with what you’d expect from PHP-based self-hosted infrastructure. The spread in practice is likely much wider: well-configured managed WordPress hosts (WP Engine, Kinsta, Flywheel) can achieve sub-500ms response times, while stores on shared hosting with cold PHP processes can see latency well above 3 seconds.

Most agent frameworks have configurable timeouts, typically defaulting between 5 and 10 seconds. A store that responds in 4 seconds most of the time will occasionally spike to 8+ seconds when the PHP process is cold or the server is under load — and those spikes cause agent session failures that look like UCP implementation errors rather than hosting issues. The manifest validates fine, but the store cannot complete a real session reliably.

Specific hosting-related issues we flag frequently: PHP-FPM cold start latency on servers where PHP processes idle between requests (common on lower-tier shared hosting); object cache not configured (WooCommerce makes a large number of database queries per request — without Redis or Memcached, product catalog responses will be slow); and opcode cache absent (WooCommerce's PHP footprint is substantial — OPcache is essential for acceptable performance and is missing on a surprising share of self-managed servers we monitor).

If you are on shared hosting and considering WooCommerce UCP, the performance characteristics alone are likely to produce poor agent experiences. Managed WordPress hosting starts at around $25–35/month and typically delivers 5–10× better MCP response times than budget shared hosting.

Configuration Checklist

Based on our monitoring data, here are the five configuration steps that separate WooCommerce stores that perform well in agent sessions from those that pass a manifest check but fail in production.

First, install and fully configure the WooCommerce UCP plugin. Do not stop at activation — complete the key generation step, review the capabilities configuration, and use the plugin's built-in test to verify the manifest and MCP endpoint are both returning valid responses. Partial configurations are the most common source of manifest issues we see in WooCommerce stores.

Second, whitelist the UCP manifest and MCP endpoint in your caching and security plugins. Add /.well-known/ucp to your caching plugin's exclusion list — agents need the current version on every request, not a cached copy. Add your MCP REST API path to your security plugin's whitelist so it returns JSON, not a block page. This step is specific to WordPress and has no equivalent in managed platform setups.

Third, verify your store at ucpchecker.com/check. Run the check, but specifically look at whether the MCP endpoint is reachable and returning valid responses — not just whether the manifest JSON is well-formed. We check both, and MCP endpoint reachability failure is far more common on WooCommerce than on any other platform we monitor.

Fourth, configure a persistent object cache. WooCommerce's database query load under agent traffic is significant — agents make tool calls in rapid succession, and without Redis or Memcached, each call triggers a full set of database queries. Most managed WordPress hosts include Redis as a one-click option; on self-managed servers, the Redis Object Cache plugin plus a running Redis server is the standard configuration.

Fifth, set up UCP Alerts. Plugin updates, security plugin config changes, and WordPress core updates can all affect your UCP configuration without any explicit notification. We have seen stores where a security plugin update changed the response format on the MCP endpoint and the merchant did not know for days. Alerts catch these changes the next time we check your store.

Plugin Compatibility: The WordPress Ecosystem Challenge

WooCommerce's power comes from its plugin ecosystem — there are over 900 extensions on the WooCommerce Marketplace alone, plus thousands more on WordPress.org and third-party marketplaces. That ecosystem is also the primary source of UCP compatibility issues we see.

The highest-risk category is security and firewall plugins. Wordfence, iThemes Security, Sucuri, and similar plugins use aggressive bot-blocking rules that frequently misclassify AI agent requests. UCP agents typically identify themselves with specific user-agent strings; if your security plugin is configured to block non-browser user agents, it will block agent traffic before it ever reaches your UCP implementation. We see this as a 403 response on the MCP endpoint — the manifest is reachable, but actual agent sessions are blocked.

The second category is caching plugins. WP Super Cache, W3 Total Cache, WP Rocket, and LiteSpeed Cache all have different approaches to caching REST API responses. By default, some of them cache the MCP endpoint — which means agents receive a cached response from a previous session, including potentially stale cart or product data. Your MCP endpoint must return fresh responses on every request, which means explicitly excluding it from caching at both the plugin and server levels.

Third is checkout customization plugins. WooCommerce Checkout Field Editor, WooCommerce One Page Checkout, and similar plugins modify the checkout flow in ways the MCP checkout tool does not know about. A mandatory custom field that requires input before checkout can proceed will silently fail agent checkout attempts — the agent calls the checkout tool, server-side validation rejects it because the custom field is empty, and the response is an error the agent typically cannot resolve.

Fourth, for merchants using multi-currency or multi-language plugins (WPML, WooCommerce Multilingual, Currency Switcher), these add complexity with no equivalent on Shopify Markets. There is no standard way for a WooCommerce store to declare multi-currency support in its UCP manifest, which means agents accessing your store from different geographic contexts may get different pricing without the manifest indicating that variation exists.

Common Failure Modes

Five failure patterns come up repeatedly across our WooCommerce monitoring data.

Caching plugin serving stale MCP responses. An agent requests the tools list and receives a cached response from a previous session — one that might include products now out of stock, prices that have been updated, or a cart session belonging to a different user. This is the most WooCommerce-specific failure mode we see and it is entirely a configuration issue, not a UCP implementation problem. The fix is always the same: explicitly exclude your MCP endpoint path from caching at every level (plugin, server, CDN).

Security plugin blocking agent user agents. The agent makes a request to the MCP endpoint and receives a 403 or a redirect to a CAPTCHA page. From the manifest perspective, everything looks fine. From the agent's perspective, the store is inaccessible. We detect this during our endpoint reachability checks. The fix requires explicitly whitelisting UCP agent user-agent strings in your security plugin's bot management configuration.

PHP memory exhaustion on large catalogs. WooCommerce stores with large catalogs (10,000+ SKUs) frequently hit PHP memory limits when the MCP discovery tool attempts to enumerate products. The default PHP memory limit on many hosts is 256MB — inadequate for large WooCommerce queries under agent access patterns. We see this as timeouts or 500 errors on the discovery tool while other tools work fine. Setting WP_MEMORY_LIMIT to 512M or higher and ensuring your PHP-FPM pool has sufficient memory allocation resolves it in most cases.

Payment gateway plugin conflicts at checkout. WooCommerce's checkout flow is highly extensible — and that extensibility means payment plugins can add hooks that interfere with the MCP checkout tool's assumptions about what happens at payment initiation. We have seen stores where a payment gateway plugin redirects to an external payment page the agent cannot follow, causing the session to terminate after cart completion but before payment. Test your specific gateway configuration explicitly with agent sessions before going live.

Variable product variant ID instability. On WooCommerce, variation IDs can change when products are edited, reimported, or synced from an external system like an ERP or inventory platform. Agents that cache a variation ID for a specific product configuration may find that ID invalid the next time they try to add it to a cart, because the variation was recreated with a new ID. For stores that use bulk product management or external sync tools, this is a persistent issue. SKU-based addressing where possible, and avoiding unnecessary variation recreation, significantly improve agent session reliability.

Product Feed Best Practices for WooCommerce

WooCommerce product data quality is more variable than Shopify's because it is entirely merchant-managed. There is no platform-level enforcement of required fields, no structured data template, and no automatic format normalization. What agents see when they call the discovery tool depends entirely on how well your product catalog is maintained.

Variable products need complete, consistent attribute sets. WooCommerce's variable product model lets you define any attributes you want as variation axes. But it does not enforce completeness. If some variations are missing attribute values — a color variation without a size, or a size variation with no price set — agents may discover the product but fail to add a specific variant to cart. Audit your variable products for incomplete variations before enabling UCP.

Custom fields require explicit plugin support. Many WooCommerce stores use Advanced Custom Fields (ACF), Meta Box, or WooCommerce's own custom product tabs to store additional product data. By default, none of this data is exposed through the MCP discovery tool — the UCP plugin has to explicitly include it in the MCP product response. If your products have custom fields essential for purchasing decisions (technical specifications, compatibility matrices, bulk pricing tiers), verify your UCP plugin is configured to include them in discovery responses.

Set explicit currency on all prices. WooCommerce's default product data model stores prices as raw numbers without currency. The currency is typically declared at the store level, but stores using multi-currency plugins may serve prices in different currencies for different contexts. Ensure your UCP plugin serializes prices with explicit currency codes — not just numeric values — in every product response. Agents guessing currency from context produce wrong price displays.

Stock status must be accurate and real-time. WooCommerce stock management is excellent when configured correctly, but many stores have products set to "In Stock" without managing actual inventory quantities. When an agent discovers a product, adds it to cart, and then hits an out-of-stock error at checkout, the session fails. Enable proper stock quantity management and ensure your stock sync — especially if you use a third-party inventory system — is near-real-time.

SKUs should be present, stable, and unique. WooCommerce SKUs are optional. Many stores, especially smaller ones, do not set them. But SKUs are the most reliable way for agents to reference specific products and variations across sessions — they are more stable than variation IDs and more portable than internal WooCommerce post IDs. Setting SKUs on all products and variations, and keeping them stable across product updates, is one of the highest-leverage improvements for agent session reliability.

Product descriptions should be agent-parseable. WooCommerce product descriptions are free-form HTML — great for human-readable storefront pages, but problematic for agents. The short description field (the excerpt) is typically what MCP discovery tools expose as the primary product description. Keep it clean, text-based, and specific to what an agent needs to understand about the product. Avoid shortcodes, embedded tables, or JavaScript-dependent content in the short description.

Structured data for web-crawling agents. Some agents discover products through web crawling before connecting via MCP. WooCommerce stores using Yoast WooCommerce SEO or Rank Math get reasonable schema.org/Product markup automatically. Verify your storefront product pages include at minimum: name, description, price with currency, availability, brand, SKU, and image. This creates a secondary discovery path for agents that do not connect via MCP directly.

What's Coming

Two developments in the WooCommerce UCP ecosystem are worth watching in 2026.

The first is first-party plugin support from Automattic. The current WooCommerce UCP implementation is third-party. As WooCommerce's UCP install base grows, there is meaningful pressure on Automattic to build UCP support directly into WooCommerce core or develop an official first-party plugin with automatic manifest updates on gateway and catalog changes. A first-party implementation would dramatically reduce the configuration burden and plugin compatibility surface we currently see across our monitoring dataset.

The second is better persistent identity support for logged-in WooCommerce customers. The current MCP authentication model does not leverage WordPress's native user session infrastructure well — most agent sessions are unauthenticated, which means agents cannot access customer-specific pricing, loyalty balances, or saved addresses. As the UCP spec's identity linking capability matures, WooCommerce stores with rich customer profiles stand to gain significantly from authenticated agent sessions that can personalize the shopping experience.

We track WooCommerce adoption trends through our stats dashboard and break down platform-by-platform analysis in the State of Agentic Commerce reports.

Check Your Store

If you are running a WooCommerce store and have not run a UCP check yet, start here. The check takes about 30 seconds and covers both manifest validity and MCP endpoint reachability — the two most common failure points on WordPress-based stores.

If you are already listed in our directory, set up UCP Alerts so you are notified when your configuration changes. A WordPress plugin update, security plugin tweak, or caching config change can silently break your UCP implementation. Alerts catch it before an agent session fails.

And if you want to see exactly how AI agents experience your WooCommerce store — variant resolution, cart building, checkout completion — UCP Playground runs real agent sessions against live stores. It is the fastest way to find the configuration issues that do not show up in manifest validation but break real transactions.

References & Official Resources

AI & Agentic Commerce in WooCommerce — Roadmap Insights — WooCommerce’s official agentic commerce vision
WooCommerce 10.3: MCP Beta Release — First official MCP integration for WooCommerce
Native UCP Support — WooCommerce Feature Request — Community request for built-in UCP
Google: New Tech and Tools for Retailers in an Agentic Shopping Era
UCP Specification — ucp.dev

Related Platform Guides

Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:

The Shopify UCP Guide: What 3,200 Monitored Domains Taught Us About AI Agent Commerce

Benji Fisher — Mon, 30 Mar 2026 21:56:59 +0000

Shopify accounts for the overwhelming majority of UCP adoption. Of the 2,826 verified UCP merchants in our monitoring dataset, 2,812 — over 99.5% — are on Shopify.

That's not a coincidence — Shopify co-developed the Universal Commerce Protocol with Google and shipped native UCP support before most platforms had even published a roadmap. But what surprised us as we grew our monitoring dataset past 3,200 domains was how significant the gap is between "technically passes" and "performs well for AI agents in production."

This guide covers everything we've learned: what Shopify gives you out of the box, what you need to configure, what breaks under real agent traffic, and how to optimize your store for the agentic commerce era.

What Shopify Provides Natively

Shopify's UCP implementation is the most complete we've seen across any platform. When you enable UCP through the Universal Commerce Agent app in the Shopify App Store, the platform automatically generates and serves your /.well-known/ucp manifest without any manual configuration required.

Out of the box, a properly activated Shopify store exposes two stable UCP capabilities to AI agents: Checkout (cart management and purchase completion) and Orders (order status and history). Every verified Shopify store in our dataset exposes both. Catalog browsing is part of the UCP spec but is currently in draft status and not yet widely deployed.

The platform also exposes your store catalog through the Agentic plan, which opens Shopify Catalog as a structured data source for agents that support it. This is separate from the MCP tool layer but increasingly relevant as agent frameworks develop richer product understanding capabilities.

What this means practically: if you install the Universal Commerce Agent app and your store is otherwise functional, you'll likely pass a basic UCP check within minutes. The harder work is everything that comes after.

The Manifest: What We See Across 3,200 Domains

Your UCP manifest is a structured JSON document that tells AI agents what your store supports, how to communicate with it, and what constraints to respect. Shopify generates this automatically, but the contents vary significantly across stores — and the differences matter.

The first thing we look at is the protocol version. The current specification is 2026-01-23, and across our dataset, the vast majority of Shopify stores are already on this version. Shopify's app update mechanism keeps active stores current — though stores that have not updated the Universal Commerce Agent app in many months may occasionally fall behind. Agents implementing strict version negotiation may refuse to interact with outdated manifests.

The second is the capabilities array. A well-configured Shopify manifest should declare at minimum dev.ucp.shopping.checkout and dev.ucp.shopping.order — the two capabilities present on every verified Shopify store in our dataset. Stores that have partially configured their UCP setup sometimes declare fewer capabilities than they actually support, which causes agents to skip features the store is perfectly capable of handling.

Third is the payment handlers section, which reflects your actual payment stack. Shopify populates this automatically based on your enabled payment providers, but it can become stale if you add or remove payment methods without a full UCP re-sync. We see this most often on stores that recently switched from Shopify Payments to a third-party provider, or vice versa.

Finally, the transports declaration. Shopify stores declare MCP as the primary transport, which is correct. Problems arise when stores have custom middleware or proxy configurations that intercept requests before they reach the MCP handler — the manifest says MCP is available but the actual endpoint doesn't behave as expected.

Common Manifest Issues We Flag

Across our monitoring dataset, the most frequently flagged issues are: missing signing keys (stores that enabled UCP before key rotation was standard and haven't re-synced), currency not declared on stores using Shopify Markets (agents trying to price-compare across sessions can get inconsistent results), and stale capabilities after payment provider changes (the manifest still lists a payment method that's no longer active).

None of these will cause a hard failure on a basic UCP check — the manifest is technically valid. But they create subtle errors in production agent sessions that are difficult to diagnose without a monitor that tracks changes over time.

Runtime Performance: What Agents Actually Experience

A manifest check tells you whether your store is configured correctly. What it can't tell you is how your store actually performs when an agent runs a real session — product discovery, cart building, variant resolution, checkout completion.

Across our benchmark dataset, Shopify stores show response times between 102ms and 1,316ms for MCP tool calls, with a median of 146ms and a p95 of 205ms — fast enough for virtually any agent workflow. The rare outliers above 500ms are almost always explained by one of three things: geographic distance from the nearest Shopify edge node, heavy app stack adding middleware latency, or Shopify Markets adding an additional 200–400ms for cross-region requests.

Tool availability is generally excellent on Shopify. When we run tools/list against a properly configured store, we consistently see both core tools available. Compare that to custom UCP implementations on other platforms, where tool availability is frequently incomplete or inconsistently declared.

Checkout completion rates are the highest we see on any platform — but they drop meaningfully on stores that have mandatory custom fields on the checkout page. Agents can handle standard Shopify checkout flows natively, but custom fields that require JavaScript interaction or are injected by third-party apps often break the automated flow. If your store has a mandatory gift message field or a custom loyalty ID input, test it explicitly with agent sessions.

In our 180-session benchmark, we ran sessions against Shopify stores using multiple agent models. Variant resolution was the most variable capability — the Llama 3.3 70B variant had notably lower success rates on stores with complex product option configurations (more than 3 option dimensions, or options that affect availability rather than just presentation).

Configuration Checklist

Based on our monitoring data, here are the five steps that separate stores that perform well in agent sessions from stores that pass the basic check but struggle in production.

First, enable UCP properly. Install the Universal Commerce Agent app from the Shopify App Store and complete the full setup flow, including the key generation step. Partial installations are the single most common source of manifest issues we see.

Second, verify your manifest at ucpchecker.com/check. Run the check, review the capabilities and payment sections specifically, and confirm the protocol version matches the current specification. If you're on an older version, an app update is usually all it takes to fix it.

Third, review your robots.txt and bot access configuration. Shopify's default robots.txt allows UCP agent traffic, but custom modifications can block it. If you've used a third-party SEO app to customize your robots.txt, verify it isn't inadvertently blocking the user agents that UCP-compliant AI clients use.

Fourth, test with multiple agent models. Don't assume that passing validation means all agents can complete transactions. Run sessions with at least two different agent implementations and specifically test variant-heavy products. Variant resolution failure is the most common production issue we see on otherwise well-configured stores.

Fifth, set up UCP Alerts. Your manifest can change silently — app updates, payment provider changes, and Shopify platform changes can all alter what your manifest declares. Alerts notify you when we detect a change in your manifest so you can investigate before agents encounter the problem.

Shopify Markets and Multi-Region Considerations

Shopify Markets is the platform's native multi-currency, multi-region selling feature. It's excellent for human shoppers and increasingly common on the stores we monitor. It also introduces UCP-specific complexity that many merchants don't account for.

The proxy layer that Markets uses to serve region-appropriate content adds 200–400ms of latency to MCP tool calls. For most agent workflows, this is acceptable. For agents running product discovery across dozens of stores in a single session, it compounds.

More importantly, your manifest can vary by geographic context when Markets is active. An agent accessing your store from a US IP may see a different payment handlers section than one accessing from the EU, because your available payment methods differ by region. This isn't inherently wrong — it's expected behavior — but it means agents can't cache your manifest reliably across sessions from different origins.

If you're using Markets, declare your primary currency explicitly in your UCP configuration even if Shopify auto-detects it. And ensure your store correctly handles the country parameter in product and checkout requests — agents that pass explicit country context should get deterministic pricing, not a redirect to a region-detection flow.

Common Failure Modes

Four failure patterns come up repeatedly in our monitoring data, and they're all worth knowing before you go into production.

App conflicts causing cart total mismatches. Some Shopify apps modify cart calculations through hooks that don't propagate correctly to the MCP checkout tool. The most common manifestation: an agent successfully adds items to a cart and receives a subtotal, but when it initiates checkout, the total has changed because a discount or surcharge app modified it after the initial cart response. Agents that validate cart totals before confirming checkout will abort the transaction.

Variant complexity exceeding agent resolution capability. Products with more than three option dimensions, or options that combine to affect availability (a size that's only available in certain colors), frequently cause agents to fail at variant selection. The MCP tool returns the product correctly, but the agent can't determine which variant ID to use without rendering the full option matrix. Simplifying your product option structure — or providing explicit variant recommendations for your most common configurations — significantly improves agent success rates.

Draft products appearing in MCP responses. Shopify's catalog API and the MCP Discovery tool don't always apply the same product visibility filters. We've seen stores where draft products (not published to the storefront) appear in MCP product listings. Agents attempting to add these to a cart receive an error. Audit your product visibility settings if you maintain a large draft catalog.

Redirect loops for agents without location headers. Some stores have geographic redirect logic that sends visitors without a detected location to a region-selection page. Agents that don't send standard location headers get caught in this loop — they follow the redirect, hit the same logic again, and either fail or get stuck. If you use geographic redirects, configure them to pass through to the default storefront for requests that carry a UCP agent identifier.

Product feed best practices

When Shopify generates your UCP manifest and exposes your catalog through MCP tools, the quality of what agents see depends entirely on your product data. A clean manifest with dirty product data is worse than no UCP at all — agents will discover your store, attempt to shop, and fail.

Here's what matters for agent-readable product feeds:

Titles must be variant-specific. An agent searching for "blue cotton t-shirt size L" needs to match against a title that contains those attributes. If your product title is just "Classic Tee" with variants buried in option fields, agents have to make extra calls to resolve what they're looking at. Stores with descriptive, variant-aware titles see higher search-to-cart conversion in our agent sessions.

Set priceCurrency on every offer. This is the single most common data quality issue we flag. Without explicit currency declarations, agents may display wrong currency symbols or attempt incorrect conversions. On multi-market Shopify stores, the product price changes by region — but if the feed doesn't declare which currency applies, the agent is guessing. Always set priceCurrency in your product structured data.

Images must have descriptive alt text. Agents that support multimodal input use alt text to understand product images. "IMG_4521.jpg" tells an agent nothing. "Navy blue merino wool crew neck sweater — front view" tells it everything. This is standard accessibility practice that doubles as agent optimization.

Keep variant data clean and consistent. If your store has products with multiple option axes (color × size × material), each variant needs a unique, resolvable ID. We've seen stores where variant IDs change after inventory syncs, breaking any agent that cached a previous variant reference. Stable variant IDs are essential for reliable add-to-cart flows.

Don't expose draft or out-of-stock products. Your MCP-facing catalog should match your public storefront. If an agent finds a product through search, adds it to cart, and then gets an "unavailable" error at checkout, that's a failed session. Check that your product visibility settings apply consistently to both the storefront and the MCP server. In our monitoring, we've flagged stores where the MCP endpoint returns 10-15% more products than the public catalog — those are ghost products that agents can discover but buyers can't purchase.

Structured data matters beyond the manifest. Shopify merchants using Schema.org Product markup on their storefront pages help agents that discover products through web crawling (not just MCP). The markup should include: product name, description, price with currency, availability status, brand, SKU, and image URLs. This creates a second discovery path for agents that crawl the web before connecting via MCP.

Update frequency. Stale feeds cause stale agent experiences. If you run flash sales, seasonal pricing, or frequent inventory changes, your product feed needs to reflect those changes in near-real-time. Shopify's native UCP integration handles most of this automatically, but custom feeds or third-party sync tools can introduce lag. Our daily monitoring catches when a manifest's product data drifts from what's actually available on the storefront.

What's Coming

Two capabilities currently in draft status will be significant for Shopify merchants when they ship: Cart as a persistent, shareable construct (enabling agents to hand off a pre-filled cart to a human for completion), and Catalog as a richer product data access layer (giving agents structured access to inventory, pricing tiers, and product relationships without relying on search).

Shopify's existing OAuth infrastructure puts it in a strong position for identity linking — the ability for agents to authenticate as a known customer and access loyalty points, saved addresses, and purchase history. This is the capability most likely to drive meaningful conversion improvements for returning customers.

We track adoption of emerging capabilities through our stats dashboard and publish deeper analysis in the State of Agentic Commerce reports. If you want to understand where the ecosystem is heading, those are the places to watch.

Check Your Store

If you're running a Shopify store and haven't run a UCP check yet, start there. The check takes about 30 seconds and will tell you whether your manifest is correctly configured and up to date.

If you're already in our directory, set up UCP Alerts so you're notified when your manifest changes. Silent regressions — the kind that only show up when an agent fails to complete a transaction — are the hardest to catch without monitoring.

And if you want to see how AI agents actually experience your store, UCP Playground lets you run real agent sessions against live stores. It's the fastest way to find the variant resolution and checkout completion issues that don't show up in manifest validation.

References & Official Resources

Shopify: The Agentic Commerce Platform — Shopify’s announcement connecting merchants to every AI conversation
Building the Universal Commerce Protocol — Shopify Engineering — Technical deep-dive into how UCP was built
Introducing Shopify Agentic Storefronts — Sell products everywhere AI conversations happen
Google: New Tech and Tools for Retailers in an Agentic Shopping Era
Under the Hood: Universal Commerce Protocol — Google Developers Blog
UCP Specification — ucp.dev

Related Platform Guides

Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:

We Built OAuth Identity Linking Into Our AI Agent Commerce Playground — Here's How the Protocol Actually Works

Benji Fisher — Sat, 21 Mar 2026 13:12:59 +0000

In our last post, we ran 180 AI agent shopping sessions across 11 models and 20 live stores. Every single session was anonymous. The agent connected, searched the catalog, built a cart, reached checkout — and the merchant had no idea who the buyer was.

That's fine for product discovery. It's a dead end for real commerce.

Without identity, there's no loyalty pricing. No saved addresses. No order history. No way to say "ship it to the same place as last time." The agent collects buyer info from scratch every session — name, email, phone, shipping address — adding 4-5 messages before checkout can even start. In our 180-session dataset, that friction was consistent across every model and every store.

So we built identity linking into UCP Playground.

What changed in the spec

On March 18, a breaking change landed in the UCP repository: feat!: redesign identity linking with mechanism registry and capability-driven scopes. Identity linking — dev.ucp.common.identity_linking — is now one of four core capabilities in the UCP spec, alongside Checkout, Order, and Payment Token Exchange.

Two concepts from this redesign matter for anyone building against UCP:

Mechanism registry. Merchants declare which authentication mechanisms they support in a structured registry within their UCP manifest. The registry pattern supports multiple mechanisms and can evolve without breaking existing implementations.

Capability-driven scopes. OAuth scopes are no longer static. A merchant might require one set of scopes for catalog access and a different set for checkout. The agent negotiates what it needs based on the capabilities it wants to use. An agent that only browses the catalog doesn't get checkout permissions. Least-privilege, applied to commerce.

What we built

We implemented the full OAuth 2.0 Authorization Code flow with PKCE in UCP Playground. Here's what the architecture looks like:

UCP Identity Linking — OAuth 2.0 PKCE Flow
Five steps, three actors. The agent never sees user credentials. The human stays in the loop at the consent step. Here's how each piece works in practice:

1. Discovery

When you point the playground at a merchant domain, we read the UCP manifest. If it declares dev.ucp.common.identity_linking and includes OAuth endpoints — authorization URL, token URL, and optionally a client registration URL — we light up the identity flow.

This is the same manifest we're already parsing for checkout and catalog capabilities. Identity linking is just another capability declaration, which means the discovery infrastructure we built for our 2,000-manifest monitoring works here too.

2. Dynamic client registration (RFC 7591)

This was the first surprise. The spec supports RFC 7591 dynamic client registration. Instead of manually registering an OAuth app at every merchant — which doesn't scale when you're testing against 20+ stores — the agent sends a registration request and gets client credentials back automatically.

In our IdentityLinkingService, this is a single POST:

$response = Http::post($registrationUrl, [
    'client_name' => 'UCP Playground',
    'redirect_uris' => [$callbackUrl],
    'grant_types' => ['authorization_code'],
    'response_types' => ['code'],
    'token_endpoint_auth_method' => 'none', // public client
]);

We cache the registration per merchant so subsequent sessions reuse the same client credentials. No developer portal visits. No API key management. The protocol handles it.

3. PKCE authorization

PKCE (Proof Key for Code Exchange) prevents authorization code interception. We generate a random code verifier, hash it to create a challenge, and send the challenge with the authorization request. When we exchange the code for tokens later, we prove we're the same client by presenting the original verifier.

$verifier = Str::random(128);
$challenge = rtrim(strtr(
    base64_encode(hash('sha256', $verifier, true)),
    '+/', '-_'
), '=');

The user sees the merchant's consent screen — what permissions are being requested, what data will be shared. The agent can't bypass this. This is the critical trust boundary: the human explicitly approves what the agent can do on their behalf.

4. Token exchange

After consent, the merchant redirects back with an authorization code. We exchange it server-side with the PKCE verifier to prove the code belongs to us. Back comes an access token and a refresh token.

We built an OAuthTokenManager that handles refresh automatically. When a token expires mid-session, the manager swaps it transparently so the agent flow doesn't break. In practice, this means a user can link their identity once and the agent maintains the connection across multiple interactions.

5. Profile resolution

With a valid token, we call the merchant's profile endpoint. Back comes the buyer's identity — name, email, phone, shipping address. This is what flows into checkout instead of the manual 4-5 message collection.

One thing we learned building this: profile response formats vary across merchants. Some return flat JSON, some nest address fields, some use different key names for the same data. Our IdentityLinkingService normalizes across formats so the agent always gets a consistent buyer profile regardless of the merchant's implementation.

What we learned

Building this end-to-end surfaced a few things that aren't obvious from reading the spec:

Dynamic client registration is the unlock. Without RFC 7591, every platform building agent commerce would need to manually register OAuth apps at every merchant. That's the same integration bottleneck UCP was designed to eliminate. Dynamic registration makes the whole flow self-bootstrapping.

PKCE is non-negotiable. The spec requires it, and rightly so. Agents are effectively public clients — they can't securely store a client secret. PKCE ensures the authorization code can only be exchanged by the client that initiated the flow. Standard security practice, but it's good to see it baked into the spec rather than left as optional.

Capability-driven scopes add real complexity. Static scopes are straightforward — you request a list and you're done. Capability-driven scopes mean the agent needs to understand what capabilities it wants to use before requesting authorization. We built scope negotiation into the authorization step, but this is an area where fragmentation could emerge as different merchants define different scope mappings.

Profile normalization is unglamorous but essential. Every merchant returns buyer data slightly differently. If you don't normalize at the protocol layer, every agent has to handle format differences. We centralized this in one service, but the spec could benefit from stricter response format requirements.

The impact on agent sessions

Here's the practical difference. In our anonymous shopping sessions, the checkout flow looked like this:

Agent: I'd like to check out. What information do you need?
[Merchant requests: email, name, shipping address, phone]
Agent: What's your email?
User: user@example.com
Agent: Shipping address?
User: 123 Main St...
Agent: Phone number?
...

Four to five back-and-forth messages before the cart even moves toward payment. With identity linking:

Agent: [resolves buyer profile via OAuth token]
Agent: Ready to check out with your saved details. Proceed?
User: Yes.

Zero friction. The agent already knows who you are and where to ship. It's the difference between an agent shopping for you and an agent shopping as you.

Where adoption stands

We monitor 3,000+ domains through UCP Checker. Identity linking is starting to appear in merchant manifests, but most implementations are still at the declaration stage — merchants list the capability without fully wiring up the OAuth flow behind it.

In our audit system, identity linking earns 2 points in the manifest capability score. If a merchant declares it but their runtime tools don't support buyer identity fields, we flag it as a gap. We're scoring declaration today; runtime probing of OAuth endpoints is on our roadmap.

The infrastructure is ready on the platform side. We're waiting for merchants to plug in.

What to watch

Merchant adoption. Platforms like Shopify already run extensive OAuth infrastructure for their app ecosystem. Extending it to UCP identity linking is a natural step. Custom platform developers building against the spec will likely move faster.

Scope standardization. The capability-driven scopes model is powerful but new. As more merchants implement it, patterns will emerge. Early standardization prevents fragmentation.

The mechanism registry evolving. OAuth 2.0 is the starting point, but the registry is designed for more. Passkeys, verifiable credentials, federated identity — the architecture is there.

Check your domain: ucpchecker.com/check
Test the full flow: ucpplayground.com
Read the spec: github.com/Universal-Commerce-Protocol/ucp
Follow the data: ucpchecker.com/blog

We Built a Chrome Extension That Discovered 1,480 Agent-Ready Stores. Here's Exactly How It Works.

Benji Fisher — Tue, 10 Mar 2026 15:25:50 +0000

Wappalyzer didn't become a 3-million-user tool by being clever. It became essential by answering one question passively: what is this site built with?

We built something similar for a different question: is this store agent-ready?

The UCP Checker Chrome extension probes /.well-known/ucp on every storefront you visit and shows you the result in your toolbar. Green dot = valid UCP manifest. Gray dot = not detected. Zero clicks required.

Six weeks after shipping it, the extension has fed 1,480 unique domains into our monitoring pool — making it our single largest discovery source, ahead of our crawler, web submissions, and bulk checks combined. With a 98.4% verified rate — meaning almost every store it finds has a live, valid manifest.

This post is the full technical breakdown: how the detection works, what the permission model looks like compared to other ecommerce extensions, what the extension discovered, and what we're building next.

If you read our first post on running 180 agent shopping sessions across 11 models, this is the prequel — the detection layer that feeds the stores into the system those agents shop on.

The architecture: four components, one HTTP request

Compare this to how Wappalyzer works: it injects content scripts into every page, reads meta tags, checks JavaScript globals, and matches against a database of 1,000+ technology fingerprints. Or Shopify Theme Inspector, which hooks into Chrome DevTools, intercepts the Server-Timing header, and renders Liquid flame graphs.

UCP Checker does none of that. The entire detection mechanism is a single HTTP request.

1. Navigation listener

javascript// webNavigation.onCompleted fires on new domain
// No content scripts. No DOM injection. No page content access.
// Only completed navigations — not iframes, AJAX, or redirects.
chrome.webNavigation.onCompleted.addListener(handleNavigation);

2. Manifest probe

javascript// One fetch() per domain visit. That's it.
const response = await fetch(
  `https://${domain}/.well-known/ucp`,
  { credentials: "omit" }  // No cookies, no session tokens, no auth headers
);
// Parse: HTTP status, response time, manifest structure

This is architecturally closer to how a browser checks /.well-known/security.txt or /.well-known/openid-configuration than how Wappalyzer fingerprints a stack. No heuristic matching, no DOM analysis, no pattern library to maintain. Either the endpoint exists and returns a valid manifest, or it doesn't.

3. Badge system

Green dot  → valid UCP manifest found (store is agent-ready)
Gray dot   → no manifest detected (404/redirect)
No change  → error states (timeouts, network failures — stay silent)

4. Optional telemetry

A toggle — on by default — labelled "Share anonymous uptime stats." When enabled, the extension sends the public manifest data to our monitoring pool:

json{
  "domain": "example-store.com",
  "status": "verified",
  "http_status": 200,
  "response_time_ms": 142,
  "manifest_version": "2026-01-23",
  "transports": ["mcp", "embedded"],
  "timestamp": "2026-03-02T14:23:01Z"
}

No user ID. No session ID. No IP forwarding. No referrer. The credentials: "omit"flag ensures no cookies leave the browser. The domain enters the monitoring pool. The connection to the individual browse event is not retained.
That's the entire technical surface. Four components, one HTTP request per domain, zero page content access.

The permission model: why it's the narrowest in the category

This is where it gets interesting for anyone who's built or evaluated Chrome extensions.

Wappalyzer requires <all_urls> and content script injection — broad access in exchange for broad detection. Koala Inspector (250K+ users, Shopify competitive intelligence) needs similar DOM access to extract product data and sales estimates. Shopify Theme Inspector hooks into the network layer to read server timing headers.

Here's ours:

json{
  "permissions": ["activeTab", "webNavigation", "storage"],
  "host_permissions": ["https://*/.well-known/ucp*"]
}

That's it.

Permission breakdown:
──────────────────────────────────────────────────────────────────
activeTab        → read current tab's URL (domain only)
                   Most restrictive tab permission Chrome offers
webNavigation    → detect domain navigations for auto-probe
storage          → save badge state locally (no cloud sync)
host_permissions → ONLY https://*/.well-known/ucp*
                   Cannot access any other path on any domain
──────────────────────────────────────────────────────────────────

What we DON'T request:
──────────────────────────────────────────────────────────────────
tabs             → would give access to all tab URLs
cookies          → would give access to session data
history          → would give access to browsing history
<all_urls>       → would give access to every page
content scripts  → would give access to page DOM
──────────────────────────────────────────────────────────────────

The extension literally cannot read what's on the page you're viewing. It can only check whether a specific well-known URL exists. Auditable in Chrome's extension management page in seconds.

Manifest V3 and why it matters

The extension ships on Manifest V3 — Chrome's current platform with a stricter security model than V2. Service workers replace persistent background pages, host_permissions are declared explicitly, and CSP blocks inline script execution.

This matters because the December 2024 Chrome extension supply chain attack — which compromised extensions affecting 2.6 million users — exploited V2-era permission patterns that V3 structurally prevents. Our V3 architecture, combined with path-scoped host permissions, means even a compromised build couldn't read page content or access arbitrary URLs. The worst case is a bad probe to/.well-known/ucp — a public endpoint that returns public data.

What the extension discovered

Here's where the modest debugging tool turned into something bigger.

Discovery source        Domains    % of pool    Verified rate
─────────────────────────────────────────────────────────────
Browser extension         1,480      73.7%          98.4%
Crawler                     407      20.3%          87.2%
Web submissions             120       6.0%          64.2%
Bulk check                    1       0.0%            —
─────────────────────────────────────────────────────────────
Total                     2,008     100.0%          83.1%

*98.4% verified *— nearly every store the extension finds has a live UCP manifest. Compare that to web submissions (64.2%), where people are testing domains that don't have UCP yet. The extension finds real merchants because it only fires on storefronts people are actually visiting.

The profile is distinctive: niche DTC brands that don't appear in any Shopify directory. Regional retailers in markets our crawler doesn't cover — Southeast Asia, Scandinavia, South America. The extension's geographic reach follows wherever our users browse.

This is the pattern Wappalyzer pioneered — crowdsourced technology detection at scale. But where Wappalyzer's telemetry feeds a commercial intelligence database (API pricing starts at $250/month for 5,000 lookups), ours feeds a public monitoring pool. The domain data powers our free benchmarks at UCP Checker, the UCP Alerts system, and the weekly adoption stats newsletter.

The extension users are building the map. And the map is open.

Privacy architecture

Extension-discovered domains are attributed only as "browser extension" in our data. We don't track which user discovered which domain, we don't store browsing sessions, and we don't build user profiles.

This is a fundamentally different approach to extension telemetry than the competitive intelligence tools. Koala Inspector and Commerce Inspector are designed to extract data from stores you visit — product listings, pricing, sales estimates. Our extension extracts nothing from the store's page. It checks a single public endpoint and reports the result.

The Hacker News thread: static vs. runtime

When we posted the extension to HN, the most substantive feedback wasn't about the extension itself. It was about what happens after validation.

The argument: a static manifest check tells you the endpoint exists and conforms to the spec. But it doesn't tell you what happens when an agent actually fetches content. A valid manifest can serve tool responses containing prompt injection, credential exfiltration patterns, or behavioural steering in product descriptions.

The commenter framed it as pairing manifest validation with runtime guardrails — classify and strip instructions in fetched content, detect exfiltration patterns, enforce policies before tool responses reach the LLM.

The timing was interesting. When we read that feedback, we were already building UCP Playground — which does exactly this from the observation side. Playground connects to a store's MCP server, runs live agent sessions, and shows you every JSON-RPC message flowing between the agent and the store.

The HN feedback didn't change our direction. It confirmed we were on the right track.

But it sharpened a distinction:

Static layer (UCP Checker + extension)
────────────────────────────────────────────────────────
Schema validation, capability declarations,
reachability, access policies.
Question: "Is this a valid, accessible UCP endpoint?"

Runtime layer (Playground — observes, doesn't enforce)
────────────────────────────────────────────────────────
Tool response content, instruction injection patterns,
checkout flow completeness, schema quality per tool.
Question: "What happens when an agent shops here?"

The open question: should the runtime layer move from observation to enforcement? And who owns that — merchants sanitising their MCP responses, model providers extending safety layers to tool responses, or the UCP spec itself defining content security policies like CSP headers in browsers?

We think observability comes first (Playground), enforcement will follow as the ecosystem matures.

What we're building next

The extension currently does one thing. Here's what's on the table — and we'd genuinely like feedback on which of these matter to you.

Local discovery history

Your personal log of every domain you've visited and its UCP status — stored entirely in storage.local, never transmitted. A personal UCP audit trail. Browse stores all week, review which ones are agent-ready. No new permissions, no API calls.

Richer popup with grading

We already grade tool schemas A through F in UCP Playground. Surfacing that grade in the extension popup:

┌─────────────────────────────────────┐
│  ● allbirds.com          VERIFIED   │
│                                     │
│  Grade: B+    Response: 142ms       │
│  Transports: MCP, Embedded          │
│  Bot access: All allowed            │
│                                     │
│  [Open in Playground]  [Run Audit]  │
└─────────────────────────────────────┘

One glance: green dot, B+ grade, 142ms, MCP + Embedded. Useful density for an agency evaluating agent readiness. Trade-off: additional API call per domain.

One-click Playground link

Visit allbirds.com → see green dot → click "Open in Playground" → watching Claude shop for running shoes. The detection-to-testing flow should be one click.

One-click alert setup

"I noticed this store has UCP" → "I want to know if it breaks" should be seamless. Deep-link from the popup to the alerts page with the domain pre-filled. Requires a logged-in account on ucpchecker.com — the extension just handles the link.

Quick audit run

A one-click "audit this domain" — the full scoring pipeline: schema quality, capability coverage, response times, bot access. Think of it as Lighthouse for UCP: right-click, audit, see the score.

What we're deliberately not building

DOM inspection or content analysis. Would require content script injection and broader permissions — a fundamentally different trust model. The extension stays manifest-only.

Automated testing or agent execution. That's what Playground is for. The extension detects. Playground tests.

Where the extension fits

Detection          Analysis            Testing             Monitoring
─────────          ────────            ───────             ──────────
Extension    →     UCP Checker    →    Playground     →    Alerts
"Is it ready?"     "How ready?"        "Does it work?"     "Did it change?"

The extension sits at the top of the funnel — the lightest-touch interaction. A passive signal in your toolbar.

Compare to how Wappalyzer evolved: the extension was the entry point, but the value migrated to the API and intelligence platform. The extension stayed free and lightweight; the business built on the data it generated. Same pattern here — the extension generates discovery data, the platform turns it into developer tools.

1,480 domains later, the community is building the map by browsing.

What I'd love to hear

We're at a decision point with the extension. It's stable, lightweight, and trusted. The question is what to add — and what to leave out.

What would make you open the extension popup more often? A grade? Response time? Transport info?
Quick audit from the toolbar — would you use it, or just go to ucpchecker.com?
Runtime enforcement: who should own it? Merchant-side gateway, agent-provider responsibility, or protocol-level spec?
The permission model — does the narrow scope matter to you when evaluating extensions?

Drop a comment below or reach out at ucpchecker.com/contact. I read everything.

Try it:

Install the extension — free, no account, Manifest V3
UCP Checker — full domain analysis and benchmarking
UCP Playground — watch agents shop in real time
UCP Alerts — get notified when manifests change

We Monitored 2,000 UCP Manifests Every Day for a Month. Here's What Breaks

Benji Fisher — Tue, 03 Mar 2026 15:33:08 +0000

In our last post, we ran 180 AI agent shopping sessions and showed what happens when models actually try to buy things. That data told us which models reach checkout and which fall off the funnel.

But it left a bigger question unanswered: what about the stores themselves?

A session failing because Claude guessed a variant ID wrong is a model problem. A session failing because the store's manifest disappeared overnight is an infrastructure problem. And you can't tell the difference from a single scan.

So ten days after UCP launched on January 11th, we started monitoring. Not a one-time crawl — a continuous, automated check of every domain in our pool, every 24 hours. A month later, our crawler has run over 24,000 checks across 2,008 domains.

Here's what the data shows.

The monitoring pool

Our crawler tracks 2,008 domains, discovered through four channels:

Browser extension: 1,480 domains — our Chrome extension probes /.well-known/ucp on every storefront visited and feeds new domains into the pool automatically. 98.4% verified rate — the stores it finds are overwhelmingly real merchants with live manifests.
Crawler: 407 domains — a proprietary engine that continuously discovers new UCP-enabled stores.
Web: 120 domains — manual checks submitted through ucpchecker.com by developers and store owners testing their implementations.
Bulk check: 1 unique domain — batch submissions, mostly domains we're already tracking.

No single source covers the full picture. The crawler finds known stores systematically. The extension picks up storefronts that don't appear in any directory — niche brands, regional retailers, development endpoints. Together they give broader coverage than any one approach alone.

As of February 27th:

83% of domains have a working UCP manifest. That's a strong baseline — but the interesting story is in the other 17%, and in what happens to manifests that were verified yesterday.

Manifests break. More often than you'd think.

Over the monitoring period, we detected 457 status changes across the pool. 95 of those were breakages: a domain that was verified on one check came back invalid, unreachable, or blocked on the next.
The breakdown:

68 verified → invalid — manifest still exists but fails validation. Most common failure mode. A deployment pushes bad JSON, a field goes missing, or a version string gets malformed.
14 verified → unreachable — endpoint times out entirely. Infrastructure issue, DNS change, or CDN misconfiguration.
7 verified → blocked — domain starts rejecting the crawler. Usually a WAF rule change.
6 verified → not detected — manifest disappears. Endpoint returns 404 or redirects.

88 unique domains experienced at least one breakage during the month. That's roughly 5% of verified stores going down at some point — and then, in many cases, coming back.

The recovery cycle

The good news: most breakages are temporary.

We observed 96 recoveries — domains that were broken or missing and then came back:

69 invalid → verified (bad deployment rolled back)
13 unreachable → verified (infrastructure recovers)
10 not detected → verified (new manifest published)
4 blocked → verified (bot rules relaxed)

This creates a pattern we're calling the "manifest recovery cycle." A store's UCP endpoint breaks — usually through an invalid manifest — and typically recovers within 24–48 hours.

A caveat: we're running a 24-hour crawl cycle, so actual recovery time could be shorter. A store that breaks and fixes within a few hours between checks wouldn't show up as a transition at all — meaning the true breakage rate is likely higher than what we're reporting.

The implication for agent developers: just because a store worked yesterday doesn't mean it works today. And just because it's broken now doesn't mean it's gone.

The flappers

32 domains showed signs of persistent instability — oscillating between working and broken states multiple times over the month. We're calling these "flappers."

The most unstable endpoint flipped status 22 times in a month. Others in the top 10 include major retailers and well-known tech companies — names you'd expect to have stable infrastructure. Some are running custom UCP implementations outside Shopify, which may explain the instability. Others appear to be testing or iterating in production.

Flapping is a signal. It tells you the endpoint exists and someone is actively working on it — but it's not yet reliable enough for an agent to depend on.

For agent developers building production flows against specific stores, flapping domains need a different strategy: retry logic, fallback handling, or simply waiting until the implementation stabilises.

Who's blocking agents — and the paradox

95 domains are actively blocking our crawler:

Firewall blocks (1,179 check instances) — the domain's WAF rejects the request before it reaches the UCP endpoint. This includes major retailers like Kohl's, Macy's, Sears, REI, Neiman Marcus, and Tiffany.
Robots.txt blocks (108 instances) — explicit crawler disallowance.

Here's the paradox we flagged in our first audit and it persists: some of these blocked domains have fully deployed UCP manifests. They've built the infrastructure for agentic commerce and then locked the front door.

This is almost certainly an operational gap — the security team updating firewall rules without coordinating with the product team that shipped UCP. But for agents, the result is a hard bounce.

Robots.txt: the access picture

Among verified domains, we check robots.txt for six major AI bot user agents. The picture is overwhelmingly permissive:

18 verified domains block at least one AI bot while maintaining a live UCP manifest. The pattern splits into two groups: stores that block everything and stores that selectively block one or two.

The selective blockers are the more interesting case — a store that blocks GPTBot but allows ClaudeBot is making a deliberate choice about which agents can discover them. Some stores appear to be conflating AI training crawlers with AI shopping agents in their robots.txt rules.

The broader signal: stores that have committed to UCP have also committed to being discoverable by agents. The 1% that block specific bots are edge cases.

Response times: fast, but with a long tail

Across 19,035 verified checks:

130ms median is fast — well within what real-time agent interactions need. But that tail matters. 1.5% of verified checks returned in over 500ms.

For agents making multiple tool calls per session — search, details, cart, checkout — a slow manifest compounds. A 130ms response adds barely any latency. A 750ms response hit three or four times adds 2–3 seconds of dead time the user feels.

If you read our Playground data, you know the difference between a 5-second session and an 11-minute one can come down to infrastructure like this.

Transports: MCP dominates, REST is where it gets interesting

UCP is transport-agnostic by design. Across 1,669 verified domains:

MCP: 99.9% (1,668 domains) — the default Shopify transport. JSON-RPC, tool discovery via schema introspection, real-time tool calls.
Embedded: 99.8% (1,665 domains) — declared alongside MCP on nearly every Shopify store. Designed to solve the payment wall: agent builds the cart, merchant's checkout UI handles payment in a secure iframe.
REST: 0.5% (8 domains) — found exclusively on non-Shopify implementations: WooCommerce via UCPReady, custom builds, development endpoints.
A2A: 1 domain — Google's Agent-to-Agent protocol. The first A2A declaration we've seen in a UCP manifest in the wild.

The dominant combo is ["mcp", "embedded"] — what Shopify ships by default. But those 8 REST-declaring stores are where the transport diversity lives. These include WooCommerce implementations that expose REST alongside MCP and Embedded — giving agents three paths to the same store.

In our 180-session deep dive, we showed the schema fragmentation across these stacks — same "add to cart" intent, three completely different tool signatures. The transport data here shows why: 99.9% of stores speak one dialect (Shopify MCP), and the remaining 0.1% is where all the interoperability challenges live.

For agent developers: an agent that only speaks MCP reaches 99.9% of the current ecosystem. But as non-Shopify platforms ship UCP with REST-first architectures, that percentage will shift. The agents that handle multiple transports will have the widest reach.

The benchmark picture

We've benchmarked 1,183 domains on our scoring system:

The A-grade stores — Allbirds, Emma Bridgewater, Bodybuilding.com, and six others — represent the current ceiling. 188ms average TTFB, total scores of 90+, full capability coverage. In our Playground testing, Allbirds was also a standout: one store, five models, 100% checkout rate, zero errors.

The F-grades are almost entirely non-Shopify domains (285 of 289). Most don't have a manifest at all — domains submitted for checking that haven't deployed UCP.

The capability gap that matters most

Among 741 stores with verified manifests and benchmarked capabilities, coverage is near-universal: search, cart, product details, policies, shipping, discounts — all at 100%.

But OAuth: effectively 0%.

Without OAuth, every agent interaction is anonymous. No saved addresses, no order history, no loyalty discounts. The spec acknowledges it. The ecosystem hasn't addressed it yet.

The interesting divergence comes from non-Shopify implementations — WooCommerce stores exposing dev.ucp.shopping.checkout and dev.ucp.shopping.fulfillment capabilities that Shopify stores don't declare. As the ecosystem diversifies beyond Shopify, capability coverage becomes a real differentiator.

What this means if you're building on UCP

If you're building agents: manifests are not static. They break, recover, and flap. Your agent framework needs retry logic, health checking, and fallback handling. Don't cache manifest state for more than a few hours.

If you're running an MCP server: the reliability gap between Shopify and everyone else is significant. Shopify stores are consistently stable. Non-Shopify implementations are where the instability lives — and where the most interesting development is happening. If you're in the second group, monitoring your own endpoint is table stakes.

If you're a store owner: check whether your security team knows about UCP. The stores blocking AI crawlers aren't rejecting agentic commerce — they're running standard bot protection that wasn't updated when UCP went live. A WAF rule change could be the difference between your store being agent-shoppable and invisible.

If you care about speed: manifest response time is infrastructure-level optimisation. The best stores respond in under 200ms. The worst take over 2 seconds. This is fixable independently of your UCP implementation.

Why we turned this into alerts

Continuous monitoring generates signals. But signals are only useful if they reach the right person at the right time.

That's why we shipped UCP Alerts — track any domain and get emailed the moment its UCP status changes. A store goes live with a manifest, you know immediately. A verified endpoint breaks, you know before your agents hit the error. A blocked domain recovers, you know when to retry.

Same crawl cycle powering all the data in this post. Sign in, add domains, and you're covered.

Methodology: Our crawler checks each domain every 24 hours. A check hits /.well-known/ucp, validates against the UCP spec, and evaluates HTTP status, response time, manifest structure, AI bot policies, and errors. All data is from real automated checks recorded between January 21 and February 27, 2026.

Tools:

UCP Checker — Check any store's UCP manifest and agent-readiness
UCP Playground — Watch an AI agent shop any UCP-ready store in real time

If you're building on UCP — MCP server, Shopify app, WooCommerce plugin, agent framework — I'd love to hear what you're seeing. What's working? What's broken? What should we monitor next?

We Ran 180 AI Agent Shopping Sessions Across 11 Models and 20 Stores. Here's What We Found

Benji Fisher — Mon, 23 Feb 2026 23:11:18 +0000

Postman didn't become essential by testing APIs. It became essential by showing developers what was actually happening between their code and the world.

We've been building something similar for agentic commerce.

UCP Playground lets you point an AI agent at any UCP-ready store that supports the Universal Commerce Protocol, and watch it shop — search products, build a cart, reach checkout — across MCP, REST, and Embedded transports. Every tool call is logged. Every JSON-RPC message is traceable. Every session is replayable.

We've now recorded 180 sessions across 11 LLMs and 20 live stores. Not synthetic benchmarks — real agent-to-store conversations over real MCP connections, hitting real catalogs, with real checkout URLs coming back.

The data tells a story about where agentic commerce actually is, and what developers building on UCP need to know right now.

Why "Postman for UCP" isn't just an analogy

Before Postman, you'd write a curl command, squint at the response, and hope for the best. Postman gave you the full request/response lifecycle in one view — headers, body, status code, timing — with the ability to save, share, and replay.

UCP Playground does the same thing for the agent-to-store interface. Point it at a domain. It reads the store's /.well-known/ucp manifest, connects to the MCP server, and opens a chat interface where an AI agent shops for real.

Type "find me running shoes in black, size 10" and watch the agent call search_shop_catalog, parse structured product data, render product cards, and ask which one you want. Say "add the first one" and it resolves the variant ID, calls update_cart, and hands back a checkout URL.

The sidebar gives you the Postman-style observability layer: MCP endpoint status, schema quality grades (A through F per tool), funnel progress, token usage, and full JSON-RPC message traces.

And just like Postman lets you test the same endpoint with different parameters, UCP Playground lets you run the same prompt against up to five models simultaneously — Claude, Gemini, GPT-4o, Llama, side by side, same store, same query — and compare the results.

That comparison capability is where things get interesting.

Three transports, one protocol UCP is transport-agnostic by design. The spec defines how stores advertise capabilities through service discovery at /.well-known/ucp, and a single store can declare multiple transports — each with its own endpoint and schema.

Across the 20 stores we tested, we found three distinct stacks in the wild:

MCP (JSON-RPC) — What Shopify ships. The agent connects to a JSON-RPC server, discovers available tools via schema introspection, and makes real-time tool calls. Five tools: search_shop_catalog, get_product_details, update_cart, get_cart, search_shop_policies_and_faqs. Product IDs are Shopify GIDs like gid://shopify/Product/6881317257296.

REST — The familiar HTTP API pattern. Some merchants expose a REST API alongside or instead of MCP. Simpler ID schemes (integers like "54068"), but often a richer tool surface. The WooCommerce stores we tested via UCPReady exposed 9 tools — full checkout lifecycle management (ucp_create_checkout, ucp_update_checkout, ucp_complete_checkout, ucp_cancel_checkout), plus order management and webhook registration.

Embedded — The newest transport and the one that solves the payment wall. When an agent reaches checkout but can't produce a payment credential (because it's an LLM, not a browser), the merchant declares an embedded transport. The Playground opens the merchant's checkout UI in a secure iframe, handles the ECP handshake over postMessage, and lets the human complete payment while the agent orchestrates the cart.

The schema fragmentation across these stacks is real. Same operation, three different tool signatures:

// Searching products
Shopify MCP:  search_shop_catalog({query: "shoes", context: "..."})
UCPReady:     ucp_list_products({search: "shoes", in_stock: true})
Custom:       list_products({query: "shoes"})

// Adding to cart
Shopify MCP:  update_cart({add_items: [{product_variant_id: "gid://shopify/ProductVariant/123", quantity: 1}]})
UCPReady:     ucp_create_checkout({line_items: [{item: {id: "54068"}, quantity: 1}]})

This is the interoperability testing problem that UCP was designed to solve. UCP Playground makes it visible — run the same agent flow against all three stacks and see where it breaks.

Almin Zolotic, creator of UCPReady — the first WooCommerce UCP plugin — put it well after shipping his integration:

"Building for the agentic web without a tool like UCP Playground is similar to building for the visual web without a browser. It provided the high-fidelity feedback loop needed to move UCPReady from a spec-compliant implementation to a production-ready, agent-shoppable WooCommerce store. Seeing the first autonomous purchase appear in WooCommerce was a defining milestone."

What 180 sessions reveal about model performance

We tested 11 models. Five had enough volume (20+ sessions) to draw real conclusions.

The checkout leaderboard

Llama 3.3 70B reached checkout at 3x the rate of GPT-4o — with the lowest failure rate of any high-volume model.

But speed tells a different story. Gemini 2.5 Flash completes a turn in 1.3 seconds. Llama takes 5.8 seconds. The fastest model converts at half the rate of the most accurate one.

Three models with smaller sample sizes — DeepSeek V3-2 (3 sessions), Gemini 3 Flash (4), and Grok 4 (3) — all hit 100% checkout. Small samples, but they're next on the testing roadmap.

Why Llama wins: the details step

The funnel data explains the gap:

Llama calls get_product_details to resolve variant IDs 2x more often than the other models before attempting to add to cart. It doesn't guess at variant IDs — it looks them up. And its cart-to-checkout conversion is essentially 100%.

The models that skip the details step are guessing at variant structures, hitting type errors, and falling off the funnel. This is something you'd never catch from a single test run — you only see it when you compare flows across models against the same store. The Postman Collections equivalent: run the same sequence, vary the environment, diff the results.

The cost question

When a session does reach checkout, how many tokens does it take?

Llama converts more often, but at the highest token cost per success. Claude burns the most tokens overall. DeepSeek reaches checkout at less than half the token cost of any other model — but with only 3 sessions, that needs validation at scale.

For developers choosing a model for production agentic commerce: it's not just about if it reaches checkout — it's about how much each checkout costs.

5 seconds vs 11 minutes: same store, same protocol

The most telling comparison in the dataset came from a single store running all three UCP transports.

The fast session: Gemini 2.5 Flash, a simple prompt — "Buy me a vichy cream." The agent searched, found 5 results, the user picked one, the agent created a checkout. 4 turns. 5 seconds. 12,877 tokens. Clean, fast, done.

The slow session: Claude Sonnet 4.5, same store, a more exploratory conversation. Over the course of the session, the agent hit four distinct issues that a developer would want to catch:

A timeout on first request — cURL error 28, 15 seconds with 0 bytes received. The agent recovered by retrying with a smaller query, but the first impression was a dead endpoint.
A pagination blind spot — the agent searched for the most expensive product but never paginated past the first 100 results, missing higher-priced items entirely. The limit parameter in the tool schema was set to 100 max — and the agent treated the first page as the full catalog.
A missing route — when the agent tried to update an existing checkout session, the MCP server returned a 404. The ucp_update_checkout endpoint hadn't been registered. The agent worked around it by creating a fresh checkout.
An OOS business logic gap — the server accepted an out-of-stock item into a checkout, then returned a warning after the fact rather than rejecting it upfront.

That session ran for 41 turns, 681 seconds, and 1.6 million tokens — a 130x token difference from the fast session on the same endpoint.

None of these issues would show up in a manifest scan. They only surface when an agent actually tries to shop. And with session replay, a developer can pinpoint each one in the trace instead of reading server logs — the same way you'd debug a failing Postman request by inspecting the response body and timing.

Store instructions: the hidden prompt engineering layer

One of the most interesting patterns we found isn't in the agent — it's in the store's MCP responses.

When Shopify's MCP server returns tool results, it injects instructions fields — stage-specific prompts embedded in the response payload. There are three, one per shopping stage:

Search instructions tell the agent how to present results — render markdown links, mention available filters, paginate.

Details instructions are minimal — render the title as a link, pay attention to the selected variant.

Cart instructions are where it gets fascinating:

Ask if the customer has found everything they need... help them complete their cart with any additional items they might need... check if they have any discount codes or gift cards...

This is the store coaching the agent through a structured checkout funnel. In one test session, Claude asked "would you like to add anything else, like running socks for example?" — a cross-sell that wasn't in any system prompt. It came from the store's update_cart response instructions.

We tested compliance on Claude Sonnet 4.5 against Allbirds: 8 out of 9 instructions followed. It rendered markdown links, resolved variants correctly, suggested additional items, and provided the checkout URL as a clickable link. The only misses: it didn't mention available filters during search and skipped the "special instructions" prompt at checkout.

The takeaway for anyone building an MCP server for commerce: ship behavioral instructions with your tool responses. The store isn't just serving data — it's doing per-tool prompt engineering at the response level. And it works.

The error taxonomy

37 tool call errors across 168 calls. Here's the pattern:

Timeout — cURL 28 — shopify merchant policy search, 15s with 0 bytes received. Slow or unresponsive endpoint.

Internal Error — MCP -32603 — shopify merchant. Server-side exception, no error body returned.

Auth Failed — MCP -32000 — 2x merchant sites. Endpoint requires auth the agent doesn't have.

Method Not Found — MCP -32601 — dev site tools/call. Deployment or routing issue.

Invalid Type — MCP -32602 — line_items: "22" instead of array. LLM passed wrong type to tool.

Route Not Found — REST 404 — merchant site ucp_update_checkout. Endpoint not registered.

The most common: _search_shop_catalog_ fails 23% of the time. Policy search fails 40%. Cart operations are the most reliable at 7%.

The type validation error (-32602) is the only one that's the model's fault rather than the store's. The LLM passed a string "22" where the schema expected an array of line item objects. Better schema descriptions and proper required field annotations in the tool definition would prevent it.

Every one of these errors shows up in the Playground's session trace — the MCP error code, the request payload, the response (or lack thereof), and the timing. The same debug workflow you'd use in Postman when an API returns something unexpected.

One store, five models, 100% checkout

Everlane is the gold standard in this dataset. Seven sessions across five models. Every one reached checkout. Zero errors.
Same prompt — "what mens backpacks do you have?" — across all five:

Same store. Same prompt. Same outcome. Same turn count. 5x latency difference between fastest and slowest. The MCP implementation is clean, fast (452ms average endpoint response), and returns consistent schemas. Every model just works.

This is the controlled test that matters — one variable at a time. It's the Postman equivalent of saving a collection, switching environments, and running it against each one. If your store doesn't perform like this across models, the Playground will show you why.

What to build on

Based on 180 sessions, here's where the leverage is for different audiences:

If you're building agents: The get_product_details → update_cart sequence is the critical path. Models that resolve variant IDs before carting convert at 2-3x the rate of those that don't. If your agent skips the details step, that's your optimization target.

If you're building an MCP server: Schema quality is the biggest predictor of agent success. Tools with clear descriptions, proper required fields, and well-defined items schemas succeed. Tools with properties: [] or missing descriptions fail. We built a schema quality scorer (A through F) because this pattern was so consistent.

If you're a store owner: Store instructions in tool responses are an underrated superpower. Stores that inject behavioral hints — how to present products, when to use which tool, how to handle variants — get dramatically better agent behavior. The best-performing stores in our dataset all do this.

If you care about checkout: The payment wall is real. Google's UCP-powered checkout is live but limited to select US stores. Outside of that, independent developers like Zologic are delivering the most complete end-to-end flows — implementing embedded checkout where the merchant's UI handles payment in an iframe while the agent orchestrates the cart.

Try it

UCP Playground — Point it at any UCP ready domain. Watch an agent shop. Replay any session.

UCP Checker — Check any store's UCP manifest and agent-readiness.

All session data in this post is from real agent interactions recorded between February 14–23, 2026. No sessions were staged or simulated.

I built UCP Checker because I wanted to understand how ready the open web actually was for agentic commerce. Scanning manifests answered part of that question. But the real answer only comes when you watch an agent try to shop — and see where it succeeds, where it breaks, and why.

That's what UCP Playground does. It's the observability layer between AI agents and store APIs — the same way Postman became the observability layer between developers and REST endpoints. Except instead of testing GET /users, you're testing whether Claude can buy someone a pair of shoes.

If you're building on UCP — whether that's an MCP server, a Shopify app, a WooCommerce plugin, or an agent framework — I'd genuinely love to hear what you're seeing. What's working? What's broken? What should we test next?

Drop a question in the comments or reach out at ucpchecker.com. I read everything.

DEV Community: Benji Fisher

The First Fully Autonomous AI Agent Purchase Through UCP

What you’re looking at

The full tool call sequence

What had to work

Protocol layer

Identity linking

Agent orchestration

Payment processing

What broke along the way

Why protocol matters

What’s next

Try it

Sources

3,000 UCP Stores, Open Data: Why We're Publishing Our Dataset on Hugging Face

What's in the dataset

What you can build with it

What's in the open dataset

Why publish it

What the data shows

Go use it

The BigCommerce UCP Guide: The Sleeping Giant of API-First Agent Commerce

What BigCommerce Provides

The Manifest: What We See Across Monitored BigCommerce Stores

Common Manifest Issues We Flag

Runtime Performance: Competitive With Shopify, Architecture-Dependent

Configuration Checklist

Multi-Storefront and Channel Considerations

Common Failure Modes

Product Feed Best Practices

What's Coming

Check Your Store

References & Official Resources

Further Reading

Related Platform Guides

The Magento UCP Guide: What Enterprise Monitoring Data Tells Us About Adobe Commerce Agent Readiness

What Magento Requires

The Manifest: What We See Across Enterprise Monitoring

Common Manifest Issues We Flag

Runtime Performance: Infrastructure-Dependent

Configuration Checklist

Multi-Store and B2B Considerations

Common Failure Modes

Product Feed Best Practices

What's Coming

Check Your Store

References & Official Resources

Further Reading

Related Platform Guides

The WooCommerce UCP Guide: What Our Monitoring Data Reveals About WordPress Agent Commerce

What WooCommerce Requires (vs. What Shopify Provides Natively)

The Manifest: What We See Across Our WooCommerce Dataset

Common Manifest Issues We Flag

Runtime Performance: Hosting Matters Enormously

Configuration Checklist

Plugin Compatibility: The WordPress Ecosystem Challenge

Common Failure Modes

Product Feed Best Practices for WooCommerce

What's Coming

Check Your Store

References & Official Resources

Further Reading

Related Platform Guides

The Shopify UCP Guide: What 3,200 Monitored Domains Taught Us About AI Agent Commerce

What Shopify Provides Natively

The Manifest: What We See Across 3,200 Domains

Common Manifest Issues We Flag

Runtime Performance: What Agents Actually Experience

Configuration Checklist

Shopify Markets and Multi-Region Considerations

Common Failure Modes

Product feed best practices

What's Coming

Check Your Store

References & Official Resources

Further Reading

Related Platform Guides

We Built OAuth Identity Linking Into Our AI Agent Commerce Playground — Here's How the Protocol Actually Works

We Built a Chrome Extension That Discovered 1,480 Agent-Ready Stores. Here's Exactly How It Works.

We Monitored 2,000 UCP Manifests Every Day for a Month. Here's What Breaks