MCP, ACP and UCP: what the agentic commerce protocol landscape actually looks like

In under a year, “how does an AI agent buy something” went from an open question to a standards race. There are now three acronyms worth knowing — MCP, ACP and UCP — and they are not competing for the same job, which is the part most explainers get wrong.

Here is the short version, and then the detail. MCP is how an agent calls tools. ACP is how an agent completes a checkout. UCP is Google’s attempt at a standard covering the whole shopping journey. You can implement one, two, or all three, and plenty of stores will end up doing exactly that.

MCP — Model Context Protocol

Who: Anthropic. Scope: tool discovery and tool calling, for any domain — not commerce-specific.

An MCP server advertises a list of tools, each with a name, a description and a typed schema. An agent connects, reads the list, and calls what it needs. That is the whole shape of it. It is not a payments standard and never claimed to be; it is the generic plumbing by which a model takes actions against a system.

For a store, that maps cleanly onto search, cart, order lookup, returns, and — on the merchant side — pricing and catalog operations. We have written at length about what MCP looks like for an e-commerce store, including the trust boundaries that matter when the caller is a program rather than a person.

ACP — Agentic Commerce Protocol

Who: OpenAI and Stripe, published September 2025 under Apache 2.0. Scope: the checkout session, specifically.

ACP standardises the exchange in which an agent says, in effect, “my user wants this item, shipped here, and here is a payment token,” and the merchant’s system answers with pricing, tax, shipping options and an order confirmation — without the buyer leaving the agent’s interface. Crucially, the merchant stays the system of record for the order, payments, tax and compliance. The agent is a client, not a custodian.

It is deliberately narrow, and that narrowness is a feature: checkout is the step where getting it wrong costs actual money. Because the spec is open, a business can implement ACP without processing payments through Stripe. OpenAI’s implementation is what powers checkout inside ChatGPT, which is the practical reason most merchants have heard of it at all.

UCP — Universal Commerce Protocol

Who: Google, launched January 2026, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed by a long list of payment and retail names. Scope: the entire shopping journey — discovery, carts, checkout, payments, order status, post-purchase.

UCP is the most ambitious of the three, and the most obviously strategic: it is the standard behind commerce experiences in Google AI Mode and Gemini. Where ACP draws a tight box around checkout, UCP tries to standardise the whole programmatic conversation between an agent and a merchant backend.

The detail worth noticing, if you are choosing what to build: UCP is specified to carry that exchange over existing transports — API, MCP, or A2A — rather than replacing them, and it is documented as compatible with A2A, the Agent Payments Protocol (AP2) and MCP. The protocols are layering, not purely fighting.

So which one do you need?

Honest answer: it depends who you expect to be selling to, and right now nobody credibly knows how that shakes out.

• If you want your own agents, copilots and internal automation to drive the store — MCP, because it is the generic tool layer and is not tied to any one storefront ecosystem.
• If you want to sell inside ChatGPT — ACP is the path, because that is what OpenAI’s checkout runs on.
• If you want to sell inside Google AI Mode or Gemini — UCP, for the same reason in reverse.

Notice that two of the three are, functionally, distribution deals dressed as specifications. That is not a criticism — open specs are genuinely better than proprietary integrations — but it is worth seeing clearly. Adopting ACP or UCP is partly a technical decision and mostly a decision about which storefront-of-the-future you want to appear in.

What Wardenclyffe implements today

MCP. Not ACP, and not UCP.

The Wardenclyffe AI Engine exposes two MCP endpoints — /mcp/customer for buyer agents and /mcp/admin for merchant agents — over a single tool registry, sharing the same authentication, RBAC, audit log and idempotency keys as the human UI. That is the whole of our agent surface, and we would rather say so plainly than imply a compliance badge we have not earned.

Two honest observations about that position, one favourable and one not:

In our favour: because UCP is specified to travel over MCP among other transports, an engine that is already MCP-native starts closer to that road than one exposing only a bespoke REST API. That is an observation about the spec, not a claim of support — we have not implemented UCP and you should not plan around it.

Against us: if your near-term goal is transacting inside ChatGPT specifically, ACP is what that requires, and we do not implement it today. A store that needs that this quarter should weigh that honestly rather than take our word that the plumbing underneath is nicer.

On the roadmap: ACP and UCP

Stated as intent, not as a feature. We have decided to add both ACP and UCP alongside MCP, taking ACP first because it is narrower and because it is what selling inside ChatGPT requires. Nothing above changes until they ship: today the engine speaks MCP and only MCP, and anything you build against it now should assume exactly that.

We are deliberately not publishing dates. Both specifications are still moving — ACP is versioned by date and described as beta, and UCP’s non-shopping verticals are unpublished — and a delivery date pinned to someone else’s moving spec is a promise we would not control. This page gets updated the day each protocol actually works, not the day it lands on a plan.

The part that outlives the acronyms

Whichever protocols win, the properties underneath do not change. Every one of these standards assumes the merchant backend can do things that a lot of commerce software cannot currently do well:

• Idempotency, so an agent retrying a timed-out request does not create a second order or a second charge.
• Typed, versioned contracts, so behaviour does not change when someone moves a div.
• Scoped authorisation, so a buyer’s agent can never reach a merchant-only capability.
• An audit log, because automated mistakes scale in a way human ones do not.

That is the actual work. Protocols are the easy part to swap later; a backend that cannot survive a retry is the hard part. If you are weighing where to spend effort before the standards settle, spend it there — and see what agentic commerce means for the broader picture, or self-hosting if the question is who owns the backend doing the surviving.