MCP Explained: The Model Context Protocol in Agentic Commerce

MCP, the Model Context Protocol, is Anthropic’s open standard for connecting AI applications to external tools and data, often described as a USB-C port for AI. It is not a commerce protocol at all. In agentic commerce its job is narrow and foundational: it is the discovery layer, the standard way an agent finds a merchant’s tools before any commerce protocol runs. It became foundational enough that Anthropic donated it to a new foundation in December 2025 to keep it neutral.

Its role in commerce

A merchant or payment provider can expose its capabilities as MCP tools, and an agent can then find and call them the same way it discovers any other tool. This is why the commerce protocols treat MCP as plumbing they plug into rather than a competitor: ACP describes itself as MCP-compatible, and UCP lists MCP as one of its supported transports. Discovery has to happen before checkout, and MCP is the layer that handles it.

MCP in payments today

You can already see MCP used directly in payments. PayPal released what it called the industry’s first remote MCP server in April 2025, initially for conversational invoicing, and Stripe ships an MCP server that exposes payment operations as agent tools. Importantly, there is no first-party “MCP commerce extension” from Anthropic. Commerce use of MCP happens through third parties building MCP servers and through other protocols choosing MCP as a transport, not through a dedicated commerce spec.

Agentic Commerce Atlas runs its own MCP server, so you can query this reference live from an AI agent. See the MCP server, and if you want to build one, how to build a remote MCP server.

Which version of the spec is current

MCP revisions are date-versioned, in the form YYYY-MM-DD. 2026-07-28 is the current stable revision. It was published as final on 28 July 2026, replacing 2025-11-25.

Five days before that release, the IETF put a question to the room that MCP builders should know about. On 23 July 2026 it held a working-group-forming BoF in Vienna, Agent Communication Protocols (agentproto), on whether agent-to-agent and agent-to-tool communication needs standardizing at the IETF rather than only in vendor-founded foundations. The draft minutes record strong sense-of-the-room support for forming a group (154 to 51) and for the IETF as the right venue (158 to 30), but the proposed scope was rejected (38 for, 124 against), and participants pushed to reframe the work around context propagation across trust boundaries. MCP came up repeatedly, including its move to a stateless core, and a charter pull request was raised from the MCP side. The process has moved a step since: on 24 July 2026 the IETF Secretariat announced a non-working-group mailing list, agentproto@ietf.org, for continuing the discussion, “including updates to the proposed charter and aimed toward the formation of a new working group.” That is a rewrite in progress, not a chartered group. Two things are worth holding steady on: the BoF results are explicitly non-binding, and the datatracker still records agentproto as state BOF with no charter. MCP’s governance has not changed. It remains at the Agentic AI Foundation, which on 17 August 2026 also became the home of A2A, and the 2026-07-28 revision is unaffected. This is a venue question that may matter in a year, not a reason to change anything you are building now.

The maintainers describe it as the largest revision since launch, and it matters to anyone running or calling an MCP server:

• A stateless core. The initialize handshake and the Mcp-Session-Id header are retired, so any request can land on any server instance. Protocol version, client identity, and client capabilities now travel in _meta on every request, and an optional server/discover method returns server capabilities up front.
• Multi Round-Trip Requests. The server-initiated elicitation/create, sampling/createMessage, and roots/list calls are replaced by one pattern: the server answers with resultType: "input_required", and the client retries the same request carrying inputResponses.
• Routing and caching at the transport. Mcp-Method and Mcp-Name headers are now required on Streamable HTTP so gateways can route without reading the body, and list results (tools/list, prompts/list, resources/list, resources/read) carry ttlMs and cacheScope so clients can cache them.
• Extensions are formalized. They are identified by reverse-DNS IDs, negotiated through an extensions capability map, and versioned independently of the spec. The official extensions named in the release are MCP Apps (server-rendered HTML interfaces in a sandboxed iframe), Tasks (io.modelcontextprotocol/tasks, long-running work, moved out of the core after its experimental run in 2025-11-25), and Enterprise Managed Authorization, which lets an organization centrally control which servers its people can connect to.
• Hardened authorization, aligned more closely with how OAuth 2.0 and OpenID Connect are deployed in practice, including RFC 9207 issuer validation. Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents.
• A formal deprecation policy, giving every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and removal. Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated under it, but continue to work.

All four Tier 1 SDKs (TypeScript, Python, Go, and C#) spoke 2026-07-28 from the day it shipped; the Rust SDK support is in beta.

This release contains breaking changes, which the maintainers frame as a one-off clean break that the new lifecycle policy and Extensions framework are meant to avoid repeating. If you run a server built against an earlier revision, read the changelog before upgrading; see how to build a remote MCP server for what this means in practice.

What comes after 2026-07-28

On 22 August 2026 the lead maintainers published a new roadmap covering the next specification release and beyond. Nothing in it is shipped, and no date is attached, but it is the clearest available signal of where the discovery layer is heading. Five priority areas, each with named Core Maintainers and a Working Group behind it:

• Agentic messaging primitives. Server-initiated events, webhooks and channels so clients are not left polling for results, plus a composition review across the Agents, Transports, and Triggers and Events Working Groups, and maturing the Tasks extension so it can move into the specification proper.
• HTTP-native transport unification. Stretching the stateless model to cover other deployment modes, including local servers speaking Streamable HTTP over stdio, so there is one transport rather than two.
• Agent identity and enterprise-ready security. Today’s authorization assumes a person approving access in a browser. The work here targets agents running as cloud workloads with their own identity, acting for an absent user or delegating narrower authority to sub-agents: finalizing DPoP (RFC 9449), and an opinionated path through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange, with continued engagement in the IETF OAuth and WIMSE working groups.
• Improved primitives. One clear contract for what a tools/call result returns, and a progressive discovery effort so a server with a large catalog can expose a small entry point and reveal more as the conversation narrows.
• SDK developer experience, including conformance testing.

Two of these matter directly for commerce. Progressive discovery is the answer to a problem merchants hit first: a catalog server with a hundred tools makes the model pay for the whole surface before the shopper has asked anything. And the Server Card Working Group continues work on .well-known metadata conventions, so a server can be discovered and reasoned over without connecting to it, which is the same discovery problem ACP and UCP each solve through their own declared profiles and feeds. Proposals inside these five areas get expedited review; proposals outside them are not rejected, but get maintainer attention last.

How to hold it in your head

The simplest way to keep MCP straight from the commerce protocols: MCP is a discovery protocol, not a commerce one. It sits underneath everything, the standard way an agent finds the merchant’s tools, while ACP and UCP define how the shopping and checkout actually run. They are complementary, and a single transaction can easily involve both. For where MCP sits among the other standards, see the protocol stack.

FAQ

Is MCP a commerce protocol? No. MCP is Anthropic’s general tool-and-data standard. In commerce it acts as the discovery layer, and the commerce protocols can use it as a transport.

How does it relate to ACP and UCP? It is plumbing they plug into. ACP is MCP-compatible and UCP supports MCP as a transport. MCP handles discovery; the commerce protocols run the purchase on top.

Is there an official MCP commerce extension? No. Commerce use happens through third-party MCP servers (PayPal, Stripe) and through other protocols using MCP as a transport, not a dedicated commerce spec.

Which version of the MCP spec is current? Revisions are date-versioned. 2026-07-28 is the current stable revision, published as final on 28 July 2026 and replacing 2025-11-25. It brings a stateless core, Multi Round-Trip Requests, required routing headers on Streamable HTTP, a formalized Extensions framework, and hardened authorization, and it contains breaking changes.