Every UCP capability so far has answered what an agent can buy and how it pays. None of them answered where. A proposed capability opened on 24 June fills that gap: a UCP Location capability — geo search, location lookup, and geofencing — that lets an agent find a physical store, restaurant or pickup point, check whether it's open and stocked, and carry that place straight into checkout.

It's the missing "where" primitive for every local vertical — food, lodging, retail pickup — and it's the direct answer to a question we keep getting: how does an agent discover a restaurant that doesn't have its own website? Here's how the proposed UCP location capability works, what the geo and lookup pieces do, and where it sits in the protocol.

#The 30-second version

• UCP is getting a Location capability — two proposed endpoints under the core dev.ucp.common namespace: location.search (geo + natural-language discovery) and location.lookup (resolve full details by ID).
• It handles the "where" of commerce: find nearby stores or restaurants, check operating hours, real-time inventory, and amenities, and verify delivery coverage with a geofence.
• It's vertical-agnostic — the same UCP location search serves retail pickup, food ordering and lodging.
• Search returns a stable location.id that threads into Catalog and Checkout — so "find the nearest store that has this in stock" becomes one continuous flow.
• Status: proposed. It's an open PR (#545), a capability-tier change building on RFC #375. No published schema to validate against yet — but it's the Technical Council's prioritised next step, not a drive-by.

#Why a UCP location capability, and why now

UCP launched retail-native: a catalog, a cart, a checkout. That model assumes the merchant is a website — a stable web origin an agent can discover and crawl. It breaks the moment commerce gets local. A neighbourhood restaurant on a point-of-sale platform, a retail chain's individual branches, a hotel property — these are places, not domains, and the protocol had no first-class way to represent or find them.

This isn't a sudden idea. The thread runs back through RFC #375 (Store-Based Local Inventory & Fulfillment) in April. And it's a stated priority: the UCP Technical Council minutes show local inventory was tabled for a dedicated deep-dive, with Ilya Grigorik tasked to bring a proposal — work that surfaces now as the Location capability. It also lands the same fortnight UCP's expansion went vertical: the proposed food-ordering charter and lodging charter both describe local experiences that need exactly this primitive underneath them.

#The two capabilities: UCP location search and lookup

The design deliberately mirrors UCP's Catalog capability — a search/lookup pair, both declared under dev.ucp.common (the protocol's own reverse-DNS namespace, the same authority the standard shopping capabilities live under).

dev.ucp.common.location.search — discovery. An agent sends a natural-language query and/or structured filters and gets back matching locations. A request must carry at least a query or a filter; a query-less request is a "browse" (filters only, no text ranking). Transport bindings: REST POST /locations/search and an MCP tool.

dev.ucp.common.location.lookup — resolution. An agent sends an array of ids and gets full detail for each (batch of 10+, server de-duplicates, order not guaranteed — the client correlates by the returned id). Optional filters apply after resolution, so "look up these two branches, but only if open_now" drops the closed one.

#UCP geo: distance vs geofence

The geographic model is the heart of it, and it's worth being precise because "UCP geo" really means two different operations:

• distance (proximity search) — "find locations within max_distance metres of this center point." This is the classic store-finder: nearest branches to the buyer.
• geofence (coverage check) — every location can publish a circular geofence_radius around its coordinates representing its service or delivery area. The geofence filter answers a different question: "does this location actually reach the buyer's address?" That's delivery-area verification, not proximity.

Two distinct, industry-agnostic spatial models in one capability — proximity for discovery, geofencing for fulfilment feasibility.

#What a UCP location actually carries

A location is "a physical entity that can be found on a map." Beyond name and address, it carries:

• Operating hours — a weekly schedule plus date-specific exception_hours (holidays, temporary closures), resolved against the location's timezone. Filterable by open_now or open_at (a future time, for ordering ahead).
• Offerings, split into two deliberately:
  • Amenities — static features: free_wifi, parking, curbside_pickup, outdoor_seating, vegetarian.
  • Inventory — dynamic availability of actual goods: products for retail, dishes for food ordering — each filter an {id, type, quantity} so an agent can ask "which branch has this item in stock right now."

