UCP Catalog Search & Lookup: AI Product Discovery 2026

TL;DR

Discovery Gap Closed: UCP’s new catalog capability introduces `dev.ucp.shopping.catalog.search` and `dev.ucp.shopping.catalog.lookup`, enabling AI agents to find and retrieve products before a checkout session even begins.
Two Capabilities, One Pipeline: Search handles free-text and filter-based product discovery, while Lookup handles precise variant retrieval by ID, SKU, or handle. Both can be adopted independently.
Protocol-Level Standardization: Both REST and MCP (Model Context Protocol) bindings are defined, meaning AI agents built on any platform can query your catalog using a single, interoperable standard without custom integrations.

For months, the Universal Commerce Protocol addressed cart management, checkout, and payment, but it operated with one significant assumption baked in: the AI agent already knew which product it wanted to buy. That assumption excluded the most commercially critical part of the buyer journey — product discovery. As of March 2026, that gap is formally closed. A new commit to the UCP repository introduces the `dev.ucp.shopping.catalog` capability, splitting product discovery into two distinct, independently adoptable capabilities: search and lookup. This article breaks down exactly how they work, what the schema definitions tell us, and why this release changes the calculus for every merchant, platform, and AI agent developer operating in 2026.

The Discovery Gap That Checkout Could Not Fill

To understand why catalog search and lookup matter, you need to understand what UCP’s checkout capability implicitly requires. The `dev.ucp.shopping.checkout` capability accepts a `line_items[].item.id`, specifically a variant-level identifier. That design is intentional: checkout is a deterministic transaction, and deterministic transactions require known quantities. The protocol specifies what to buy, how many, and what to pay.

The problem is that in the real world, an AI agent shopping on behalf of a user rarely starts with a variant ID. It starts with a natural language expression of intent: “find me blue running shoes under $150,” “I need a 12-piece chef knife set that ships within two weeks,” or “show me the cheapest available variant of this product I saved last month.” These are discovery queries, not checkout intents.

What Was Missing Before Catalog Capabilities

Before this commit, UCP-compliant merchants could expose their checkout pipeline to AI agents, but those agents had no standardized way to browse the catalog to find what to put into a cart in the first place. They would have needed to fall back on custom search APIs, product feed parsers, or platform-specific integrations that are explicitly what UCP was designed to eliminate. The catalog capability introduces the missing layer: a standardized interface for product discovery that plugs directly into the checkout pipeline.

The variant IDs returned by `catalog/search` and `catalog/lookup` map directly to the `item.id` field in checkout line items. The connection is not incidental — it is architecturally deliberate, completing the full buyer journey within a single coherent protocol surface.

The Scale of What This Unlocks

This release has direct commercial implications. A user asking a Gemini agent to “find me comfortable running shoes under $150 in size 10” can now trigger a `POST /catalog/search` with a semantic query, a price filter, and a size context. The agent receives structured product and variant data, selects the best match, and passes the variant ID directly into `POST /checkout`. The entire journey from discovery to payment confirmation happens within UCP, without the agent ever touching a product detail page or initiating a custom API call. For merchants, this means visibility to AI agents is no longer gated by whether they have bespoke AI integrations. It is gated by whether they are UCP-compliant.

Understanding dev.ucp.shopping.catalog.search

The catalog search capability is registered under the identifier `dev.ucp.shopping.catalog.search`. It exposes a single operation, Search Catalog, accessible via `POST /catalog/search` in REST and `search_catalog` in MCP’s JSON-RPC interface.

Search Inputs: What an AI Agent Can Send

A valid search request must include at least one recognized input. The specification defines three valid input types, and this is a deliberate extensibility decision worth examining closely.

The first is a free-text `query` string. This is the most familiar input: a natural language search phrase like “blue running shoes” or “stainless steel French press.” The specification explicitly supports semantic search, meaning implementations can use embedding-based retrieval rather than simple keyword matching. An agent sending “comfortable shoes for standing all day in a kitchen” can legitimately expect semantically relevant results, even if those exact words do not appear in product titles.

The second input type is `filters` without any query. This represents a browse operation. An agent that knows a user wants products in the “Footwear > Running” category priced between $5,000 and $15,000 (in minor units, so $50 to $150) can send a filter-only request and receive a ranked product set without any text relevance scoring. This is the structured equivalent of navigating a category page.

