UCP Checker has a new tool: the Location Validator. Give it a store and it calls the store's UCP location search and lookup, up to 13 read-only calls, and checks what comes back against 32 rules from the spec. Or paste a response and it checks what each location carries.
We built it because stores are already shipping location search: thousands of the UCP profiles in our census declared it on 26 October. Until now nothing told a store whether an agent could actually use it.
What is UCP location search?
UCP location search is how an AI agent finds a business's physical places: shops, restaurants, pickup points. It is two capabilities in the shared dev.ucp.common namespace, first published in release 2026-08-25. dev.ucp.common.location.search finds locations by free text, by a radius around a point (distance), by an address or point the location can serve (serves), and by filters for opening time, amenities and items in stock. dev.ucp.common.location.lookup fetches locations by id.
It isn't tied to one vertical. The same capability serves a retailer's stores for pickup, a restaurant's branches and a hotel's properties. Our July explainer covered the proposal; what shipped differs in a few places, and the explainer now carries a note saying which.
What the validator checks
Each call asks the store one question the spec answers exactly:
| Call | What the spec says should happen |
|---|---|
| An empty search | A bounded default page, never an export |
| The next page | The cursor works and no location repeats |
| A word from a shop's name | That shop comes back |
| A 1 km radius around a shop's own coordinates | That shop comes back: its distance is 0 |
| A 1 km radius on the opposite side of the Earth | Nothing comes back, or only places inside it |
| A radius with no center | Refused: the store must not work out a center from context or IP |
| A filter no store supports | Refused, not ignored |
| An amenity no shop has, an item no store sells | Nothing matches |
| An amenity a shop lists | Every shop returned has it |
| Shops open now | Only shops whose own hours say they are open |
| Lookup of an id twice, plus an id that doesn't exist | The shop once, with inputs[] naming the ids; nothing for the unknown id |
| Lookup with a radius that contains a second shop, then half that radius | Kept, then dropped |
On top of that, every location that comes back is checked for what it carries: an id and a name, valid coordinates, amenities as reverse-domain ids with a description a buyer can read, opening hours in the spec's days and 24-hour times, holiday hours that don't overlap, and an IANA time zone whenever there are hours. The response is checked too: the ucp wrapper, locations[], the pagination shape, and over MCP, the answer in structuredContent.
Why a refusal can pass
Several rules pass when the store says no. The spec is explicit that a store which gets a filter it doesn't support "MUST reject the request with an actionable error; it MUST NOT ignore the filter and return broadened results", and a radius without a center is invalid. An agent that sends a filter and gets every shop back has no way to know the filter was dropped.
So the validator sends a filter in our own namespace, com.ucpchecker.probe_unsupported, that no store can support. A refusal passes. A list of every shop fails.
The same logic applies to the amenity and item filters: a store may refuse them if it doesn't support them, but if it accepts them, an amenity nobody has must match nothing.
What we found on the first runs
We ran it on four large retail stores that declare location search, and on our own test store.
The four stores had no failures. Radius search was right in both directions, including the lookup refinement. An unknown item and an unknown id matched nothing. The amenity and open-now filters were refused, which the spec allows for filters a store doesn't support. Answers came back in structuredContent, and the stores refused the filter and the radius without a center, as they should.
One thing to consider: in the four stores we tested, locations came back without opening hours. Each carried an id, a name, an address and coordinates. Without hours, an agent should treat a shop's schedule as unknown and, as the spec asks, not tell a buyer it is open.
Text search matched words in a shop's name or address. A city name that wasn't in the address found nothing. The spec leaves text retrieval to the store, so that is allowed, but an agent that knows where the buyer is should search by distance.
Our own test store failed one rule. Asked for a filter it didn't support, UCP Sandbox's flowers store ignored it and returned all five shops. We fixed it the same day (Sandbox 0.7.7), and it now passes all 32.
One thing for agent builders
A store only offers the location tools to an agent whose UCP profile declares them. Our checker's agent profile declared catalog search and lookup but not location, and the stores answered Tool not found: search_locations. Adding dev.ucp.common.location.search and dev.ucp.common.location.lookup to the profile fixed it. That is capability negotiation working as designed, but the error doesn't say so.
Changes to the profile are not instant either. For up to an hour after ours changed, some calls in a run worked and others still said the tool wasn't there. Our profile is served with max-age=3600. The validator now reports a tool the store didn't offer as not run rather than as a failure.
Try it
Run the Location Validator on a store that declares location search. To see every rule run, use our test store flowers.ucpsandbox.com, which has five shops with hours, amenities and a second time zone. Each call opens to show exactly what was sent and what came back.
FAQ
What is the UCP Location Validator?
A free tool on UCP Checker that tests a store's UCP location search and lookup. It makes up to 13 read-only calls to the store and checks the answers against 32 rules from release 2026-08-25. Nothing is bought, reserved or stored.
Is UCP location search only for restaurants and hotels?
No. It sits in the shared dev.ucp.common namespace and works for any vertical. The stores we have seen declaring it so far are retail stores.
Why does a store say "Tool not found: search_locations"?
A store can offer the location tools only to an agent whose UCP profile declares dev.ucp.common.location.search and dev.ucp.common.location.lookup. Add both to your agent profile. In our testing, the change took up to an hour to reach every server.
Does a store have to support every location filter?
No. A store can refuse a filter it doesn't support, with an actionable error. What it must not do is ignore the filter and return more than was asked for.
Why does the validator say a shop has no opening hours?
Because none came back. Without hours, the schedule is unknown, and the spec says an agent must not infer a shop is open.
How does the validator measure distance?
The spec uses the shortest WGS 84 geodesic. The validator measures great-circle distance, which is within about half a percent of it, and allows for that before calling a shop outside the radius.
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, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.
Sources
- Location Search Capability, UCP specification, release 2026-08-25
- Location Lookup Capability, UCP specification, release 2026-08-25
- Location MCP binding, UCP specification, release 2026-08-25
- UCP Sandbox changelog, 0.7.7, 26 October 2026
Related coverage: What is the UCP Location capability? · UCP v2026-08-25 spec update · How UCP works: a real agent buys flowers