MCP For Ecommerce: How Merchants Expose Catalog, Cart, Checkout, And Order Tools To AI Agents

MCP for ecommerce means giving AI agents a standard way to discover and call merchant tools: product search, product detail, availability, cart, checkout, order status, and support actions. MCP does not replace commerce protocols or payment authorization. It is the tool-access layer that lets agents reach the systems where commerce happens.

Short answer

Use MCP to expose merchant capabilities as tools. Start with read-only catalog and policy tools. Add cart, checkout, order, or account tools only when authentication, authorization, validation, rate limits, and audit logs are in place. Pair MCP with ACP, UCP, or your own commerce APIs for the transaction itself.

Where MCP fits

The Model Context Protocol is not an ecommerce standard. It is a general protocol for connecting AI applications to tools and data. In commerce, that makes it the discovery and tool-call layer. An agent can ask: “What tools does this merchant expose?” Then it can call the right one.

The checkout rules still live elsewhere. ACP standardizes an agentic checkout session. UCP covers a broader shopping journey. AP2 handles authorization. Payment networks and processors handle credentials and settlement. MCP is how the agent reaches a merchant’s capabilities in a predictable way.

MCP is no longer an Anthropic project in governance terms either. It was contributed to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025.

Which revision of MCP this guide assumes

MCP revisions are date-versioned. The current stable revision is 2026-07-28, published on 28 July 2026, and it is the largest change to the protocol since launch. Nothing in this guide about what a merchant should expose changes because of it, but three things about how do, and they are operationally significant for a commerce deployment:

• The protocol is stateless. The initialize and initialized handshake and the Mcp-Session-Id header are gone. Any request can land on any instance, so a commerce MCP server can sit behind an ordinary load balancer with no sticky routing and no shared session store.
• State moves into explicit handles. Because the transport no longer carries a session, a server that needs continuity across calls should mint an identifier from a tool (a cart ID, for example) and have the model pass it back as a normal argument. For ecommerce this is the natural pattern anyway: create_cart returns a cart ID, and update_cart and quote_checkout take it as input.
• Traffic is routable and cacheable at the HTTP layer. Every Streamable HTTP request carries an Mcp-Method header, and tool, resource, and prompt calls also carry Mcp-Name, so gateways can route, throttle, and rate-limit per tool without reading the body. List and resource-read results now carry a cache lifetime and a cache scope, so a catalog tool list can be cached rather than re-fetched on every conversation.

The older HTTP plus Server-Sent Events transport is deprecated, and three core features (roots, sampling, and logging) are deprecated but still working under a formal policy that requires at least twelve months before removal. If you are running a server written against an earlier revision, it will keep working while clients negotiate versions, but new work should target 2026-07-28.

The tool set an ecommerce agent needs

Think in tiers. Public read-only tools are the safest starting point.

Tool	Read or write	Why an agent needs it
search_products	Read	Find candidate products from a user’s intent
get_product	Read	Retrieve attributes, variants, price, availability, and images
estimate_shipping	Read	Check delivery cost and timing before checkout
get_policies	Read	Return returns, warranty, restrictions, and support policies
create_cart	Write	Assemble a cart from selected items
update_cart	Write	Change quantity, variant, address, or fulfillment choice
quote_checkout	Read/write	Price the final cart with tax, shipping, discounts, and constraints
complete_checkout	Write	Complete an order after authorization and payment are valid
get_order_status	Read	Support post-purchase questions

Not every merchant should expose every tool. A public reference site might expose only search and page retrieval, like the Atlas MCP server. A retailer handling customer carts needs a much stricter trust model.

Start read-only

The lowest-risk ecommerce MCP server exposes public data: product search, product details, availability, store policies, and perhaps a shipping estimate that does not require private customer data. That is enough for an agent to compare and recommend products, and it helps you learn how agents call your systems before letting them mutate carts or orders.

Read-only tools still need guardrails. Return structured, current data. Rate-limit calls. Avoid exposing internal fields. Make errors clear enough for agents to recover. Log the tool name, inputs, caller, response status, and latency.

Add cart and checkout carefully