The third input type covers extension-defined inputs. The specification explicitly carves out space for future modalities: image search, vector search, reference-product-based search, and other mechanisms that business implementations may define. This is an open vocabulary design, not a closed enum, which means the protocol can evolve without version bumps.

Filters: Categories and Price

The `filters` object accepts two standard parameters. The `categories` field accepts an array of strings with OR semantics. If an agent sends `[“Footwear”, “Accessories”]`, it will receive products matching either category. Category values match against the `value` field in product category entries, which can draw from any taxonomy: Google Product Category, Shopify, or a merchant-defined hierarchy.

The `price` filter accepts a `min` and `max` value, both expressed in ISO 4217 minor units. A request filtering for products under $150 in USD would send `”max”: 15000`. The currency denomination follows the `context.currency` field, so the protocol requires platforms to include their preferred currency when sending price filters to avoid ambiguous denominations. If the presentment currency differs from the filter currency, implementations should convert before applying the filter. If conversion is not supported, implementations may ignore the filter and are expected to notify the agent via a `messages` entry in the response.

Context: Location, Language, Intent, and Currency

The `context` object is one of the most strategically important elements in the catalog capability. It is a provisional hint layer carrying four fields: `address_country` (ISO 3166-1 alpha-2), `address_region`, `postal_code`, `language` (IETF BCP 47), and `currency` (ISO 4217).

The new `language` field deserves specific attention. It was added specifically to support content localization. A platform can send `”language”: “es”` to request Spanish-language product descriptions. For REST requests, this field overrides the `Accept-Language` header when present. Businesses may return content in a different language if the requested language is unavailable, but they must make a best-effort attempt. The practical implication: merchants with multilingual catalogs can now serve AI agents from different markets with localized content through the same endpoint, without routing logic in the agent.

The `intent` field within context is a free-text hint for semantic context beyond the query itself: “looking for a gift under $50,” “need something durable for outdoor use,” “buying for a 10-year-old.” Implementations can use intent to rerank results, adjust recommendations, or personalize the product set beyond what the query alone would produce.

Critically, context signals are explicitly designated as provisional and not authoritative. The specification states that eligibility and policy enforcement must occur at checkout time using binding transaction data. An agent claiming to be in California cannot unlock region-restricted products: the checkout will enforce it. This framing prevents agents from gaming context to access products or prices not legitimately available to them.

Understanding dev.ucp.shopping.catalog.lookup

The catalog lookup capability, `dev.ucp.shopping.catalog.lookup`, handles targeted retrieval by identifier. Where search answers “what products match this query?”, lookup answers “give me exactly these products or variants by ID.”

Supported Identifiers and Resolution Behavior

Implementations must support two identifier types: product ID and variant ID. They may additionally support secondary identifiers like SKU, barcode, or handle, provided these are also fields on the returned product object. This requirement ensures that clients can correlate inputs to outputs by field matching, not by relying on opaque server-side logic.

The resolution behavior follows a two-tier model. When the input is a variant ID, the match type is `exact`: the identifier resolved directly to that specific variant. When the input is a product ID or a handle, the match type is `featured`: the server selected a representative variant as the best match for that identifier. This distinction is machine-readable, exposed through the `inputs` array on each variant in the lookup response.

Client Correlation: The inputs Array

One of the most sophisticated design elements in the lookup capability is the `inputs` array on each returned variant. In a batch lookup, a client can send 10 different identifiers, and the server may return a different number of products depending on deduplication, merging, and resolution behavior. Without an explicit correlation mechanism, the client would need to reverse-engineer which input IDs mapped to which returned variants by field-matching, which is brittle and ambiguous.

The `inputs` array solves this. Each variant in a lookup response carries at least one entry: `{id: “the-request-id”, match: “exact|featured”}`. When two different input IDs resolve to the same variant — say, a product ID and one of its variant IDs — the variant carries two entries in its `inputs` array, one per resolved identifier, each with its own match type. The specification mandates that variants without an `inputs` entry must not appear in lookup responses, making the correlation guarantee binding on all conforming implementations.

Batch Size and Error Handling

Implementations should accept at least 10 identifiers per request. There is no hard maximum specified at the protocol level: implementations set their own upper bound. When a request exceeds the implementation’s maximum, the server must reject it with HTTP 400 `request_too_large` for REST or JSON-RPC error code -32602 for MCP. This is a transport-level error, not a business outcome, meaning it short-circuits the response rather than appearing in the `messages` array.

