UCP vs ACP vs MCP: which does your business need?

UCP and ACP describe commerce interactions; MCP connects applications to tools and data. They can work together, but none automatically lists your business with every assistant or replaces a tested customer journey.

Reviewed October 1, 2026 · 7 min read

UCP, ACP and MCP solve related but different problems. UCP and ACP define commerce interactions such as cart and checkout. MCP defines how an application connects to external tools, resources and prompts, which can include commerce capabilities.

Choose among them by identifying the application and customer task you want to support. A confirmed integration requirement is a better starting point than adopting whichever acronym appears most often in announcements.

Three protocols, three different jobs#

ACP provides a specification for agent-business commerce. Its project is maintained by OpenAI and Stripe. The exact endpoints and capabilities you need depend on the version and integration you implement.

UCP is a modular commerce specification introduced by Google and partners. MCP is a general connection protocol used by compatible applications to discover and call capabilities. A commerce workflow may combine a business protocol with MCP as an interface.

Keep three questions separate: what information describes the offer, what interface can perform the action and which platform will expose it to customers? No one acronym answers all three.

ACP: commerce interactions between agents and businesses#

The ACP project describes programmatic commerce flows and supports compatible API or MCP integration patterns. It was introduced alongside ChatGPT Instant Checkout, but that product's later changes do not define the protocol's entire scope.

For implementation, separate catalog data, checkout state, payments and platform participation. You may reuse underlying business data across channels, but schemas and acceptance rules differ. Payment handling must follow the supported provider contract.

Use ACP when a confirmed client or commerce provider requires it. Check the supported version and lifecycle behavior before estimating the work. The ACP integration guide covers that process.

UCP: Google’s commerce protocol for Gemini and Search#

UCP advertises modular capabilities through a business profile. Google's merchant integration documentation describes its own supported experience. The open protocol and Google's eligibility rules are related but distinct.

Capabilities and their bindings define how compatible parties exchange information. Use the exact binding, version and payment requirements supported by your client. Do not infer that every possible transport or payment mechanism works in every implementation.

A commerce provider may implement UCP for you, or you may build directly. In either case, verify your account's participation and the final customer flow. The UCP merchant guide covers the checks.

MCP: the protocol agents use to actually do things#

The Model Context Protocol standardizes connections to tools and data. It does not define a universal catalog, payment model or customer acquisition channel. Commerce is one possible use of a tool connection.

A business might expose tools to search offers, check availability or request a booking. A compatible client still needs a connection, appropriate permissions and a clear understanding of the action. An MCP server is useful when a real application can use it.

Registries and directories can help developers find servers, but listing is not automatic adoption by public assistants. Review the relevant registry or application requirements and test the actual client connection.

Compare the responsibilities#

Treat support claims as dated information. Record the version and platform configuration you tested so a later update does not silently change the assumptions behind your integration.

Where they overlap, and where they compose#

The protocols can complement one another. A commerce capability can be made available through a supported MCP interface, while a shared catalog supplies data to several destinations. Reuse the source data, then validate each destination's contract separately.

Public pages and JSON-LD remain useful for explaining offers to people and supporting systems. They are not universal prerequisites for every protocol, and special files such as llms.txt are not a substitute for a working integration.

For example, one customer may arrive from a search recommendation and use your website, while another uses a connected booking assistant. Both should receive the same service terms and current price even though their interfaces differ.

Choose what to support first#

Begin with a real demand or integration requirement. If none exists yet, improve your public offers and customer flow while you investigate the options. You do not need to implement three protocols to make useful progress.

1. Define the task: discovery, a quote, a reservation or a completed purchase.
2. Identify the consuming application and confirm merchant or connector eligibility.
3. Compare required capabilities with your current catalog, calendar, checkout and payment systems.
4. Build the smallest complete supported flow, including authorization and failure handling.
5. Measure actual use and completed outcomes before expanding. See the measurement guide.

For services, scheduling and scope often matter more than shipping attributes. Choose a flow that handles those details explicitly, whether through an existing booking platform or a connected tool. See how agents book services.

Use shared data without assuming shared compatibility#

Nexez publishes structured business listings and supported commerce resources from maintained offer data. Review what each resource exposes and which clients can use it. A platform-specific enrollment step may still be required.

The useful benefit is fewer separately maintained copies of an offer. Verify the resulting pages, feeds and actions independently, especially when availability or payment details change.