Write tools are where MCP becomes operationally sensitive. A cart tool changes state. A checkout tool can commit money. An order tool can reveal customer data. These tools should require authentication, explicit authorization, input validation, idempotency, and audit logging.

Since the protocol is stateless, carry cart state in an explicit identifier your tools return and accept, not in transport metadata. That also makes the state visible to the model and to your logs, which is what you want when you later have to reconstruct what happened.

Before adding a write tool, answer:

• Who is the caller, and how do we know?
• What user or merchant account is this tool acting for?
• What constraints apply to price, quantity, products, geography, recurrence, and payment?
• Can the call be retried safely?
• What record proves what happened?

For checkout implementation detail, see how to implement ACP. For authorization, see AI shopping agent authorization.

Tool descriptions matter

MCP tools are selected by models. That means names and descriptions are part of the interface. A vague tool such as commerce_tool is hard for an agent to use safely. A precise tool such as estimate_shipping with a schema for product_id, quantity, postal_code, and country is easier to call and easier to validate.

Good ecommerce tool schemas:

• use stable IDs rather than display names;
• distinguish optional and required fields;
• use integer money amounts in minor units when returning prices;
• return explicit availability and restriction states;
• include policy URLs where a human or agent can inspect terms;
• reject ambiguous input rather than guessing.

Privacy and authentication boundary

Public catalog data can often be public. Customer data cannot. Cart, checkout, order, account, loyalty, subscription, and support tools should be authenticated and scoped to the user or organization they act for. If a tool can spend money, expose private data, change an order, or trigger fulfillment, it needs stronger controls than a public product lookup.

The MCP specification includes patterns for transports and authorization, but the business rule remains yours: expose the minimum capability needed, and make the tool’s scope obvious.

How this composes with ACP and UCP

MCP can expose the door. ACP or UCP can define what happens after the agent walks through it. The two are not mutually exclusive: UCP’s v2026-08-25 specification defines its Checkout, Cart, and Catalog capabilities over REST, MCP, and A2A transports, so a merchant implementing UCP may be exposing those capabilities as MCP tools already. ACP’s latest stable specification, 2026-04-17, likewise covers MCP alongside cart, feed, orders, and authentication.

A typical composed flow:

1. An agent calls search_products through MCP.
2. It calls get_product and estimate_shipping for the best candidates.
3. It creates a cart through a merchant tool or ACP checkout endpoint.
4. The user approves, or an AP2 mandate proves prior authorization.
5. Payment is completed with a scoped token or other payment artifact.
6. The order record is returned and logged.

This layered model avoids asking one protocol to do everything. MCP is discovery and tool access. Commerce protocols define shopping and checkout semantics. Payment protocols prove and settle the money movement.

A minimal implementation plan

1. Publish complete, accurate product data.
2. Build read-only MCP tools for search, product detail, policy, and shipping estimate.
3. Add logging, rate limits, monitoring, and clear error shapes.
4. Add authenticated cart tools only after validation and idempotency are ready.
5. Connect checkout through ACP, UCP, or your existing API.
6. Add payment authorization and evidence records before accepting real money.

For a worked MCP server example, see how to build a remote MCP server. For the catalog foundation, start with product catalog for agentic commerce.

FAQ

What is MCP for ecommerce? It is the practice of exposing merchant capabilities, such as catalog search, product details, cart creation, checkout status, and order lookup, as MCP tools an AI agent can discover and call.

Is MCP enough to complete a purchase? Usually no. MCP is the tool and data access layer. Checkout, authorization, and payment still require commerce and payment protocols or merchant APIs.

Which tools should a merchant expose first? Start with read-only product search, product detail, availability, shipping estimate, policy lookup, and order status. Add cart and checkout later.

Should public tools require authentication? Public catalog tools may be unauthenticated if they expose only public data. Anything involving customers, carts, orders, private pricing, or checkout should require authentication and authorization.

Which MCP revision should a merchant build against? The current stable revision is 2026-07-28, published on 28 July 2026. It made MCP stateless: no initialize handshake, no session header, required Mcp-Method and Mcp-Name headers on Streamable HTTP, and cacheable list results. Cart and checkout tools that used to lean on session state should mint an explicit handle, such as a cart ID, and have the agent pass it back on later calls.