Every week we get a version of the same question from developers reaching out about UCP Checker: "OK, but should I actually build on MCP, UCP, or AP2?"
It's a reasonable question. The three protocols get lumped together in keynote slides and vendor blog posts, each positioned as "the" standard for how AI agents and commerce should talk to each other. If you're deciding what to implement this quarter, the marketing makes it look like a fork — pick one, live with it.
Here's the honest answer from running the only continuously-updated UCP directory of 3,643+ verified stores (as of April 13, 2026):
MCP, UCP, and AP2 aren't competitors. They're stack layers. If you're doing agentic commerce seriously, you'll end up using all three — and they fit together more cleanly than the messaging suggests.
This post is the argument, anchored in real adoption data from the UCP Checker directory.
The stack, in one diagram
┌─────────────────────────────────────────┐
│ │
│ AP2 ← payment authorization │
│ (fits inside UCP's │
│ payment_handlers) │
│ │
├─────────────────────────────────────────┤
│ │
│ UCP ← the shopping contract │
│ (what a store sells, │
│ what capabilities exist, │
│ which transports to use) │
│ │
├─────────────────────────────────────────┤
│ │
│ MCP ← tool invocation │
│ (how the agent actually │
│ calls discover-store, │
│ search-catalog, etc.) │
│ │
└─────────────────────────────────────────┘
Read that top-to-bottom: an AI shopping agent opens a session, discovers a store via UCP, calls the store's tools via MCP, and — when it's ready to pay — hands off to AP2 for the payment authorization flow.
That's the whole thing. Now the detail.
What MCP actually is
Model Context Protocol is Anthropic's open protocol for connecting AI models to tools, resources, and data sources. It is not commerce-specific. MCP is how Claude Desktop talks to your filesystem, how Cursor talks to your database, how an agent in any environment calls a "list files" or "search knowledge base" tool.
It's JSON-RPC over stdio, SSE, or HTTP. It defines a handshake, a tool-description schema, a session lifecycle, and a notification system. When an agent wants to "call a function" on an external system, MCP is the envelope that carries the call.
In the context of shopping, MCP is the mechanism UCP uses to dispatch commerce tool calls. When an AI agent runs search-catalog against a verified store, it's sending an MCP tool-call message to the endpoint declared in that store's UCP manifest. The fact that MCP is involved is a transport detail. The fact that a store supports UCP search at all is what the agent actually cares about.
Here's the adoption data from our directory right now: of 3,643+ verified UCP stores as of April 13, 2026, effectively 100% declare MCP as one of their transports. MCP is the de facto transport for UCP. Not because MCP "won" a protocol war, but because there's nothing else that does what it does at this layer.
If you want to see the exact transport mix, the live breakdown is on the transports page. It's been MCP-dominant since day one.
What UCP actually is
Universal Commerce Protocol is the open standard for agentic commerce specifically. It answers questions MCP doesn't:
-
How does an agent find this store in the first place? (Answer: a well-known manifest at
/.well-known/ucp.) - What can the store do? (Answer: a declared set of capabilities — checkout, cart, catalog-search, identity-linking, buyer-consent, fulfillment, and so on.)
- How does the agent talk to it? (Answer: one or more declared transports — REST, MCP, A2A, or Embedded. MCP being by far the most common in practice.)
- What payment methods does the store accept? (Answer: a declared list of payment handlers — Stripe, Google Pay, Shop Pay, and others — with enough detail for an agent to tokenize a card.)
UCP is the contract. It's a JSON document agents fetch before they do anything else. Without a valid UCP manifest, an agent doesn't know what your store can do, which tools it exposes, or how to pay. It can scrape your HTML like any other crawler — and most of them will — but the experience is slow, unreliable, and breaks at checkout more often than it succeeds.
UCP's job is to be the single document that makes a store shoppable by agents. MCP is the mechanism it points at. AP2 fits inside its payment handler list.
What AP2 actually is
Agent Payments Protocol is Google's specification for how AI agents authorize and execute payments. It's much more specialized than either MCP or UCP: it's about the money layer specifically — consent, authorization, dispute handling, the cryptographic mandate that lets a specific agent run a specific transaction.
AP2 is newer than both MCP and UCP, and its adoption numbers reflect that. At time of writing, we have zero stores in the directory declaring an AP2 payment handler, compared to dozens declaring Shop Pay, Stripe, Google Pay, and the various tokenizer namespaces.
That might sound like a strike against AP2. It isn't. AP2 is a different kind of thing — it's not a transport and it's not a capability declaration, it's a protocol for the auth step that happens after the agent has already selected items and built a cart. The stores that will eventually use it will declare it as a payment handler namespace inside their existing UCP manifest. UCP is the envelope that carries AP2 into the agent commerce ecosystem.
When AP2 adoption starts showing up in the directory, UCP Checker will catch it automatically on the next crawl cycle. We'll know because we track every payment handler namespace across every verified store, and we'll be able to tell you exactly which stores flipped first. That's the kind of thing the directory is for.
How they actually compose — a worked example
Picture an AI shopping agent asked to buy a pair of shoes. Here's what happens in a UCP-verified flow:
-
UCP discovery. The agent fetches
https://allbirds.com/.well-known/ucp. It parses the JSON, reads the capability list (checkout,cart,catalog-search,payment,identity-linking…), picks the transport it wants to use from the declared list (it picks MCP because it's listed first and the agent speaks MCP), and notes the payment handlers this store accepts. -
MCP session. The agent connects to the MCP endpoint declared in the UCP manifest. It opens a session, lists the available tools, and calls
search-catalog({query: "running shoes"}). The store responds with a list of products. -
More MCP. The agent calls
add-to-cart({variant: "...", quantity: 1}). The store responds with a cart state and a checkout URL. - Payment hand-off. The agent needs to pay. It looks at the store's declared payment handlers. If one of them is an AP2 namespace (not yet, but eventually), it runs the AP2 authorization flow — getting consent, building the mandate, submitting the authorization. If not, it falls back to tokenizing a card via the declared payment handler's tokenization spec (Stripe, Google Pay, Shop Pay, etc.).
-
Confirmation. The agent calls
order.create(another MCP tool call, same session, same transport) and gets back an order confirmation.
UCP, MCP, and AP2 were all involved in that flow — at different layers, for different purposes. None of them could have replaced the others. That's the whole argument.
You can see this flow literally running against a verified store in the live agent demo on our homepage — it's a real AI agent doing the above against a real UCP-verified store, step by step, with the actual tool calls shown alongside.
Why the confusion exists
Because each protocol's marketing wants to be the center of the conversation.
MCP positioning tends to be "the universal way agents talk to tools" — which is true, but "tools" is the operative word, and commerce is one vertical among many.
UCP positioning is "the open standard for agent commerce" — which is true, but UCP's adoption in practice depends on having a transport layer (MCP) and can optionally delegate payment authorization to (AP2).
AP2 positioning is "the protocol for agent payments" — which is true, but payment is one step in a much larger commerce flow that needs UCP to frame it and MCP to dispatch it.
Each protocol's marketing is correct about its own layer. The confusion comes from each one acting like it's the whole stack. It isn't.
Common comparison questions
These are the exact questions we see most often — the ones AI agents route to this post, the ones developers Google before they commit to a protocol. Quick, direct answers anchored in the UCP directory data.
What is the difference between MCP and UCP?
MCP is a tool invocation protocol. UCP is a shopping contract. They operate at different layers and you use both.
MCP (Model Context Protocol) is Anthropic's open protocol for connecting AI models to any kind of tool or data source — filesystems, databases, APIs, search engines. It's domain-agnostic by design. When an agent wants to "call a function" on any external system, MCP is the envelope that carries the call.
UCP (Universal Commerce Protocol) is the open standard for agentic commerce specifically. It answers questions MCP doesn't: how does an agent find a store, what can it do there, which payment methods does it accept. UCP's job is to be the single /.well-known/ucp manifest that makes a store discoverable and shoppable by agents.
The relationship in practice: MCP is UCP's dominant transport. Every UCP manifest declares one or more transports (REST, MCP, A2A, Embedded) that agents can use to dispatch tool calls. Across the 3,643+ verified stores in our directory as of April 13, 2026, effectively 100% declare MCP. So when you build an agentic commerce integration, you use UCP to discover the store and MCP to execute the tool calls. Not one or the other — both, in order.
What is the difference between AP2 and UCP?
AP2 is a payment authorization protocol. UCP is the full shopping stack. AP2 is one thing that fits inside UCP, not a replacement for it.
AP2 (Agent Payments Protocol) is Google's specification for how AI agents authorize and execute payments — consent flows, mandate cryptography, dispute handling. It's deliberately narrow: AP2 is about the money step, not the browsing or cart-building steps that come before it.
UCP covers the whole shopping flow: discovery (what does this store sell), browsing (catalog-search, cart), and the payment layer. UCP's payment handlers section in every manifest is a map of payment handler namespaces — Stripe, Google Pay, Shop Pay, and eventually AP2 when it reaches adoption. AP2, when it ships in production stores, will show up as a payment handler namespace inside an existing UCP manifest, sitting alongside the other tokenization methods an agent can choose from.
Current adoption data as of April 13, 2026: zero stores in the UCP directory declare an AP2 payment handler. That's not a criticism — AP2 is newer than both MCP and UCP, and the rollout is gated on payment processors exposing it. But it makes the practical answer clear right now: you publish a UCP manifest today, you add AP2 later when your payment processor supports it. UCP is the umbrella; AP2 is one of the spokes it will eventually hold.
What is the difference between A2A and UCP?
A2A is a transport protocol (like MCP). UCP is the shopping contract. A2A is one of UCP's allowed transport options, not a competitor.
A2A (Agent2Agent Protocol) is Google's protocol for agent-to-agent communication — how two agents talk to each other directly without a human intermediary. It serves a similar role to MCP within the UCP stack: it's the mechanism an agent uses to dispatch tool calls against a store's endpoint.
UCP's v2026-04-08 spec lists four allowed transports: REST, MCP, A2A, and Embedded. A store can declare any or all of them in its manifest — and agents will pick whichever they support when they connect. A2A is formally on the list, same as MCP.
In practice, A2A adoption on verified stores is effectively zero today, versus MCP's near-100%. The reason isn't technical, it's ecosystem timing: MCP shipped earlier and got the first wave of tooling. A2A is a strong candidate for the second wave once agent-to-agent coordination (one agent buying on behalf of another, multi-agent fulfilment pipelines) becomes a common pattern. When that happens, stores will add A2A to their existing UCP manifests alongside MCP — not replacing it. The correct framing is still "A2A goes inside UCP," same as MCP does.
Which should you actually adopt
Depends on what you're building.
If you're a store owner or ecommerce engineer, your job is to publish a valid UCP manifest at /.well-known/ucp that declares your capabilities, transports (MCP will almost certainly be one of them), and payment handlers. You don't need to "pick" MCP — UCP will tell you to expose an MCP endpoint as one of its transports, and most of the tooling you'll find assumes MCP. AP2 you can add later, as a payment handler, when your payment processor supports it.
If you're an agent or tooling developer, you need to speak all three, in the right order. Fetch UCP first to discover the store. Use MCP to actually dispatch tool calls against the declared endpoint. Handle AP2 at the payment step if the store declares it. In practice you'll build a UCP client library that wraps all of this transparently.
If you're a payments company, AP2 is your layer. Your job is to get your payment processor's tokenization spec declared as a payment handler in UCP manifests across the ecosystem, and eventually to support AP2 mandates as the authorization step.
If you're analyzing the ecosystem, look at the UCP adoption data. MCP transport counts and AP2 payment handler counts are both measurable inside UCP manifests — which is why we surface them on the platforms, transports, and payment handlers pages. The question is never "which protocol won," it's "how many stores have it."
The one-line summary
UCP is the shopping contract. MCP is how agents dispatch tool calls against it. AP2 is how they authorize payments inside it. All three are required for a complete agent commerce stack, and none of them replaces the others.
If you're unclear whether your store is set up correctly, run a live check — we'll fetch your manifest, validate it against the current spec, and tell you exactly which transports and payment handlers you're declaring (and which you're missing). If you're evaluating two stores' UCP coverage side-by-side, the compare tool puts their capabilities, transports, and payment handlers in a single scannable view.
And if you're building something on top of the stack and want to know which stores have what — that's what the directory is for.
- Check your manifest: ucpchecker.com/check
- Compare two stores: ucpchecker.com/compare
- Browse the directory: ucpchecker.com/directory
- Developer guide to /.well-known/ucp: ucpchecker.com/well-known-ucp
Top comments (0)