Agentic Checkout Is Already Live on Half of DTC. We Called the Endpoints.

The agentic commerce conversation is almost entirely about intent: which platforms say they will support which protocol, and when. We went and called the endpoints instead.

Of 58 well-known DTC brands, 31 — 53% — serve a live Universal Commerce Protocol discovery document, and every one of those 31 answers a Model Context Protocol request with 13 working checkout tools. An AI agent can transact with over half this sample today. Most of those brands did not build it and, as far as we can tell, do not know it is there.

What is actually live

Two requests establish it, and you can repeat both in a terminal right now against any of the brands in our published dataset.

curl -s https://kosas.com/.well-known/ucp

curl -s -X POST https://kosas.com/api/ucp/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The first returns a UCP merchant profile: version 2026-04-08, declared services, capabilities including dev.ucp.shopping.checkout and dev.ucp.shopping.fulfillment, and registered payment handlers — Google Pay with a per-merchant merchant ID, plus Shopify card and Shop Pay handlers.

The second returns 13 tools with full JSON schemas, covering the complete checkout lifecycle:

• create_checkout
• update_checkout
• complete_checkout
• cancel_checkout
• get_checkout
• get_cart

Identical version, identical tool count, identical handler set across all 31. This is one platform’s deployment rather than 31 independent integrations — every store we platform-checked among them runs Shopify.

It is not quite universal, though, and the exceptions are informative. Two Shopify stores in our sample — Vuori and Baggu — serve Shopify assets but return 404 on /.well-known/ucp. Both look like custom or headless front-ends: Vuori also publishes a hand-written llms.txt rather than the generated one, and Baggu publishes none at all. The likely explanation is not that the platform withheld the capability but that a bespoke front-end at the customer domain never proxies the paths Shopify serves automatically.

Which is its own lesson for anyone who has gone headless: your platform may have shipped an agent commerce API on your behalf, and your own front-end may be the thing hiding it.

The full tool surface

We have not seen this documented anywhere, so here it is in full. It is not a checkout bolt-on — it is a complete commerce API, from catalog search through to order retrieval.

Two details worth noticing. search_catalog means an agent does not need to crawl or parse a storefront at all — it can query the catalog directly, which is a different and far more reliable path than reading a product page. And get_order extends the surface past the purchase into post-purchase support, which is where a lot of agent value actually sits.

Every tool takes a meta argument and carries a full JSON schema, and prices are returned as integer minor units with a currency code — the schema notes explicitly warn an agent to convert before quoting a price to a buyer. That level of detail is not what a specification stub looks like.

The merchants did not do this

We found it by accident. We had been measuring llms.txt adoption and dismissed the Shopify-generated file as boilerplate describing a generic store. Reading it properly, it is a protocol handshake: it names the UCP endpoints, sets out a six-step agent flow from discovery to completed checkout, and states a hard rule that payment requires contemporaneous buyer approval.

So the llms.txt is not really an adoption statistic. It is where the platform announces to agents what it has already switched on for its merchants.

Which means the interesting question for a brand on Shopify is not “should we get agent-ready”. It is whether anyone internally knows that agents can already create and complete a checkout against their store, and whether the operational assumptions behind that — inventory accuracy, payment approval, refund handling for agent-placed orders — have been examined by a human.

The 27 that do not have it

We tried to identify what each of them runs. Fifteen refused our request outright, so their platform is unknown — which is itself consistent with the edge-blocking pattern we found in an earlier study. Of the twelve that answered: three are Adobe Commerce (Peloton, Purple, Blue Apron), one Salesforce Commerce Cloud (quip), one a custom Next.js front-end (Misfits Market), two the Shopify headless cases above, and five we could not classify.

So the honest version is narrower than “everyone else is behind”. We can say with confidence that one platform has shipped this broadly and that Adobe Commerce and Salesforce stores in our sample had not, on this date. We cannot say what those vendors support in general, because three stores is not a platform assessment.

What it does show is where the capability came from: a platform default rather than a project anyone prioritised. That is not a criticism of the brands without it.

It also explains why platform comparisons in this category are so unsatisfying. A listicle grading platforms on “native UCP support” is measuring something one vendor shipped to its entire base at once, which is a very different achievement from a merchant implementing a protocol deliberately.

It will not talk to just anyone

We tried calling search_catalog to see what an agent actually gets back. It refused:

{"error":{"code":-32001,"message":"UCP discovery failed",
  "data":{"code":"invalid_profile_url",
          "content":"Unable to fetch agent profile: Missing profile uri"}}}

Listing the tools is open; calling them is not. The server wants the calling agent to present its own resolvable UCP profile before it will answer — an identity handshake in both directions, not just merchant discovery.

This is worth knowing for two reasons. It qualifies the headline: an agent can transact with these stores, but an anonymous script cannot, and anyone reading “live API” as “open endpoint” would be wrong. And it is a more considered design than the breathless version of this story would suggest — a checkout API reachable by any unidentified caller would be an abuse surface, and this one is not.

So what we have verified is precise: discovery is live and public, the tool surface is real and fully schema’d, and execution is gated on agent identity. We did not build a conformant agent profile to test the transacting path, and we did not attempt a purchase on anyone’s store.

What this does not say

We verified that the endpoints exist and respond. We did not attempt to complete a purchase, and nothing here should be read as a claim about how well the flow works end to end, how agents currently discover these endpoints, or how much volume moves through them. Answering a tools/list request is a low bar; it is simply a much higher bar than a press release, which is what most claims in this space rest on.

The sample is 58 well-known US DTC brands, chosen for recognisability rather than at random, and it skews to Shopify — which is precisely the platform this finding is about, so the 53% should be read as a statement about this sample and not about ecommerce. A sample of enterprise retailers would show a far lower number.

All figures, per brand, are in the DTC AI crawler index, collected 14 August 2026 and free to cite with attribution. If you want to know whether an agent can read your own store, our free checker runs the readability half.