Not-found identifiers do not generate transport errors. When a requested identifier has no match, the server returns success with the found products, and may include an informational message with code `not_found` and the unresolved identifier as the content. This graceful partial-success behavior is aligned with how AI agents need to handle mixed-reliability inputs: a batch of 10 IDs where 8 are found and 2 are stale should not fail catastrophically.

The Product and Variant Schema: What Gets Returned

Both search and lookup return an array of `products`, each conforming to the Product schema. Understanding this schema in depth is essential for merchants deciding how to structure their catalog data for AI agent readiness.

Product-Level Fields

A product object requires: `id`, `title`, `description`, `price_range`, and `variants`. Every other field is optional, but the specification is deliberate about what those optional fields enable.

`price_range` replaces the earlier `price` field naming and references a `PriceRange` schema with `min` and `max` values. This is the price range across all variants of the product. The naming change from `price` to `price_range` was intentional: it signals to agents that this is a range, not a single price point, preventing false inference about actual variant pricing.

The `handle` field is a URL-safe slug designed for SEO-friendly URLs, like `blue-runner-pro`. The specification explicitly notes that `handle` is for SEO and display, while `id` should be used for stable API references. This distinction matters for merchants who rotate slugs for marketing campaigns: the handle may change, but the product ID must remain stable.

The `categories` field accepts an array of category objects, each carrying a `value` and a `taxonomy`. A single product can simultaneously carry Google Product Category taxonomy, Shopify taxonomy, and a merchant-defined taxonomy, all in the same field. This multi-taxonomy design explicitly accommodates the reality that AI agents and platforms may use different classification systems, and a single response needs to serve all of them.

The `media` array is ordered. The first element is the featured media for listing contexts. This ordering contract is normative, not a recommendation: platforms should treat the first item as the featured image. AI agents rendering product cards or generating purchasing summaries benefit from a guaranteed featured media position.

Variant-Level Fields

Variant objects carry their own rich schema. The `availability` object now supports two fields: `available` (boolean) and `status` (open string). The boolean answers “can I buy this?” directly. The `status` field qualifies the fulfillment state: well-known values include `in_stock`, `backorder`, `preorder`, `out_of_stock`, and `discontinued`. An agent can check `available: true` and then surface `status: “backorder”` to inform the user that the product ships in 2-3 weeks, rather than simply confirming it is purchasable.

The `barcodes` field replaces the single `barcode` string from earlier schema drafts. It now accepts an array of objects, each with `type` and `value`, supporting UPC, EAN, ISBN, GTIN, and JAN simultaneously. This matters for agents operating in marketplaces where cross-referencing product identity across platforms requires multiple barcode standards.

The new `unit_price` field enables per-unit pricing for products sold by weight, volume, or length. A 750ml wine bottle priced at $25 can expose a unit price of $3.33 per 100ml, precomputed by the merchant. The specification explicitly requires the merchant to precompute this value rather than deriving it from the variant price at runtime, ensuring consistent display across all agent surfaces.

Enabling Your Store for UCP Catalog Discovery

At UCP Hub, this is the moment we have been preparing merchants for. The catalog capability is not a passive upgrade: it requires intentional action to ensure your product data is ready for agent-mediated discovery.

If you want AI agents like Gemini, Claude, and ChatGPT Shopping to surface your products through the UCP catalog pipeline, your store needs to expose structured, machine-readable data that conforms to the Universal Commerce Protocol. Book a discovery call with UCP Hub to discuss how we can help you implement catalog search and lookup readiness for your WooCommerce or Shopify store, before your competitors get there first.

REST vs MCP Bindings: Choosing Your Transport

The catalog capability is defined at the capability level and then bound to transport protocols separately. REST and MCP are both first-class citizens in the specification, and merchants can implement one, the other, or both.

REST Binding: Two Endpoints

The REST binding defines two endpoints. `POST /catalog/search` accepts a JSON body with `query`, `context`, `filters`, and `pagination`. `POST /catalog/lookup` accepts a JSON body with `ids` (array) and `context`. Both endpoints return HTTP 200 for all business outcomes, including partial success and not-found scenarios. Transport-level errors (400, 401, 429, 500) are reserved for protocol failures, not business logic. Response bodies include the standard UCP envelope with `capabilities`, the `products` array, and an optional `messages` array.

