UCP Compatibility with A2A, AP2, and MCP
> UCP is designed to be transport-agnostic and protocol-composable: it supports REST natively, integrates with MCP as a tool-calling transport, works with A2A for multi-agent commerce orchestration, and pairs with AP2 as a cryptographic trust layer for verifiable agent transactions — giving merchants a single commerce protocol that works across all major AI agent frameworks.
---
Why Protocol Interoperability Matters
The AI agent ecosystem is not converging on a single framework. Different AI platforms and agent developers use different communication protocols — some use REST, some use MCP tool calls, some use A2A for multi-agent coordination, and some require cryptographic proof of payment authorisation. A commerce protocol that is locked to a single framework would require merchants to build separate integrations for each agent type.
UCP addresses this by being transport-agnostic and extensible. The core commerce capabilities — search, lookup, cart, checkout, identity, post-purchase — are defined once in the UCP specification and can be invoked via REST, via MCP tools, or via an A2A-coordinated multi-agent workflow, without the merchant needing to change their underlying UCP implementation. The AP2 extension layer adds cryptographic guarantees to UCP transactions for contexts where verifiable payment authorisation is required.
This page explains each of the three companion protocols, their relationship to UCP, and what each means practically for merchants implementing the full UCP stack.
---
MCP — Model Context Protocol
MCP (Model Context Protocol) is a protocol that defines how AI models interact with tools and external data sources. In the MCP model, AI applications — chatbots, research assistants, coding agents — connect to MCP servers that expose capabilities as structured tools with defined input and output schemas. The AI model invokes these tools by name, passes structured inputs, and receives structured outputs.
UCP supports MCP as a transport layer. This means UCP commerce capabilities — catalog search, product lookup, cart management, checkout — can be packaged as MCP tools and exposed through an MCP server. An AI agent built on an MCP-compatible framework can invoke "search products," "add to cart," and "complete checkout" as native tool calls, without needing a dedicated REST client or custom commerce connector.
The ACP specification itself notes this parallel: ACP is described as similar in concept to MCP — just as MCP defines how AI models interact with tools and data sources, ACP defines how AI agents interact with seller checkout systems. UCP takes the same composability approach. The result is that a merchant's single UCP implementation — REST endpoints, manifest, and capability declarations — is accessible to any MCP-compatible agent platform without any additional integration work on the merchant's side.
For merchants, MCP compatibility means that UCP's addressable agent audience grows as MCP adoption expands. Every new AI product or agent framework that adds MCP support immediately gains the ability to invoke UCP commerce capabilities on any UCP-enabled merchant.
---
A2A — Agent-to-Agent Protocol
A2A (Agent-to-Agent) is a communication framework for multi-agent systems — architectures where a coordinating AI agent delegates specific tasks to specialised sub-agents. In a multi-agent commerce scenario, a general-purpose AI assistant might delegate product search to a specialised commerce search agent, price comparison to a comparison agent, and checkout execution to a dedicated transaction agent. A2A defines how these agents communicate, pass state, and coordinate without losing context.
UCP supports the A2A communication framework, allowing UCP-defined commerce services to be orchestrated within multi-agent systems. An A2A-coordinated commerce workflow might look like this: the user's primary assistant agent receives a shopping intent, delegates the search and evaluation sub-task to a product discovery agent via A2A, receives back a shortlist, then delegates the checkout execution to a commerce transaction agent — all of which invoke UCP endpoints on the merchant's system throughout the flow.
From the merchant's perspective, A2A compatibility means that UCP interactions may originate from an orchestrating agent rather than a single end-user agent. The merchant's UCP endpoints remain unchanged — the agent calling the endpoints is simply part of a multi-agent pipeline rather than a single monolithic assistant. The request structure, authentication model, and response contracts are identical.
The a2aprotocol.ai UCP guide confirms that UCP is built to work within the A2A framework, positioning UCP as the commerce capability layer that multi-agent systems can invoke as part of broader orchestrated workflows.
---
AP2 — Agent Payments Protocol
AP2 (Agent Payments Protocol) is a cryptographic trust extension for agentic commerce. Where UCP defines the commerce interaction model — what capabilities exist and how to invoke them — AP2 adds verifiable digital signatures to those interactions, providing cryptographic proof of user intent and payment authorisation. The ucp.md AP2 integration documentation describes AP2 as built on top of UCP's commerce capabilities.
AP2 introduces two signed mandate types:
CheckoutMandate: A digitally signed assertion that a specific user has authorised a specific checkout action. The mandate is signed with the user's private key and can be verified by the merchant using the corresponding public key. This provides non-repudiation — the merchant has cryptographic evidence that the user genuinely authorised the purchase, not just an agent acting on assumed intent.
PaymentMandate: A digitally signed assertion that a specific user has authorised a specific payment. Similar to CheckoutMandate, the PaymentMandate provides verifiable proof of payment authorisation, independent of the agent's claim that the user consented.
AP2 mandates are passed as part of UCP requests — they are additional fields in the request body, not a separate API layer. A UCP merchant that wants to support AP2 must verify the mandate signatures on receipt, which requires implementing the AP2 signature verification logic alongside the existing UCP request header verification (Signature, Timestamp).
For merchants, AP2 is most relevant in high-value transaction contexts — expensive electronics, luxury goods, large multi-item orders — where cryptographic proof of user intent reduces dispute risk and strengthens the merchant's position in any post-purchase disagreement.
---
How the Three Protocols Relate to UCP
| Protocol | Relationship to UCP | Merchant Impact | |---|---|---| | MCP (Model Context Protocol) | UCP capabilities exposed as MCP tools; agents invoke commerce via tool calls | Accessible to all MCP-compatible agents without extra integration | | A2A (Agent-to-Agent) | UCP services callable within A2A multi-agent workflows | UCP endpoints reachable from orchestrated multi-agent pipelines | | AP2 (Agent Payments Protocol) | Cryptographic trust layer on top of UCP; adds CheckoutMandate and PaymentMandate | Verifiable user intent and payment authorisation for high-value transactions | | REST (native) | UCP's primary transport; direct HTTPS endpoint calls | Default integration path for all merchants |
---
Why It Matters for Merchants
Protocol interoperability translates directly into addressable market size. A merchant who implements UCP once — REST endpoints, manifest, capability declarations — is reachable via REST, MCP, and A2A simultaneously. As new AI agents and platforms emerge and choose their transport frameworks, the merchant's UCP implementation works with each of them without modification.
The AP2 layer provides a specific commercial benefit: reduced payment dispute risk in high-value transactions. For a merchant selling products above a certain price threshold, having cryptographic evidence that the buyer signed a PaymentMandate before the transaction completed is a meaningful protection — particularly in the early days of agentic commerce when consumer and regulatory norms around AI-initiated purchases are still forming.
Merchants do not need to implement AP2 to participate in UCP commerce. It is an optional extension for scenarios where the additional trust guarantee justifies the implementation complexity. The decision of whether to implement AP2 should be driven by the merchant's product category, average order value, and dispute frequency — not by the protocol's availability.
---
FeedBridge Relevance
FeedBridge operates within the UCP ecosystem by implementing the core UCP REST protocol stack — manifest, search, lookup, cart, identity linking, and redirect checkout. MCP and A2A compatibility at the transport layer means that AI agents using those frameworks will invoke the same UCP endpoints that FeedBridge provides, without any additional FeedBridge-specific integration work.
AP2 signature verification is not currently documented as a FeedBridge platform capability. Merchants who want to implement AP2 mandate verification should refer to the ucp.md AP2 integration documentation and implement signature verification on their own commerce stack.
---
Frequently Asked Questions
Q: Do I need to implement MCP support separately from UCP? A: No. If your UCP endpoints are correctly implemented and your manifest is published, MCP-compatible agents can invoke your commerce capabilities via the MCP tool-calling layer without any additional endpoint work from you. The MCP compatibility is a property of how UCP capabilities are exposed, not a separate integration requirement.
Q: Is A2A support required for UCP certification? A: A2A compatibility is a property of the UCP protocol design, not a merchant implementation requirement. Merchants implement UCP REST endpoints; the fact that those endpoints are also reachable from A2A orchestrated workflows is a protocol-level characteristic that requires no additional merchant effort.
Q: What is the difference between ACP and AP2? A: ACP (Agentic Commerce Protocol) is a standalone checkout protocol focused on ChatGPT Shopping and similar AI surfaces. AP2 (Agent Payments Protocol) is a cryptographic extension layer built on top of UCP — it adds signed mandates to UCP transactions but is not a standalone commerce protocol. They are complementary: ACP handles checkout delegation for OpenAI surfaces, AP2 adds cryptographic trust to UCP-based transactions on Google surfaces.
Q: Does AP2 change how payments are processed? A: No. AP2 adds signature verification to UCP requests — it provides cryptographic proof of user intent, but the actual payment processing still happens through the merchant's PSP (for native checkout) or through Google Pay (for UCP on Google surfaces). AP2 is a trust attestation layer, not a payment processing layer.
Q: Where can I find the AP2 specification? A: The AP2 integration documentation for UCP is available at ucp.md. The full AP2 specification covers CheckoutMandate and PaymentMandate structures, signing requirements, and verification procedures.
---
Related Topics
Parent hub: UCP Interoperability
Related concepts:
- What Is UCP?
- UCP Across the Full Shopping Journey
- UCP Capability Discovery Explained
- UCP Profile and Capability Negotiation Basics
Breadcrumb:
---
Source Documentation
| Claim | Source | Source Class | Reference | |---|---|---|---| | UCP supports MCP and A2A as transports | a2aprotocol.ai UCP 2026 guide | T1 – Official UCP Docs | https://a2aprotocol.ai/blog/2026-universal-commerce-protocol | | ACP described as similar in concept to MCP | agenticcommerce.dev/docs | T1 – Official ACP Docs | https://www.agenticcommerce.dev/docs | | AP2 built on top of UCP; CheckoutMandate and PaymentMandate | ucp.md AP2 integration docs | T1 – Official UCP Docs | https://ucp.md/en/docs/ap2-integration/ | | FeedBridge UCP REST stack: manifest, search, lookup, cart, identity, redirect checkout | FeedBridge Platform Capabilities April 2026 v2.0 | T1 – FeedBridge Internal | FeedBridge-Platform-Capabilities-April2026.md |