Shopping with an agent has had a speed problem. "Shopping with an agent shouldn't feel like watching paint dry," as Gil Greenberg of Shopify put it when he announced the fix.

On 28 September Shopify launched WebMCP support for checkout, including Shop Pay, for all eligible Shopify merchants. A browser agent can now read the checkout, update it and place the order with the buyer's permission, through four tools registered on eligible checkouts: get_checkout, update_checkout, complete_checkout and navigate_to_storefront. In Shopify's own test, WebMCP completed 60 of 60 checkout attempts in 10.3 seconds each, against 56 of 60 and 27.4 seconds for an agent driving the page like a person would.

It is a good launch, and it came with something just as useful: a recommendation.

#Shopify's recommendation: two routes, one protocol

Both routes lead to the same Universal Commerce Protocol checkout. In Shopify's words, "Checkout WebMCP and Checkout MCP share the checkout object, statuses, and messages." They are two ways into the same protocol:

• Server to server. The agent never opens a page. It calls the store's hosted MCP endpoints directly. Shopify's advice: "If your agent can run on a server, then use Checkout MCP."
• In the browser. "Use Checkout WebMCP when your agent runs in the buyer's browser." The agent uses the tools the storefront and checkout register, rather than clicking through pages built for people.

Because both routes share one checkout, an agent could build a checkout on the server and move into the browser when the buyer needs to review or verify something.

For a merchant, that recommendation turns a technical choice into a business question: which route will the agents that matter to me use, and what happens at my store when they do?

#Speed is the first difference

Shopify's own numbers show why the route matters. Against an agent driving the checkout page like a person, its WebMCP tools were 2.7 times as fast and succeeded every time, at 58% lower cost. Read them for what they are: ten checkout tasks on two of Shopify's test shops, one model, page setup time left out. Search Engine Journal also noted that one total in the post doesn't add up to the 60 attempts. The direction is still clear. The server route goes further: no page to load, no browser to orchestrate.

The browser route also depends on the browser. WebMCP is a W3C Community Group draft, not yet a web standard. Chrome runs it as an origin trial, Firefox is neutral and Safari's engine team has opposed it.

#The route is only the first variable

Speed is the visible difference. The less visible one is that the model and the store change what the agent actually does, whichever route it takes.

The model. Each shopping agent runs on its own model. Google's AI Mode is built on Gemini. Meta's Muse runs on Meta's own Muse Spark. ChatGPT's desktop app now calls the tools a page registers by default: OpenAI calls them site tools, "ChatGPT's implementation of the proposed WebMCP standard." Models differ in ways that matter on a real store. In one of our checks a newer model put the search terms in the wrong field of a UCP catalogue request. The store returned its default listing. The agent then chose from the wrong shelf. The previous model, on the same store and the same task, found the item first time. Nothing on the store had changed.

The store's own instructions. Tools carry instructions as well as data. On Shopify's storefront tools, the reply to adding an item to the cart ends by telling the agent to respond to the user. Some models treat that as the end of the task and stop at the cart, before checkout. Others carry on. Same store, same tool, different agent, different outcome.

The store's data. Search terms, variants and stock answers are read by every agent on every route. When a catalogue search misses an exact item, or a checkout reports a product out of stock that the page still sells, every agent that meets it fails the same way, whichever model it runs.

As the number of agents grows, this multiplies. A store will not be reached by one agent but by many, each with its own model and its own habits, over whichever route its runtime prefers. Knowing that a store "supports UCP" will matter less than knowing how each of those agents actually gets on there.

#What travels with each route

There is one more difference between the routes, and for payments it may matter most.

WebMCP is a way for a web page to offer tools to an agent in the browser. It inherits everything else from the buyer's session: the spec itself notes that tools run with the user's existing cookies and session, so they can make purchases without further checks. That is why it defines a consequentialHint, a flag a site can set so agents ask the person before a step that spends money. On Shopify, the agent must "show the buyer the current order and total, and get their permission" before calling complete_checkout, and "if checkout needs other buyer action, such as a payment challenge, then the buyer finishes it on the checkout page." To the store, the agent is acting inside a person's session.

The server route can carry more of that itself. UCP's latest release (v2026-08-25) adds much of it:

• Payment: 3D Secure authentication, card numbers and network tokens as distinct credentials, split payments across instruments, and deferred payments, deposits and instalment schedules.
• Identity: account linking with scopes tied to capabilities, and delegated identity providers.
• Agent identity: interoperability with Web Bot Auth, so one agent signature can serve both.
• Attribution: platform referral and ad attribution context, so a store can see which platform sent a sale.

On the browser route the agent borrows the buyer's identity. On the server route it can arrive as itself, carrying its own signature, the payment credential and the record of where the sale came from. For merchants, payment networks and anyone who needs to know who an agent is before it pays, that is the difference that lasts.

#What a store can do now

• Know which routes your store offers. On Shopify, a store can now be reached both ways: a UCP endpoint for agents on servers, and WebMCP tools on the storefront and, where eligible, the checkout. Whether an agent gets through is a separate question, and it has a store-specific answer.
• Fix what every agent reads. Clean search terms, variants that say which option they are, and stock answers that match the page help every agent on both routes.
• Watch the agents, not just the protocol. The number of agents, models and routes will keep growing. The useful question is not "do I support UCP?" but "what happens when each of them arrives?"

#Try both routes in UCP Playground

We have updated UCP Playground to support WebMCP, so you can test both routes on your own store side by side. The release is covered in full in Shop through the store page: WebMCP runs in Playground 0.22.0.

• Pick the route. On the Agent page, choose how the agent connects: UCP over MCP, UCP over REST, or the WebMCP tools your store's pages register. Routes your store doesn't offer show as unavailable.
• Run a real task. Send an agent shopping through your page's WebMCP tools, in a browser on our side. It shows the page it opened and the checkout it reached, with screenshots in the replay.
• See what your page offers. The Inspector lists the WebMCP tools your storefront registers, with findings, beside your UCP tools, and can run the read-only ones.

Run the same task both ways and you see the difference this post is about: how far each route gets, how long it takes, which product the agent picks and what it tells the shopper.

Built with guardrails. Store-page runs need a free Playground account and are capped at 10 a day per account. The agent never runs a tool that pays or places an order, and it stops once it reaches the checkout, so no purchase can happen. Our browser identifies itself as UCP Playground on every request and can't reach private networks. It's a tool for testing your own store; please don't point it at sites you don't run.

#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

• TechCrunch — Shopify opens checkout to browser-based AI agents (28 September 2026)
• Gil on X — WebMCP checkout launch (28 September 2026)
• Shopify developer docs — Checkout WebMCP
• UCP v2026-08-25 release notes (GitHub)
• WebMCP draft specification (W3C Web Machine Learning Community Group)
• OpenAI — Using site tools in the ChatGPT desktop app
• Search Engine Journal — Shopify extends WebMCP into checkout for browser agents
• The Paypers — Shopify lets AI agents complete checkout via WebMCP
• VentureBeat — Meta launches proprietary model Muse Spark
• 9to5Google — Gemini app and AI Mode adding product checkout
• Related coverage: Shop through the store page: WebMCP runs in Playground 0.22.0 · Agent identity in UCP: Web Bot Auth interop · The v2026-08-25 spec update · What shopping agents do when the store misbehaves · The State of Agentic Commerce — September 2026