MCP Binding: JSON-RPC via Model Context Protocol

The MCP binding exposes two tools: `search_catalog` and `lookup_catalog`. Both operate over JSON-RPC 2.0 using the `tools/call` method. MCP requests require a `meta` object carrying the `ucp-agent` profile, enabling version compatibility checking and capability negotiation between the agent and the server.

The MCP binding is particularly significant because it is the native integration path for AI agents built on Model Context Protocol infrastructure. Agents that use MCP as their tool-call layer can query your product catalog using standard JSON-RPC semantics, with no HTTP REST plumbing required on the agent side. This is the architecture that enables agents like Claude to call merchant tools directly via MCP servers.

Capability Discovery via .well-known/ucp

Both transport bindings are advertised through the UCP discovery manifest at `/.well-known/ucp`. A merchant’s profile must declare `dev.ucp.shopping.catalog.search` and `dev.ucp.shopping.catalog.lookup` as capabilities, each with version, spec, and schema references. This is how AI agents discover what a merchant supports before initiating any catalog request. The UCP .well-known directory guide on UCP Hub covers the implementation details for this discovery layer.

Pagination: Cursor-Based and Clamp-Aware

Catalog search supports cursor-based pagination. The `pagination` request object accepts `cursor` (an opaque string from a previous response) and `limit` (the requested page size). The default limit is 10.

The specification’s approach to page size is nuanced: `limit` is a requested page size, not a guaranteed count. Implementations should accept at least 10, but may clamp silently when the requested limit exceeds their maximum. Clients must not assume the response size equals the requested limit. This design mirrors pragmatic production behavior where database query limits, caching tiers, and rate controls may result in smaller pages than requested, and clients that treat limit as a contract will break.

The pagination response object includes `has_next_page` (required), `cursor` (required when `has_next_page` is true, enforced via JSON Schema `if/then`), and `total_count` (optional). The `cursor` field is absent by design when there are no more pages, preventing clients from storing stale cursors for exhausted result sets.

Measuring Success: KPIs for Catalog Capability Adoption

Implementing UCP catalog search and lookup is a strategic investment. Here is how to measure its impact at 30, 60, and 90 days post-launch.

What to Expect 30 Days After Launch

In the first 30 days, the primary KPI is discovery indexability: the percentage of your product catalog successfully indexed and returnable by a search or lookup request. Target a coverage rate above 90% of active SKUs. Secondary metrics include response latency (target under 200ms for search, under 100ms for lookup) and schema validation pass rates. Any products missing required fields such as `description`, `price_range`, or at least one `variant` will not return in search results. Use the UCP Store Check to identify compliance gaps before they silently exclude products from agent-mediated discovery.

What to Expect at 60 Days

At 60 days, shift focus to agent engagement metrics. Track the volume of `POST /catalog/search` and `POST /catalog/lookup` calls in your server logs or analytics layer. Monitor the ratio of search calls to checkout initiations: a well-functioning catalog capability should generate measurable checkout intent from agent sessions. Target a catalog-to-checkout conversion rate of at least 15-20% in the initial phase, with optimization toward 30%+ by end of Q2. Also track category filter usage: high filter volume signals that agents are using structured browse paths, not just raw semantic search.

What to Expect at 90 Days

At 90 days, the focus shifts to revenue attribution. Segment orders by source: did the checkout session originate from a `catalog/search` query? Cross-reference variant IDs in checkout line items against the catalog sessions that produced them. Merchants with strong UCP catalog coverage report agentic conversion rates up to 9x higher than traditional referral traffic because the agent has already negotiated intent, matched constraints, and selected the optimal variant before the checkout session begins. Track average order value from agentic sessions separately. Agents optimizing for price-within-budget constraints tend to find higher-margin products within the user’s stated ceiling rather than defaulting to the cheapest option.

Security Considerations Built Into the Catalog Spec

The catalog specification includes several security requirements that merchants and platform implementers must handle explicitly.

HTML Sanitization for Product Descriptions

The `description` object supports three formats: `plain`, `html`, and `markdown`. The HTML format carries an explicit security note: platforms must sanitize HTML before rendering, stripping scripts, event handlers, and untrusted elements. This matters because catalog data flows from merchant backends through AI agent interfaces into user-facing surfaces. Unsanitized HTML in product descriptions creates a cross-site scripting attack surface at every point where that content is rendered. Merchants populating the `html` format field must ensure their CMS or product management system does not inject executable content, and platforms rendering it must apply their own sanitization layer regardless.

