Updated 26 September 2026. This article originally described UCP too narrowly as a transaction-only layer and said KaliCart Bridge published a merchant-domain UCP profile. UCP now has an explicit Catalog capability, and since Bridge 1.0.137 KaliCart serves opted-in WooCommerce stores through KaliCart Global instead of declaring an unimplemented UCP binding on each store.
Two problems, not one
"Expose a catalog to an agent" and "let an agent transact" sound like one problem. They are two, and the clearest way to see it is by analogy with the web. HTTP defines how a browser and a server talk; HTML defines the structured content that makes the response worth rendering. A perfectly compliant HTTP exchange delivering malformed HTML gives the user nothing useful. The transport being correct does not make the payload legible.
Agentic commerce has a similar split, but the boundary is not protocol versus catalog. UCP can carry catalog discovery and transaction capabilities. ARC focuses on a different question: whether the catalog facts are explicit, current and trustworthy enough for an agent to reason over. A UCP Catalog interface and an ARC legibility contract can therefore describe the same product surface from different angles.
- Discovery signals + discovery document
- Catalog endpoints: search, listing, detail
- Explicit availability, list price, variants
- Quality signals for weak records
- Hands off at checkout — no payment
- Capability profile at /.well-known/ucp
- Catalog search and product lookup
- Checkout: sessions, tax, totals
- Identity linking (OAuth 2.0)
- Orders: webhook lifecycle events
- Payment token exchange, AP2
What UCP is (from the source)
UCP is an open standard, published on GitHub under the Apache 2.0 license, describing itself as enabling interoperability between commerce entities to facilitate seamless integrations. Its README states the design directly: businesses declare supported capabilities for autonomous discovery, facilitate secure checkout sessions with or without human intervention, and do so over standard transports.
Three facts from the specification matter here:
It is composable and discovery-driven. A business publishes a profile declaring which capabilities it supports; platforms read it and configure themselves. Google's UCP documentation specifies that this profile is published at /.well-known/ucp.
It is transport-agnostic. The spec states capabilities can be offered over REST, MCP, or A2A, depending on the business's infrastructure.
Its initial release centered on transactions, with Checkout, Identity Linking, Order and Payment Token Exchange capabilities. The protocol has since made Catalog a first-class capability too: Shopify's Global Catalog and Storefront Catalog both implement UCP Catalog over MCP.
The useful distinction is therefore not “UCP has no catalog.” It is that a protocol can standardize how catalog tools are called without, by itself, guaranteeing the completeness, provenance or legibility of every product record returned.
What ARC is
ARC is deliberately narrower. It is a contract for one job: making a product catalog legible and trustworthy to an agent before a transaction is attempted.
It defines discovery signals and a discovery document, catalog endpoints (search, listing, product detail), and a product object carrying explicit operational facts — availability, list price, variants, and quality signals for records that are ambiguous or incomplete. Its conformance levels describe catalog legibility, and they stop short of payment on purpose: an ARC surface hands off to the merchant's own checkout rather than processing payment itself.
The restraint is the design, not an unfinished edge. ARC answers can an agent understand this offer well enough to consider it? and leaves executing the purchase to whatever executes purchases.
Where they meet — a matter of record
This is the part usually missed, and it isn't aspirational — it's written into the ARC specification's UCP-interoperability section. ARC was authored so its catalog data is UCP-shaped at the field level:
stock.availability_statususes UCP's standard values, rather than a private vocabulary.list_pricecarries the strikethrough list price specifically for UCP interoperability.variants[]follows a shape aligned with UCP.- An ARC catalog can coexist with a UCP profile and UCP Catalog binding; the profile must declare only capabilities the implementation actually serves.
Because the vocabulary was chosen to match, the core catalog facts an ARC surface exposes are already in the form a UCP-speaking agent expects. The handoff between "legible catalog" and "transaction protocol" is a boundary both sides describe the same way, so it needs no translation layer to cross.
Why two layers is the right shape
If UCP already contemplates a catalog, why should a separate legibility contract exist? Because defining the interface and governing the content are different jobs.
An interface specifies the tool names and the request and response shapes an agent calls. It does not, by itself, guarantee that availability is stated with confidence rather than implied, that the same fact is offered at the right resolution for the step the agent is on, or that a low-quality record is quarantined instead of silently returned. A catalog can satisfy an interface and still be too noisy to reason over. The interface says how to ask; the legibility contract says what a good answer looks like.
Keeping those separate is the same principle UCP itself is built on. UCP's own README describes breaking commerce into distinct capabilities and extensions precisely so implementations stay flexible and don't bloat. A catalog-legibility layer feeding a transaction layer applies that separation one step earlier in the funnel: what makes a catalog worth transacting on is not the same mechanism that executes the transaction.
In practice
Concretely, on a real store, the two layers coexist without conflict.
On Shopify. Shopify's agentic-commerce stack is UCP-compliant. Its developer documentation describes Storefront Catalog MCP (single-merchant product discovery) and Global Catalog MCP (cross-merchant), both implementing the UCP Catalog capability and its MCP binding, alongside cart and checkout capabilities. A Shopify merchant participates in the transaction layer through this stack.
On WooCommerce. KaliCart Bridge exposes a bounded live catalog from the merchant's domain. Stores that explicitly join the Federated Catalog can also be searched through KaliCart Global's UCP Catalog endpoint and profile. Since Bridge 1.0.137 the plugin does not publish a merchant-domain UCP profile, because that would declare a binding the plugin itself does not implement. Checkout remains the merchant's WooCommerce flow; neither Bridge nor KaliCart Global claims a complete UCP transaction stack.
The practical shape is a catalog interface agents can call, a legibility contract that makes its answers trustworthy, and a separate purchase path whose capabilities must be declared honestly.
The useful question
"UCP versus ARC" presumes a fight for one piece of ground. The better questions are whether an agent can call the catalog through an interoperable interface, whether the returned facts are legible and trustworthy, and which separately declared path completes the purchase. Those questions can share a vocabulary without being collapsed into one claim.
Sources
- Universal Commerce Protocol — specification & README (Apache 2.0): github.com/Universal-Commerce-Protocol/ucp and ucp.dev
- "Under the Hood: Universal Commerce Protocol" — Google Developers Blog
- "Building the Universal Commerce Protocol" — Shopify Engineering
- UCP business profile (
/.well-known/ucp) — Google for Developers, merchant UCP guide - Shopify UCP Catalog documentation — shopify.dev/docs/agents/catalog
- KaliCart's current WooCommerce UCP architecture — UCP for WooCommerce
- ARC specification, §8 UCP interoperability — bridge.kalicart.com/spec