Practice · Choosing protocols4 min readReviewed

UCP, MCP and ACP compared: Choosing protocols for your shop

Stefan Hamann · English
Text

UCP, MCP and ACP perform different tasks in agentic commerce. UCP and ACP describe commerce flows. MCP connects AI applications to data and tools. For merchants, a useful choice follows from the agents they want to reach and the parts of the purchase they intend to support.

Practical planning starts with the customer's request. A traveller needs a suitcase, selects a model and wants it to arrive on time. The agent needs product knowledge, a valid selection, current terms and a path to ordering. Several protocols can work together along that journey.

The role of each protocol

Component Role Purchasing example
UCP Describe commerce capabilities and flows Find products, update a cart and continue a purchase
ACP Enable commerce flows between an agent and a merchant Complete a checkout with the participating provider
MCP Connect AI applications to data and tools Call a product search or quotation tool
AP2 Represent authorisation and evidence for payments Record which payment was permitted under which conditions
A2A Describe collaboration between agents Coordinate a task with a specialist agent

The table maps the roles. Implementation depends on the specification used and the capabilities supported by the other participant. The protocol catalogue links to original sources and documented versions.

UCP: a shared description of commerce

The Universal Commerce Protocol provides building blocks for connections between platforms, agents and businesses. It centres on merchant capabilities and the data a purchase needs. An agent can use it to discover the operations a merchant offers in a defined way.

When planning a shop integration, the supported steps matter: what can the agent discover, how are variants selected, how is the cart updated and how does the customer obtain order status? Our UCP profile brings together specifications, SDKs and integration notes.

MCP: tools for the assistant

The Model Context Protocol connects AI applications to external systems. A merchant might expose product search, a delivery estimate query or access to approved product information as tools. Commerce rules come from the connected systems and the workflows built on them.

An assistant can use such a tool to find the suitcase in the right size. For a binding purchase, the application also needs appropriate permissions and a supported checkout. The MCP profile explains how it connects to other components.

ACP: examine the supported purchasing flow

The Agentic Commerce Protocol focuses on connecting agents and merchants for commerce flows. For a particular integration, check which providers support the flow, how the customer confirms a selection and which information returns to the merchant.

Compare UCP and ACP using the same task. A successfully transferred cart and a completed order are different outcomes. Delivery estimates, taxes, variant changes and handling a failed purchase also belong in the comparison. This makes the protocol choice a decision about the service customers actually receive.

A complete purchase connects several layers

Our suitcase purchase can be divided into four steps:

  1. The agent identifies suitable products and checks dimensions, price and delivery date.
  2. The customer selects the offer and defines what the agent may execute.
  3. The application runs the supported purchasing flow and receives an unambiguous outcome.
  4. Enquiries and changes refer to the same order.

MCP can expose tools for the initial research. UCP or ACP can describe the available commerce flow. Depending on the integration, AP2 can contribute evidence for the authorised payment. Test the actual combination of participating clients, services and versions to establish which arrangement works.

How merchants can make a useful choice

For each planned integration, list the customer environment it reaches, supported tasks, customer access and payment requirements, data needs and operational responsibilities. Then build a complete example purchase and deliberately change its conditions.

Prefer a shared core for product knowledge, prices, inventory and orders. Different access channels can then use the same business rules. An additional agent channel becomes easier to maintain when its terms come from the existing systems.

The merchant preparation guide, acceptance tests and Lab projects support the next step. For the architecture, the linked specifications and their actual capabilities remain the starting point.