Context Signals Are Not Authorization

The specification’s security framing of context signals is worth restating at the implementation level. Context fields like `address_country`, `currency`, and `intent` are provisional hints. They inform relevance and localization. They do not grant access. A merchant receiving a catalog search request with `”address_country”: “US”` must not use that signal as an authorization substitute for displaying US-only pricing or restricted products. The only authoritative enforcement point is checkout, using verified transaction data. Merchants who expose region-restricted catalog items through search without a checkout-level enforcement layer are creating an exploitable gap.

RFC 9421 Request Signing

Both catalog endpoints require RFC 9421 HTTP Signatures via three headers: `Signature`, `Signature-Input`, and `Content-Digest`. This signing requirement is the same as for checkout and cart endpoints. It establishes a chain of custody from the AI agent’s registered platform identity through every request in the commerce pipeline. Merchants who have already implemented request signature verification for checkout can extend that same verification logic to catalog endpoints with minimal additional work. The UCP security guide on UCP Hub covers the trust architecture in detail.

How Catalog Capabilities Connect to the Full UCP Commerce Journey

The catalog capability does not exist in isolation. It is the entry point into a sequential UCP pipeline that flows through cart, checkout, and order.

From Discovery to Transaction

A well-structured agentic commerce session unfolds across four UCP capability layers. The catalog capability provides discovery: the agent finds a product and selects a variant. The cart capability provides session state: the agent adds the variant to a cart and manages quantities. The checkout capability provides transaction initiation: the agent submits billing and shipping details, receives a total, and confirms purchase intent. The order capability provides fulfillment tracking: the agent monitors status and handles returns.

Prior to this release, UCP-compliant merchants were building pipelines that started at cart or checkout. With catalog search and lookup defined, the pipeline now has a complete, protocol-native top of funnel. Agents that previously needed to scrape product pages, parse feeds, or call bespoke search APIs can now enter the UCP pipeline at the discovery stage and remain within it through fulfillment.

Independent Adoption Is Explicitly Supported

One of the clearest signals of the specification’s pragmatism is the explicit statement that search and lookup can be adopted independently. A merchant who already exposes structured product data through a search endpoint can add `dev.ucp.shopping.catalog.lookup` first, enabling agents to resolve variant IDs from external sources without implementing full-text search. A marketplace building a discovery layer can implement `dev.ucp.shopping.catalog.search` without exposing lookup. The capability registry model in the UCP manifest supports this granularity: you advertise exactly what you implement, and agents negotiate accordingly.

For merchants already implementing UCP through UCP Hub, this means catalog capability support can be phased. Review the UCP implementation guide for sequencing recommendations based on your current protocol maturity level.

The Multi-Taxonomy Category System: Why It Matters

The new `categories` field upgrade from a single string to an array of `{value, taxonomy}` objects deserves specific attention from catalog architects.

Supporting Multiple Classification Systems Simultaneously

Before this upgrade, UCP required merchants to choose a single category string per product. In practice, merchants operate across multiple classification systems simultaneously. A pair of running shoes might need to be classified as category 187 in Google Product Category for Shopping ads, `aa-8-1` in Shopify’s taxonomy for platform navigation, and “Footwear > Running” in the merchant’s own hierarchy for internal search.

The new schema supports all three in a single response. An AI agent shopping for “running shoes” that uses Google Product Category taxonomy can filter by `187` and get the right result. An agent that uses Shopify taxonomy gets the same product under `aa-8-1`. A merchant’s own internal tool gets it under their hierarchy. No data transformation, no pre-processing, no loss of specificity.

Category Filter Semantics

The search filter accepts `categories` as an array with OR semantics. If an agent sends `[“Footwear”, “Accessories”]`, it receives products matching either category value. This is a deliberate choice aligned with how consumers express multi-category intent: “show me shoes or bags under $200” is an OR query, not an AND query. Merchants populating category data across multiple taxonomies should ensure their category values are consistent with the values agents will use in filter requests, which may require surfacing available categories in documentation or through the search response itself.

Frequently Asked Questions

What is the difference between dev.ucp.shopping.catalog.search and dev.ucp.shopping.catalog.lookup?

