Implementing UCP: A Working Catalog Feed Walkthrough

UCP is the discovery-and-catalog side of agentic commerce: it is how a shopping agent operating in Google AI Mode or the Gemini apps finds out what you sell, whether it fits the user's request, and how to transact. The protocol is an open standard under Apache 2.0, and it composes with the rest of the stack, the three-protocol landscape is mapped here, so this walkthrough stays on the catalog layer: what an agent needs from your product data, and the order to build it in.

One framing note before the steps: an agent reading your catalog is doing comparison under constraint. It has a user request ("waterproof trail runners under $150, size 44, shipping to Austria"), a handful of candidate products across merchants, and a token budget. Every field you publish either helps it line your product up against alternatives or wastes its budget. That property, whether your catalog can be lined up, is catalog legibility, and it is the thing this walkthrough builds.

Step 1: expose the discovery profile

UCP is discovery-first. An agent starts by fetching a merchant capability profile from a well-known URL on your domain, which declares what you support: which capabilities (checkout, identity linking, cart), which transport (REST, JSON-RPC, MCP), which payment handlers. This profile is your handshake; without it, the agent does not know you speak the protocol at all.

The practical work here is small but exact: serve the profile at the spec's well-known path, keep it valid JSON, declare only capabilities you actually support, and version it honestly. Declaring capabilities you have not implemented is worse than declaring fewer, because an agent that fails mid-flow on your site learns to route around you. If you run on Shopify, the platform publishes this for you; the audit task is verifying what it declares matches what your store actually does.

Step 2: identity fields, the non-negotiables

An agent comparing products across merchants needs to know it is looking at the same product. That is what identity fields are for, and they carry more weight in agentic commerce than anywhere else, because cross-source verification is how agents establish trust. Three fields do the work: the GTIN (the global identifier that lets the agent match your listing against the same product elsewhere), the brand (as a stable entity name, not a marketing string), and the canonical product name (consistent with how the product is named everywhere else it exists).

The common failure: a merchant renames products for differentiation ("UltraGrip Pro Trail Beast 3000" for a shoe every other store calls by its manufacturer name), which breaks the agent's ability to verify the listing and silently drops it from comparisons. In the selection economy of agents, being unverifiable is being invisible. The full field set that determines product visibility extends this, but identity is the layer nothing else survives without.

Step 3: price, availability, and the truthfulness constraint

Agents act on your data. A human seeing a stale price gets annoyed at checkout; an agent seeing a stale price builds a transaction on it, fails, and records the failure. That changes the engineering requirement: price and availability in your UCP-facing data must be as fresh as your actual store state, which usually means generating them from the same system of record that powers checkout, not from a nightly export. If your feed pipeline has a lag, publish conservative availability rather than optimistic, an agent that finds you honestly out of stock returns later; an agent that finds you falsely in stock does not.

Include the currency explicitly, the shipping scope honestly, and condition where relevant. Pricing and stock-status structure for AI surfaces covers the schema side, and the same rules carry into UCP: the fields are cheap; keeping them true is the actual work.

Step 4: variants in comparable units

The last layer is where merchants with rich product pages still fail: variants and specifications published in ways only a human can interpret. "Available in multiple sizes" is legible to a person scanning a page and useless to an agent filtering for size 44. The requirement is structured enumeration: every variant as its own addressable option with its own availability, and specifications in standard units, weight in grams, dimensions in centimeters, capacity in liters, not in marketing language. An agent comparing five products across three stores lines up whatever it can parse into the same axis; everything else falls out of the comparison.

This is also where the catalog work pays twice: the same structured attributes that make you legible to UCP agents strengthen your product schema for AI search surfaces, the nesting structure that connects product to merchant is the shared substrate.

What to validate before you call it done

Run the agent's checklist against your own feed. Can a program, not a person, determine what the product is, verify it against an external source, learn the true current price and availability, filter it by every variant axis, and find the transaction path? Then test the negative space: what happens when a product is discontinued, out of stock, or region-locked. Agents remember failures structurally, a failed flow is a signal your capability profile overpromised. The merchants that win agent traffic are not the ones with the largest catalogs; they are the ones whose catalogs never lie.

The contrarian point, and it matters for budgeting: the hard part of UCP is not the protocol integration, which platforms increasingly handle, it is the data quality underneath it. A merchant with clean identity fields, truthful availability, and structured variants can become UCP-legible in days. A merchant with a decade of inconsistent product data cannot, regardless of integration budget, because the protocol transmits your catalog exactly as coherent as it actually is. UCP does not fix your data. It exposes it.

Sources

• Google Developers, Under the Hood: Universal Commerce Protocol: the official architecture overview. developers.googleblog.com
• Shopify Engineering, Building the Universal Commerce Protocol: the co-developer's design rationale: discovery, negotiation, capabilities. shopify.engineering
• Schema.org, Product: the structured-data vocabulary the catalog layer builds on. schema.org/Product
• Website AI Score, the three protocols compared: where UCP sits against ACP and MCP. View article
• Website AI Score, the 14 product schema fields: the visibility field set the catalog layer extends. View article