That amenities-vs-inventory split is the quiet but important call: it separates "what this place is" from "what this place has right now", which is exactly the line agents need to reason about.

#How it threads into the rest of UCP

This is the part that makes it more than a map API. Location search and lookup return stable, business-scoped location.id values, and those IDs are the join key into the existing flow:

• pass a location.id into Catalog filters to scope products to one branch;
• pass it as selected_destination_id into Checkout to signal pickup.

So the "inventory-based store finder" becomes one continuous journey: filter location search by offerings.inventory to find the nearest place that has the item, then carry that same location.id through to checkout. For food and local retail — where the merchant often has no canonical website, only a place on a map — this is the discovery primitive that was missing.

#The discipline it bakes in: provisional vs authoritative

There's one line in the proposal worth holding onto, because it's a lesson the protocol has learned the hard way. Discovery signals — hours, inventory, amenities — are explicitly provisional, not binding, and the spec says they should not be cached or reused across sessions without re-validation. Final pickup or fulfilment terms must be re-confirmed authoritatively at checkout.

That's the same provisional-vs-authoritative discipline we've watched agents fail on elsewhere: when we tested five frontier models against expiring inventory, none of them re-checked a signal before acting. Writing "re-validate before you commit" into the discovery layer itself is the right instinct — and it's exactly the behaviour an independent check exists to verify once the spec lands.

#What it means for each vertical

• Food ordering — the proposed food charter defers menu discovery to a later phase; the Location capability is how the restaurant itself gets found in the first place, by geo and dish-inventory, with no website required.
• Lodging — the lodging charter starts at checkout; location lookup gives the property a structured, resolvable identity to anchor a booking to.
• Retail pickup — "buy online, pick up in store" needs a store finder that knows hours and per-branch stock. That's location.search with a distance filter and an inventory filter, returning an ID that flows into checkout.

#Status check: this is proposed, not live

To be precise about where it sits: PR #545 is open, a capability-tier change (maintainer approval, not a core-protocol or Technical-Council-gated one), with schemas drafted but no tests yet and nothing merged. There is no dev.ucp.common.location.* capability in the published spec today, and no live endpoint declares it. We track it on our protocol tracker and will validate against it the moment it lands.

#UCP Location capability: FAQ

What is the UCP Location capability? A proposed UCP capability for discovering and resolving physical locations — stores, restaurants, pickup points — via two endpoints, dev.ucp.common.location.search and dev.ucp.common.location.lookup. It adds the "where" of commerce to a protocol that previously only modelled catalog, cart and checkout.

What is UCP geo / geofencing? The location capability's geographic model. distance does proximity ("nearest branches within N metres"); geofence does coverage ("does this location's service radius reach the buyer's address"). Together they cover store-finding and delivery-area verification.

What are UCP locations? Physical places a business exposes to agents — each with a name, address, coordinates, operating hours, amenities and real-time inventory, identified by a stable location.id that other UCP capabilities reference.

Does UCP have a store finder? Not in the published spec yet. The proposed location.search with a distance filter (and optionally an inventory filter) is effectively a standardised, agent-readable store finder.

Is the UCP location capability live? No — it's a proposed open PR (#545), building on RFC #375. No published schema, no live adoption. It's the Technical Council's prioritised next step for local commerce.

What namespace is it under? dev.ucp.common — the protocol's own reverse-DNS namespace, shared across verticals, the same authority as the standard shopping capabilities.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and track the spec as it evolves so you don't have to. When the Location capability ships, a conformance check is exactly what proves a location.id resolves, a geofence is honest, and an "open now" signal is true.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• Track the protocol: ucpchecker.com/protocol-tracker
• Get notified on changes: ucpchecker.com/alerts

#Sources

• The proposal: PR #545 — Introduce Location Search + Lookup capabilities
• Lineage: RFC #375 — Store-Based Local Inventory & Fulfillment Options
• Prioritisation: UCP Technical Council meeting minutes
• Related: What Is a UCP Namespace? · UCP for Food Ordering: the charter · UCP for Lodging: the charter