They serve fundamentally different discovery intents. Search is for finding products when you do not know the exact identifiers: you have a query (“blue running shoes”), some filters (price under $150, category: Footwear), and you want a ranked list of matches. Lookup is for retrieving specific products or variants when you already have identifiers: product IDs, variant IDs, SKUs, or handles. Search is open-ended exploration; lookup is precise retrieval. The specification supports adopting each independently, so you can implement lookup for ID-based retrieval before committing to full-text search infrastructure.

Can AI agents use catalog search without an authentication token?

The protocol does not mandate OAuth or session authentication for catalog operations, but it does require RFC 9421 request signatures via the `Signature`, `Signature-Input`, and `Content-Digest` headers. These signatures verify the agent’s registered platform identity, not a user’s authenticated session. Merchants may also accept `Authorization: Bearer` tokens and `X-Api-Key` headers, depending on their implementation. The UCP technical architecture guide covers the full authentication model in detail.

How does cursor-based pagination work for catalog search results?

Cursor-based pagination passes an opaque string token between requests to retrieve sequential pages. Your first search request returns a `pagination.cursor` value in the response when `has_next_page` is true. You include that cursor in the `pagination.cursor` field of your next request to get the next page. Cursors are stateless: implementations can encode them as keyset tokens, meaning they do not require server-side session state. The default page size is 10 results; you can request more via `pagination.limit`, but implementations may silently clamp to their own maximum.

What happens when a lookup request includes identifiers that don’t exist?

Not-found identifiers do not cause transport errors. The response returns HTTP 200 with the found products in the `products` array, plus optional informational `messages` entries with code `not_found` and the unresolved identifier as content. If zero identifiers resolve, the response returns HTTP 200 with an empty `products` array and the not-found messages. This graceful partial-success model lets agents handle stale IDs, discontinued products, or cross-merchant identifier mismatches without breaking the agent session.

How does context.language affect catalog responses?

The `language` field in the context object requests localized content using IETF BCP 47 tags (e.g., `”en”`, `”fr-CA”`, `”zh-Hans”`). For REST requests, it overrides the `Accept-Language` header when present. Implementations that support localization should return product titles, descriptions, and other textual fields in the requested language. If the requested language is unavailable, implementations may return content in a fallback language without error. The lookup endpoint example in the specification shows a `language: “es”` request receiving Spanish-language product descriptions, with the `description.plain` field returning localized text.

Can a merchant expose a filter-only catalog search without full-text search support?

Yes. The specification explicitly lists `filters` as a standalone search input alongside `query`. A filter-only request (no `query` field) represents a browse operation where the merchant returns matching products based on category and price criteria without text-relevance ranking. This is explicitly conformant with the specification. Merchants who have structured catalog data with strong category taxonomy but limited search infrastructure can implement the catalog search capability using filter-only requests as their initial deployment, then layer full-text search on top when ready.

How does the unit_price field work for price-per-weight products?

The `unit_price` object on a variant enables per-unit pricing for products sold by weight, volume, or length. It carries four fields: `amount` (the precomputed unit price in ISO 4217 minor units), `currency`, `measure` (the actual product quantity, e.g., `{value: 750, unit: “ml”}`), and `reference` (the display denominator, e.g., `{value: 100, unit: “ml”}`). The merchant must precompute the `amount` value: `(variant.price.amount / measure.value) * reference.value`. For a 750ml bottle priced at $25, the unit price displayed as “per 100ml” would be `(2500 / 750) * 100 = 333` (in USD minor units, so $3.33 per 100ml). AI agents can use this to compare products sold in different package sizes on a normalized price basis.

What is the availability.status field and why was it added?

The `available` boolean field answers the binary question: “can I buy this?” It covers in-stock, backorder, and preorder states without distinguishing between them. The new `status` string field was added to qualify the fulfillment contract: why is it available, and when will it ship? Well-known status values include `in_stock`, `backorder`, `preorder`, `out_of_stock`, and `discontinued`. The key design principle is that `status` qualifies `available`, not the reverse. A merchant can set `available: true` without populating `status` and remain conformant. Agents that do not recognize a `status` value fall back to the boolean. This open vocabulary design means new fulfillment states can be added by implementations without requiring a schema version bump.

UCP Catalog Search and Lookup: How AI Agents Discover Products in 2026