The UCP manifest at /.well-known/ucp, explained for merchants

The Universal Commerce Protocol starts with discovery: before an agent platform can check out on a store, it needs to know what the store supports. The UCP specification at ucp.dev answers that with a single file, the business profile, published at /.well-known/ucp on the store’s domain.

Google’s merchant guide, last updated in October 2026, says the file must be publicly accessible and not require any authentication, and that it shares the public keys used to verify messages sent from the merchant’s server.

What is in it

The specification at ucp.dev, as of 13 October 2026, defines these parts:

• A version. UCP versions are dates in the form year, month, day, and the platform picks one exact version from those the business advertises.
• Services. Each keyed by a reverse domain name, with a transport and an endpoint. The transports the specification defines are REST, MCP, A2A and embedded.
• Capabilities. Named in the same reverse domain style, so the checkout capability is dev.ucp.shopping.checkout. The dev.ucp namespace is reserved for the UCP governing body, and vendors add their own under their own domains.
• Payment handlers. Required even when the list is empty. Google’s guide gives Google Pay as the example.
• Signing keys. A set of public keys in JWK format, used to verify signatures on messages from the business.

How an agent uses it

The platform identifies itself on each request with its own profile address, sent in a UCP-Agent header over HTTP. The business then works out the active capabilities: for every capability both sides support, it takes the highest version both understand, and drops any extension whose parent capability is not active.

The consequence for a merchant is that the file is a promise. Every capability it lists is something an agent will try to use, against the endpoint it names. A capability advertised and not implemented is a stall the store wrote for itself.

What Google asks for around it

Google’s merchant guide for going live on AI Mode and Gemini, as of 13 October 2026, sets out these steps:

1. Prepare Merchant Center: shipping, returns and a product feed, then join the waitlist.
2. Publish the UCP profile.
3. Secure the API endpoints the profile points at.
4. Choose a path: native checkout, which also needs the Google Pay payment handler and order updates after purchase, or the cart path, which moves the shopper’s cart from Google to your own website.
5. Optionally add identity linking over OAuth 2.0, and promo codes and discounts.

The guide also says UCP is an evolving standard and that not all features defined in the specification are available on Google’s surfaces, so the manifest describes what you support, not what Google will use.

If you are on a hosted platform

The platform implements the services, so the platform is the right party to publish the file. Find out whether it does before anything else: see how to tell which protocol your platform supports.

The failure that is yours either way

A manifest that a bot challenge hides is a manifest no agent can read. The well known path has to be reachable by automated clients, which is exactly the traffic a strict bot wall turns away. Check it from outside your network, not from a browser that has already passed the challenge. Agent view does that check for you: it requests the file the way an agent does and says whether a manifest is published and whether it matches the specification. A published file that does not is an unreadable UCP manifest.

For how UCP relates to ACP, AP2 and MCP, see ACP, UCP, AP2 and MCP explained, and for the wider implementation picture, implementing the Universal Commerce Protocol.