Which protocol powers AI shopping agents? ACP, UCP, or MCP?

What is the difference between ACP, UCP, and MCP?

The three protocols answer three different questions. ACP defines how an AI agent completes a purchase with a merchant. UCP defines how an agent and a merchant interact across the whole shopping journey, from catalog search to post-purchase support. MCP defines how an AI agent connects to external systems and data, whether in commerce or elsewhere. Because each one specifies a different layer, comparing them as rivals overlooks how they actually combine: UCP’s own specification lists MCP as one of its supported transports, and both commerce protocols depend on the type of system connectivity that MCP standardizes.

ACP (Agentic Commerce Protocol): the checkout standard

The Agentic Commerce Protocol is an open specification for completing purchases between buyers, their AI agents, and sellers. OpenAI and Stripe maintain and open-source it under the Apache 2.0 license; it’s currently in beta.

• Who’s involved: ACP defines four roles: the buyer, the agent that interprets the buyer’s intent, the seller, and the payment provider.
• How a purchase works: The agent renders the checkout interface, creates and manages checkout sessions via a REST API implemented by the seller, and relays payment credentials via delegated payment tokens scoped to the transaction.
• What the merchant keeps: The seller retains its existing back-end systems and payment processing, decides which agents and transactions to accept, and remains the merchant of record throughout.
• What the spec covers: Checkout sessions, capability negotiation between agent and seller, structured payment handlers, and extensions such as discount codes, with date-based versioning.
• Where it runs today: OpenAI is the first AI platform to implement ACP in production. Merchants that implement the spec can transact with ChatGPT users, and OpenAI publishes a product feed specification for making catalog data available to ChatGPT.
• What it doesn’t cover: ACP is a transaction standard, not a discovery or data standard. How your product information becomes complete and accurate enough for an agent to recommend is outside its scope.

UCP (Universal Commerce Protocol): the full-journey standard

The Universal Commerce Protocol is an open standard developed by Google, Shopify, and retail and payments partners. Where ACP specifies checkout, UCP specifies the full commerce interaction between platforms (AI agents, apps) and businesses (merchants, suppliers).

• Built on capabilities: Standalone, independently versioned functions such as checkout, catalog search, identity linking, and order management. Extensions add functionality, such as discounts and fulfillment rules, without changing the core.
• How agents find merchants: A merchant declares its supported capabilities in a profile published at a standardized address on its own domain (/.well-known/ucp). Agents discover that profile and negotiate a session from the intersection of what both sides support.
• Transport-agnostic: A merchant can expose capabilities via REST, MCP, or the Agent2Agent (A2A) protocol, depending on its infrastructure.
• How payments work: Through the Agent Payments Protocol (AP2), an open standard, now governed by the FIDO Alliance, that uses signed payment mandates and verifiable credentials to prove the buyer authorized what the agent is doing. AP2 is one of three payment protocols for AI agent commerce, alongside MPP and x402, that standardize how agents actually pay. 
• What the merchant keeps: The business remains the merchant of record and keeps ownership of its customer relationships.
• Versioning and neutrality: The specification uses date-based versioning, with the current version published at ucp.dev. Google’s developer documentation describes UCP as neutral and vendor-agnostic, designed to power agentic commerce on any surface.

MCP (Model Context Protocol): the connectivity layer underneath

The Model Context Protocol is not a commerce protocol. It is the open standard for connecting AI applications to external data sources and tools, regardless of the systems involved.

• Origin and governance: Anthropic introduced MCP in November 2024 and donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025, where its maintainers govern it as a neutral, community-driven project.
• How it works: A merchant or its software vendor runs an MCP server that exposes systems such as a product catalog, inventory, or order management as tools that an agent can call. Any MCP-compatible agent connects to that server without a custom integration.
• Adoption: The protocol reports first-class client support across ChatGPT, Claude, Gemini, Microsoft Copilot, and other major AI platforms.
• Role in commerce: MCP operates below ACP and UCP. It doesn’t define a checkout flow or a shopping journey; it defines whether an agent can reach your systems and data at all.
• Proof the protocols stack: UCP’s own specification supports MCP as a transport for its shopping capabilities. If your product information systems expose an MCP server, that connectivity works for whichever commerce protocol runs on top of it.

Do you need ACP, UCP, and MCP–or just one?

For most brands and manufacturers, the honest answer is: plan for more than one. Because each protocol standardizes a different layer, they don’t substitute for each other, and no platform accepts a competitor’s integration in place of its own. A merchant that implements only one remains unreachable on the surfaces the others govern.

Supporting several protocols carries real integration demands, and you should plan for them honestly:

• Separate implementations per protocol. ACP requires its REST endpoints, payment token handling, and a structured product feed. UCP requires a hosted capability profile on your domain and live endpoints for each capability you declare. MCP requires a server that exposes your systems as tools. None of this work transfers directly between protocols.
  
• Specifications that keep changing. ACP is in beta, with date-based versions and an evolving set of extensions. UCP versions its capabilities independently and continues to expand coverage. Your integrations require ongoing maintenance, not a one-time build.
  
• Parallel data requirements. Each protocol reads product data through a different interface and format, so every product record must be complete, accurate, and current in multiple forms at once.

One layer you largely don’t have to build: payments. AP2, MPP, and x402 are being standardized industry-wide, with Visa, Mastercard, and Stripe backing open standards and governance bodies, and are implemented by your payment provider and the commerce protocols themselves, not by you. The layers you do own are the ones above: your endpoints and your product data. 

With limited engineering capacity, most teams still have to sequence the work. Choosing between ACP and UCP as your starting point comes down to where your buyers already shop with agents and what your commerce platform supports natively. The data requirement, though, is one you can’t sequence around: every protocol depends on it from day one.

How do you prepare your product data for ACP, UCP, and MCP?

Strip away the differences between the three protocols and one shared assumption remains: the merchant side can produce complete, accurate, machine-readable product data on demand. None of them fixes that data or catches its errors; they only move it. A wrong or incomplete record now fails everywhere at once, so preparation starts with the data, not the endpoints:

1. Consolidate product data from every source it exists in. 

Each protocol assumes your systems can serve complete records on request. That’s only possible when product data from your ERP, PLM, suppliers, and channels is ingested into a single governed platform rather than assembled by hand for each integration.

2. Make every record complete and accurate before an agent reads it. 

Agents act on what the record says. Validation and readiness checks must run within your product data flow, so errors are caught before any protocol endpoint serves them.

3. Keep records current as requirements change. 

Protocol specs, channel requirements, and product data change daily. Readiness is an ongoing operation, and your PIM either supports AI-driven work at this pace, or it doesn’t.

4. Govern what agents read and act on. 

Every AI workflow that touches product data needs verification and validation, so agentic speed never comes at the cost of accuracy.

This is the work Inriver is built for. Inriver’s flexible data model ingests product data from any source, as-is, without the upfront cleaning or ETL project that stalls most readiness efforts before a single endpoint exists. 

Inriver then orchestrates AI agent and LLM workflows with built-in verification and validation, so what an agent reads through ACP, UCP, or MCP is checked against trusted product data before it reaches a buyer. The protocols will keep changing. Product data that agents can trust is the requirement that won’t change.

See how Inriver makes your product data ready for every protocol; book a personalized demo today.