MCP vs UCP vs ACP: The Protocol Landscape, Explained

Ron Reynolds · 2026-02-11 · 8 min read

By Ronald Reynolds, Founder & CEO of ComOS If you've been following agentic commerce, you've seen the alphabet soup: MCP, UCP, ACP, A2A, AP2. Five protocols. Three major backers. One very confused market.

Let me cut through it.

I've been implementing these protocols for the last year — not reading about them, building on them. ComOS Gateway supports MCP and UCP in production today, with ACP and the rest in various stages. Here's what each one actually does, who's behind it, and what it means for your business. The Quick Reference

Before we go deep, here's the landscape at a glance:

MCP (Model Context Protocol) — Anthropic The original. How AI agents interact with external tools and data. Think of it as the HTTP of agentic commerce. Linux Foundation standard as of December 2025. This is the one that matters most right now.

UCP (Unified Commerce Protocol) — Google / Shopify Google's answer to MCP, developed with Shopify. Designed specifically for commerce with a layered architecture. Eight distinct layers covering everything from discovery to fulfillment.

ACP (Agent Commerce Protocol) — Emerging standard Focused on checkout and payment sessions. Where MCP and UCP handle discovery and catalog, ACP is about completing the transaction.

A2A (Agent-to-Agent) — Google How AI agents talk to each other. Not merchant-facing directly, but important for the ecosystem — it's how a customer's agent might negotiate with a merchant's agent.

AP2 (Agent Payment Protocol) — Foundation stage The payment rail for agent transactions. Still early, but it addresses a real gap: how do you handle payment authorization when the buyer is an AI agent, not a human clicking "confirm"? MCP: The Foundation

MCP is where this started, and it's still the protocol that matters most for merchants.

Anthropic released MCP in late 2024 as an open protocol for AI agents to interact with external systems. It wasn't designed specifically for commerce — it's general-purpose. But commerce turned out to be one of its most natural applications, because shopping is fundamentally about tools: search a catalog, check a price, add to cart, complete checkout.

What MCP does well: Clean, standardized tool interface — agents call tools with structured inputs and get structured outputs Session management — agents can maintain context across multiple interactions Discovery — agents can find and connect to MCP servers dynamically Broad adoption — Claude, ChatGPT, and most major AI platforms support MCP

What MCP doesn't do: Commerce-specific semantics — MCP doesn't know what a "product" or "cart" is natively. That's left to the implementation. Payment handling — MCP can trigger a checkout, but the payment flow isn't part of the protocol Agent-to-agent communication — MCP is agent-to-server, not agent-to-agent

ComOS Gateway exposes 126 MCP tools — that's us building the commerce semantics on top of MCP's general framework. When Claude connects to our gateway, it gets tools like searchproducts, addtocart, getshippingoptions, and completecheckout. MCP provides the transport. We provide the commerce meaning.

For merchants: MCP is non-negotiable. It's the most widely adopted protocol, it's a Linux Foundation standard, and it's what most AI agents speak today. If you're only going to support one protocol, this is it. UCP: Google's Commerce-Native Approach

UCP takes a different philosophy. Where MCP is general-purpose (and commerce is built on top), UCP was designed for commerce from day one.

Google and Shopify developed UCP with an eight-layer architecture:

1. Discovery — How agents find merchants and catalogs 2. Catalog — Standardized product data representation 3. Search — Structured query interfaces 4. Cart — Cart management operations 5. Identity — Customer identity and preferences 6. Checkout — Transaction completion 7. Fulfillment — Shipping, tracking, delivery 8. Support — Returns, exchanges, customer service

What UCP does well: Commerce-native design — every layer is purpose-built for shopping Google ecosystem integration — natural fit for Google's AI agents and shopping infrastructure Comprehensive scope — covers the full purchase lifecycle, not just search and buy Strong data standards — product data schemas are well-defined

What UCP doesn't do: General-purpose tool interaction — UCP is commerce-only, so agents need MCP (or something else) for non-shopping tasks Universal adoption — it's newer than MCP and primarily backed by Google/Shopify Independent from platform — the Shopify connection means it's optimized for Shopify's model

