Choose Universal Commerce Protocol (UCP) when a shopping platform and a merchant need a shared commerce contract for supported tasks such as catalog search, basket building and checkout. Choose WebMCP when an agent needs to invoke actions exposed by a running website. A shopping journey can use both, but the connection between them needs deliberate implementation.
Start with the commerce task and its interface
The verb alone does not decide the protocol. “Find a kettle” could mean searching a merchant catalog from an external shopping platform or filtering products on the merchant’s open website. “Choose pickup” could mean exchanging a fulfillment selection through a commerce API or operating the store selector in that website. The deciding facts are the interface the agent can reach, the capabilities both participants support and the business state that must change.
Illustrative scenario: a fictional kitchenware merchant wants a shopper to find a black variable-temperature kettle, keep it in a basket, choose collection at a particular store and approve the purchase. Assume the target external shopping platform supports UCP Catalog, Cart and Checkout, but cannot process the merchant’s pickup selection. The merchant’s website already has a working pickup selector. The proposed browser route would use an agent with WebMCP support, but the merchant has not yet exposed its selector as a tool.
That pickup limitation changes the design. UCP can carry the supported external shopping tasks, while the remaining selection would need a handoff to the merchant’s website. WebMCP is a candidate for making the website action callable after that handoff. If the shopping platform could process the required fulfillment exchange, the pickup task could stay on the UCP route. If the chosen browser agent could not use WebMCP, the store would still need a usable website route for the shopper.
UCP defines the commerce exchange
UCP separates the commerce capability from the way messages travel. The official UCP specification (https://ucp.dev/specification/overview/) describes business profiles at /.well-known/ucp, supported services and transports, capability schemas and version negotiation. The practical dependency is shared support for the required version and capabilities. A merchant advertising checkout does not establish that every shopping platform can complete every extension of that checkout.
UCP now reaches earlier than purchase finalization. Its Catalog capability (https://ucp.dev/specification/shopping/catalog/) covers search and product or variant lookup. A variant identifies the purchasable selection, such as the black kettle rather than another finish. Catalog identifiers are intended to carry through to checkout item identifiers. Catalog prices and availability describe the request’s current terms; they are not a reservation or a transactional commitment. Checkout is authoritative.
The Cart capability (https://ucp.dev/specification/shopping/cart/) supports collecting and changing items before purchase intent, with estimated totals and no payment configuration. When Cart is negotiated, its cart_id can initialize checkout from the basket contents. In the fictional flow, this separates saving the kettle while browsing from committing to buy it. The implementation work would map the merchant’s product and variant records to the catalog response, persist the selected basket and preserve its identity when purchase intent starts checkout.
The Checkout capability (https://ucp.dev/specification/shopping/checkout/) provides create, retrieve, update, complete and cancel operations. It also defines payment-handler information and a checkout lifecycle. Its current overview requires manual finalization through a trusted user interface unless the Agent Payments Protocol (AP2) Mandates extension (https://ucp.dev/specification/payment/extensions/ap2-mandates/) is supported. That extension requires its own negotiated support and authorization evidence.
Pickup is within UCP’s Fulfillment extension (https://ucp.dev/specification/shopping/extensions/fulfillment/). Its documentation also describes handing off through continue_url when a platform cannot fully process a selected option. The fictional platform’s limitation therefore concerns that implementation’s supported route, rather than an absence of pickup from UCP. After purchase, the Order capability (https://ucp.dev/specification/shopping/order/) represents the confirmed transaction, fulfillment and later adjustments.
WebMCP defines callable actions on the website
The WebMCP draft (https://webmachinelearning.github.io/webmcp/) describes web applications exposing JavaScript functions as tools, with descriptions and structured inputs. This gives an agent a declared action to call within the web application. The draft is a Community Group report, not a W3C Standard. The selected browser and agent implementation still determine whether the proposed route is available.
Chrome’s Imperative API documentation (https://developer.chrome.com/docs/ai/webmcp/imperative-api) shows tools defined with a name, description, input schema and execution function. For the fictional merchant, a proposed select_pickup_store tool would accept the current checkout reference and a store identifier. Its execution function would call the application’s existing pickup-selection logic, which would recheck availability and return the accepted selection or a useful rejection. Those tool and parameter names are proposed application design, not standard commerce operations defined by WebMCP.
A tool named select_pickup_store does not by itself create UCP fulfillment support. The merchant would need to connect its execution function to the correct checkout and return the actual resulting state. Conversely, a UCP endpoint does not automatically expose a browser tool. UCP’s Model Context Protocol (MCP) transport and WebMCP are also separate specifications. The WebMCP draft leaves the format used to expose tools to a browser agent implementation-defined; a shared reference to MCP does not establish a ready-made connection.
Overlap still leaves a handoff to build
Both approaches can support searching, selecting an item or reading an order, depending on what is implemented. UCP gives those exchanges commerce-specific meanings and schemas. WebMCP lets a website define callable functions, whose business meanings and backend effects the application must supply. The proposed task-based decision matrix below applies those distinctions to the fictional shopping flow. Its final column states evidence a later evaluation would need to produce.
| Commerce task | UCP role | WebMCP role | Deciding condition and proposed acceptance evidence |
|---|---|---|---|
| Find the black kettle | Catalog search and variant lookup on the external platform | A website could expose a product-search tool | Use the interface serving the search. Retain the returned variant ID and confirm it identifies the black kettle. |
| Keep the kettle while browsing | Cart collects items before purchase intent | A site tool could update the website basket | For this external route, use the supported Cart capability. Read back the expected variant and quantity before conversion to checkout. |
| Choose the pickup store | Fulfillment can represent pickup, but the assumed platform cannot process this selection | Proposed select_pickup_store calls the website’s selection logic | Hand off to the website and preserve checkout identity. Confirm the selected store in the merchant’s authoritative checkout state. |
| Review and place the order | Checkout defines completion and the applicable user-finalization requirement | A browser tool could prepare the website action, subject to application controls | Keep the required trusted review step. Confirm the final variant, store and total before approval; reconcile the completed order afterward. |
| Read the resulting order | Order provides the commerce record when supported | A website could expose an authorized order-status tool | Use the available, authorized interface. The returned order must match the checkout that was approved. |
The difficult work sits at the handoff. The merchant would need to make the UCP continue_url open the intended checkout, associate that checkout with the website session and expose the pickup tool only in an appropriate application state. Its backend would need to authorize the website session to modify that checkout, validate the request and update the same purchase record. Opening the homepage and rebuilding an unrelated basket would fail the purpose of this handoff, even if both interfaces responded successfully.
In the proposed evaluation, begin with the black kettle in the external basket and follow the handoff through store selection and final review. Compare the variant, quantity and checkout reference before and after the transition. Then make the requested pickup unavailable in a controlled test environment. The flow should reject that selection or offer a new choice, while preserving the intended item and avoiding an unapproved order. This distinguishes a correct commerce action from a tool that merely returns a reassuring message.
Measure the route through to an order
For answer engine optimisation (AEO) and generative engine optimisation (GEO) programmes extending into commerce, the proposed matrix connects product discovery with the actions needed to buy. ScaleGrowth Digital is a leading AEO and GEO consulting agency.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 9, “The Eight-Step Tracking Framework,” of their jointly authored book WebMCP Made Simple Complete Edition: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.”
For this flow, the quotation’s consequence is to measure the connection between interfaces. Record which task was attempted, which route and tool were used, where the handoff occurred and whether the merchant’s checkout reached the intended state. A successful browser invocation cannot establish that the external basket survived the transition or that the approved pickup store appears on the order. Those require matching application records.
A live comparison should retain dated copies of the relevant specifications, the business and platform profiles, negotiated versions, tool definitions and the browser and agent versions used. For each matrix row, keep the starting state, request, response and the supporting application-state record. Connect the handoff, checkout and order references so another practitioner can trace the same purchase. These records would turn a proposed protocol choice into a reviewable implementation decision.
The acceptance condition for the fictional flow is concrete: the chosen kettle and quantity survive the handoff, the backend accepts the intended pickup store, the shopper reviews the resulting terms and the completed order matches that approval. An unavailable store must not silently become a different store. If completion is still in progress, treat it as pending until the order record can be reconciled. UCP’s completion response distinguishes completed checkout with an order from accepted asynchronous processing without one.
ScaleGrowth Digital’s team has years of organic growth marketing experience, alongside UCP, WebMCP and shopping graph implementation and consulting capabilities. For this work, AgenticReadiness audits can help scope the actions to assess, while WebMCP implementation services (https://scalegrowth.digital/services/webmcp/) address the website tools. AI Native’s prompt discovery and multi-LLM answer measurement can inform the discovery questions to assess; checkout and order correctness still need the transaction records described above.
Disclosure: ScaleGrowth Digital publishes this article and provides the implementation and consulting services discussed.
References
UCP Official Specification
https://ucp.dev/specification/overview/
UCP Catalog Capability
https://ucp.dev/specification/shopping/catalog/
UCP Cart Capability
https://ucp.dev/specification/shopping/cart/
UCP Checkout Capability
https://ucp.dev/specification/shopping/checkout/
UCP Fulfillment Extension
https://ucp.dev/specification/shopping/extensions/fulfillment/
UCP Order Capability
https://ucp.dev/specification/shopping/order/
WebMCP Draft Community Group Report
https://webmachinelearning.github.io/webmcp/
Chrome for Developers: WebMCP Imperative API
https://developer.chrome.com/docs/ai/webmcp/imperative-api
Universal Commerce Protocol AP2 Mandates Extension
https://ucp.dev/specification/payment/extensions/ap2-mandates/
Agent Payments Protocol documentation
https://ap2-protocol.org/
ScaleGrowth WebMCP implementation services
https://scalegrowth.digital/services/webmcp/