MCP vs the Agentic Commerce Protocol
MCP, the Model Context Protocol, is a standard for connecting agents to tools, data, and capabilities. ACP, the Agentic Commerce Protocol published by OpenAI and Stripe, defines how an agent and a merchant complete a purchase. MCP governs access to capability; ACP governs a commercial transaction.
Different layers, not competitors
MCP answers a plumbing question. An agent needs to use something outside itself: a database, a search index, an internal service, a file store. MCP standardises how that capability is described, discovered, and invoked, so a tool implemented once can be used by any compatible client. Its objects are servers and the tools, resources, and prompts they expose.
ACP answers a commerce question. An agent is buying something from a merchant, and both sides need a shared understanding of what is being bought, what it costs, what the buyer has authorised, and how the order completes. Its objects are orders, line items, and checkout state.
These are not alternatives. A merchant could expose its ACP-based checkout as an MCP tool, so an agent discovers the ability to purchase through the same mechanism it discovers everything else, then completes the purchase through the commerce protocol. The question of which to use usually indicates that access and transaction have been collapsed into a single decision when they are separate.
The corpus already covers how ACP compares to AP2, which addresses authorisation rather than checkout. Those three names get used interchangeably and they sit at three different layers.
What neither of them does
Neither moves money by itself. ACP defines how a checkout proceeds and expects a payment method behind it; MCP has no opinion on payment at all. So a stack that lets an agent buy something still needs a settlement rail underneath, and the choice of rail is independent of both. This is the gap that per-call payment schemes and stablecoin rails fill, and it is why a discussion of ACP versus MCP can conclude without anyone having decided how funds actually move.
Two different things you might be paying for
Paying for a capability call. An agent invokes a tool and the provider wants to charge per invocation. This is metered access to an API, and the natural mechanism is a per-call payment demanded at request time. MCP does not define this, so it is layered on: the transport carrying the tool call also carries the payment challenge, or the tool itself requires payment before returning a result.
Paying for goods or services. An agent buys a physical product, a subscription, or a booking. Here the amount is not a per-call fee, the transaction has an order and a fulfilment step, and the failure modes involve returns, disputes, and delivery rather than a failed request. This is what a commerce protocol addresses, and treating it as a metered API call loses everything that makes it a purchase.
The distinction matters because the guarantees differ. A failed API call can be retried cheaply and idempotently. A failed purchase may have moved money, created an order, and committed inventory. An architecture that handles both identically will either over-engineer the cheap case or under-engineer the expensive one.
Authorisation is a third concern. What the user actually approved, recorded in a form that survives the agent's own reasoning, is what AP2 addresses and what neither MCP nor a settlement rail provides. A spending limit enforced by a key is a blunt version of the same idea, and for many agent workloads it is sufficient.
| Dimension | MCP | ACP |
|---|---|---|
| Problem solved | Connecting an agent to tools and data | Completing a purchase between agent and merchant |
| Layer | Capability access | Commerce transaction |
| Published by | Anthropic | OpenAI and Stripe |
| Core objects | Servers, tools, resources, prompts | Orders, line items, checkout state |
| Handles payment | No, not its concern | Yes, as part of checkout |
| Typical integrator | Anyone exposing a capability to agents | Merchants selling to agent buyers |
| Relationship assumed | Client connects to a server it trusts | Buyer and seller completing a transaction |
| Can wrap the other | A checkout can be exposed as an MCP tool | Not a transport for arbitrary capability |
Frequently asked questions
- What is the difference between MCP and ACP?
- MCP is a standard for connecting agents to tools, data, and capabilities, covering how those are described, discovered, and invoked. ACP, published by OpenAI and Stripe, defines how an agent and a merchant complete a purchase. One governs capability access, the other a commercial transaction.
- Do MCP and ACP compete?
- No, they sit at different layers and compose. A merchant can expose an ACP-based checkout as an MCP tool, so an agent discovers the ability to buy through the same mechanism it discovers everything else, then completes the purchase through the commerce protocol.
- Does MCP handle payments?
- No. MCP has no payment concept, so charging for a tool call is layered on top, either by the transport carrying a payment challenge alongside the call or by the tool requiring payment before returning a result. Settlement itself is a separate mechanism entirely.
- Does ACP move money?
- It defines how a checkout proceeds and expects a payment method behind it, rather than settling funds itself. A stack that lets an agent buy things still needs a settlement rail underneath, and that choice is independent of which commerce protocol sits above it.
- Is paying for an API call the same as buying a product?
- No, and conflating them causes design problems. A failed API call retries cheaply and idempotently. A failed purchase may have moved money, created an order, and committed inventory, with returns and disputes as real outcomes. The guarantees each needs are genuinely different.