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. Large retailers are now doing the same directly. Walmart is the clearest case: on 21 October 2026 it announced the Walmart Agent Gateway, an MCP server through which approved third-party agents can search its inventory and place orders for a customer, starting as a beta for companies and developers and governed by Walmart’s own published terms for AI agents. 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 since run to a decision. 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.” And on 8 October 2026 the IESG approved the charter. The Datatracker now records agentproto as an Active working group in the Applications and Real-Time Area, chaired by Leslie Daigle and Orie Steele, under charter-ietf-agentproto-01; the one Block raised during review, over layering and scope, had been cleared in September and its author recorded Yes before the vote. The approved charter also tells MCP builders where they sit in it. The scope is now “a common baseline agentic dialog management protocol” built around dialog identifiers, lifecycle semantics and the propagation of dialog context, explicitly not a replacement for application-layer agent protocols or a new transport; a 2 October revision dropped earlier wording about extension points, and the approved text says the dialog context “is defined so that existing application-layer agent communication protocols (e.g., the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol) can carry it using their own mechanisms,” with any related change to those protocols left to their own maintainers and out of scope. In practice MCP would carry agentproto’s dialog context in its own messages rather than plug into a new protocol. The milestones run from an informational use-cases draft adopted in December 2026 and an architecture draft in February 2027 to the protocol draft or drafts submitted to the IESG as proposed standard in March 2028, so a chartered group now exists but the standard it produces is a 2028 question on the IETF’s own schedule. As of 31 October 2026 the group had adopted no working-group drafts (all documents on its Datatracker page are individual submissions), and its first session is scheduled for IETF 127 in San Francisco on 16 November 2026. 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 a server/discover method, which servers must implement and clients may call, returns supported protocol versions, capabilities, and server identity 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 were 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. The set has since grown: the official extensions index now lists six, adding Skills over MCP (discovering workflow instructions and reading supporting files through MCP resources), OAuth Client Credentials (machine-to-machine authentication with application-level credentials, no browser redirect and no user consent step, for background services and CI) and Server Cards (below). Since 29 October 2026 each extension also carries a maturity stage, under SEP-3392, Extension Lifecycle (status Final): an extension moves from Experimental to Beta and then either to Stable or into the core specification, and a Stable extension changes only with a new core protocol revision, while Experimental and Beta extensions may still make breaking changes. The index now marks MCP Apps, Enterprise Managed Authorization and OAuth Client Credentials as Stable, Tasks as Beta with promotion to the core as its stated destination, and Skills over MCP and Server Cards as Beta. For an implementer that stage, not the word “official”, is the stability signal to read. Official extensions live in ext- repositories inside the MCP GitHub organization and use the io.modelcontextprotocol vendor prefix, so the index rather than the release post is the thing to check.
• 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, or at least ninety days under an expedited-removal exception the policy reserves. Roots, Sampling, Logging, and the legacy HTTP+SSE transport are deprecated under it, but continue to work. Plan on twelve months, but do not treat it as a guarantee.

All four Tier 1 SDKs at release (TypeScript, Python, Go, and C#) spoke 2026-07-28 from the day it shipped. The official SDK list now rates six SDKs as Tier 1, adding Rust and Ruby; Ruby reached Tier 1 on 29 September 2026, with version 1.2.0 of its mcp gem completing 2026-07-28 support. SDKs adopt revisions on their own schedules, so check each one’s documentation.

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 server discovery has moved from roadmap to accepted design. On 6 October 2026 SEP-2127, MCP Server Cards, was merged with status Final as an Extensions Track proposal, chartering an official extension, io.modelcontextprotocol/server-card. A domain publishes an AI Catalog at /.well-known/ai-catalog.json that links to or embeds Server Cards, and each card describes a server’s identity, its remote endpoints and the protocol versions it supports, so a client or crawler can find and configure a server without connecting to it; <streamable-http-url>/server-card is reserved as the recommended card location. Tools, resources and capabilities are deliberately left out of the card, and cards must not carry credentials. That is the same discovery problem ACP and UCP each solve through their own declared profiles and feeds, now with an MCP answer for where a merchant’s server lives. Two caveats: the normative wire format sits in the ext-server-card repository (renamed from experimental-ext-server-card), whose README still labels the work experimental, although since 29 October 2026 the official extensions index lists Server Cards as a Beta extension; where the two disagree, the index is the maintainers’ current classification. The extension is also not part of the 2026-07-28 core specification, so client support will lag. For catalog-level discovery of products today, the commerce protocols’ own feeds remain the working answer. 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.