ComOS Gateway has UCP in production with 222 unit tests covering all eight layers. When a Google shopping agent connects, it gets the full UCP interface. When Claude connects, it gets MCP. Same merchants, same data, different protocols.

For merchants: UCP matters because Google matters. If you believe Google's AI agents will drive shopping traffic — and they will — UCP visibility is essential. But you shouldn't have to choose. ACP: The Checkout Layer

ACP is narrower in scope but fills a real gap. MCP and UCP handle discovery through checkout initiation well, but the actual payment transaction — the moment money moves — needs its own protocol.

ACP focuses on: Checkout session management Payment method negotiation Authorization flows when the buyer is an AI agent Transaction confirmation and receipts

This is still emerging, but the problem it solves is concrete: when an AI agent says "buy this," who authorizes the payment? How does the merchant know the customer actually approved the purchase? ACP provides the handshake.

For merchants: You don't need to worry about ACP directly. Your commerce infrastructure should handle it. But you should be aware that payment protocols for agent transactions are developing, and your platform needs to stay current. A2A: Agents Talking to Agents

A2A is the most conceptually interesting protocol, even if it's the furthest from direct merchant impact today.

Think about it this way: right now, a customer's agent talks to our gateway, which connects to merchant stores. But what if the merchant also has an agent? What if that agent could negotiate, offer personalized deals, handle complex queries about custom orders?

A2A enables that. It's how a customer's Claude might talk to a merchant's agent to negotiate a bulk discount, check on a custom order, or arrange a complex fulfillment scenario.

For merchants: A2A is future-looking. It matters when you start thinking about having your own AI agent that represents your business. Not critical today. Very important in 18 months. AP2: The Payment Rail

AP2 is the foundation layer for agent payments. It addresses the fundamental question: how do financial transactions work when AI agents are the buyers?

Traditional payment flows assume a human looking at a screen, clicking "pay," maybe entering a CVV. Agent transactions need a different model — pre-authorized spending limits, delegated payment authority, transaction verification without human-in-the-loop.

AP2 is the earliest of these protocols. It's foundational work. But getting payments right for agent commerce is critical, and the fact that this work is happening now tells you where the industry is heading.

For merchants: Like ACP, this is handled by your infrastructure. You should know it exists and ensure your platform tracks it. Why Protocol Fragmentation Is a Feature, Not a Bug

Here's the insight most people miss: having multiple protocols isn't a problem. It's the natural evolution of a maturing ecosystem.

HTTP didn't eliminate FTP or SMTP. TCP/IP didn't eliminate UDP. Different protocols serve different purposes, and a healthy infrastructure supports all of them.

The real question isn't "which protocol wins?" — they all serve different functions. The real question is: who handles the complexity for merchants?

If you're implementing protocols yourself, fragmentation is a nightmare. Five protocols, each evolving independently, each with different semantics and versioning. That's a full-time engineering team just to stay current.

If you're on infrastructure that handles it for you, fragmentation is invisible. You connect once, and your commerce is accessible regardless of which protocol an agent uses.

That's the architectural decision behind ComOS Gateway. We implement every relevant protocol so merchants don't have to. When a new protocol emerges or an existing one updates, we handle it. The merchant's experience doesn't change. The Practical Takeaway

If you're a merchant, here's what you need to know:

1. MCP is essential today. It's the most widely adopted protocol and a Linux Foundation standard. If your store isn't MCP-visible, you're missing the majority of agent traffic.

2. UCP is essential for Google. Google's agents will use UCP. That's a massive channel. You need coverage.

3. ACP, A2A, and AP2 are coming. You don't need to act on them today, but your infrastructure should be tracking them.

4. You shouldn't manage protocols yourself. This is infrastructure work, not merchant work. Choose a platform that handles protocol complexity and lets you focus on your products.

5. Multi-protocol coverage is a competitive advantage. The merchants who are visible to every agent, regardless of protocol, will capture more sales than those locked into one standard.

The protocol landscape will keep evolving. New standards will emerge. Existing ones will update. The merchants who thrive won't be the ones who picked the "right" protocol — they'll be the ones whose infrastructure adapts automatically.

That's what we built ComOS to do.