Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
The Model Context Protocol (MCP) is an open standard that lets AI applications connect to outside systems in a consistent way. For a store, an MCP server is a small service that exposes selected capabilities, such as searching the catalog, checking stock, building a cart or looking up an order, as "tools" and "resources" that an AI assistant or agent can discover and call. It does not make your store AI-powered by itself; it gives AI clients a controlled, documented doorway into your data and actions, and the security of that doorway is your responsibility.
This guide explains how MCP works, what an ecommerce MCP server typically exposes, and the security controls each capability needs.
How the Model Context Protocol works
The official documentation at modelcontextprotocol.io describes three participants:
- MCP host: the AI application, such as a desktop assistant, an IDE or a shopping agent.
- MCP client: a component inside the host that keeps a connection to one MCP server.
- MCP server: a program that provides context and actions. It can run locally or remotely.
Messages use JSON-RPC 2.0. Remote servers typically use the Streamable HTTP transport, and the protocol recommends OAuth for obtaining access tokens. Servers can expose three core primitives:
- Tools: functions the AI can call, such as
search_productsorget_order_status. - Resources: data the AI can read for context, such as a returns policy or a product record.
- Prompts: reusable templates that help structure interactions.
Clients discover what a server offers by listing its tools, and each tool declares a JSON Schema for its inputs. The protocol is evolving quickly: the 2026-07-28 specification, current as of November 2026, describes stateless, self-contained requests, so design tools to pass identifiers such as a cart ID explicitly rather than relying on a session. Check the current specification before building, and expect further changes.
Where MCP fits in commerce
MCP is a connection layer, not a shopping standard. Agentic commerce protocols such as the Universal Commerce Protocol (UCP) and the Agentic Commerce Protocol (ACP) define shopping and checkout flows between agents and merchants, and they can run alongside or on top of MCP-style connections. Our explainers on agentic commerce and UCP vs ACP cover those layers.
Adobe committed in February 2026 to supporting UCP and ACP, and introduced a Commerce MCP server at Adobe Summit in April 2026. Adobe has described these as announcements and commitments, so what is available to a given store depends on edition, deployment model and licence; check Adobe's current documentation. Stores that need capabilities outside what a vendor server provides, or that run Magento Open Source, can build their own MCP server on top of the platform's GraphQL and REST APIs.
Capability table: what a store MCP server can expose
Each capability below is a candidate tool or resource. The security column lists the minimum controls; the risk column reflects what happens if the control fails.
| Capability | Example tools / resources | Risk | Key controls |
|---|---|---|---|
| Read catalog | search_products, get_product, product attributes as resources | Low | Public data only; rate limits; respect customer-group visibility and pricing |
| Check price and stock | get_price, check_availability | Low to medium | Prices computed by the platform, never by the model; B2B prices only for authenticated accounts |
| Store policies | Shipping, returns and warranty as resources | Low | Single source of truth; versioned content |
| Cart | create_cart, add_item, apply_coupon | Medium | Unguessable cart handles bound to the authenticated user; coupon abuse limits |
| Checkout and payment | start_checkout, hand-off to payment | High | Explicit user confirmation; payment through the payment provider's own flow; never pass card data through the model |
| Order lookup | get_order_status, list_orders | Medium to high (personal data) | User-scoped OAuth tokens; return only the requesting customer's orders; data minimization |
| Order changes | cancel_order, request_return, change_address | High | Separate scopes; confirmation step; business-rule validation; audit log |
| Admin operations | Update products, prices, inventory | Very high | Usually keep out of customer-facing servers; staff-only server with strong authentication and narrow scopes |
A practical rule: start with read-only catalog and policy capabilities, then add cart, then order lookup for authenticated customers, and treat anything that changes orders or money as a separate project with its own review.
Security considerations
The MCP project publishes security best practices. The points most relevant to stores are:
- No token passthrough. The specification forbids MCP servers from accepting tokens that were not issued for the MCP server itself. Validate the token audience; do not forward a client's token straight to your commerce API.
- Least-privilege scopes. Offer a minimal initial scope for read operations and request more only when a privileged tool is used. Avoid omnibus scopes such as full access.
- State handles are not authentication. A cart or workflow ID returned by a tool must be random, expiring and bound server-side to the authenticated user. Possession of the handle alone must never grant access.
- Treat model input as untrusted. Tool arguments come from a language model that may have been manipulated by text in a web page or product review. Validate every argument against the schema and your business rules on the server.
- Confirm consequential actions. MCP supports elicitation, where a server asks the user for input or confirmation. Use explicit confirmation for purchases, cancellations and anything irreversible.
- Log and rate-limit. Record which client called which tool with which scope, and cap request rates per client and per user.
These controls apply whether you use a vendor's server or build your own. With a vendor server, ask how each one is implemented.
Building a custom MCP server for Magento
A custom server is usually a thin service in front of Adobe Commerce or Magento Open Source:
- Choose the capabilities from the table above and write a short spec for each tool: name, description, input schema, output and required scope.
- Implement the tools against the platform's GraphQL or REST APIs so pricing, tax and stock logic stay in the platform. Where the APIs do not cover a need, add a small custom module; our Magento extension development work covers that layer.
- Add OAuth-based authorization with separate scopes for read, cart and order operations.
- Test with an MCP inspector tool and with real AI clients, including adversarial prompts.
- Monitor usage and keep tool descriptions accurate, because AI clients choose tools based on those descriptions.
FAQ
Is MCP only for Anthropic's products?
No. MCP is an open protocol with SDKs in several languages, and many AI applications and developer tools support it as clients.
Does an MCP server help my products appear in AI shopping assistants?
Not on its own. Visibility in assistants depends on how each assistant sources products, which often involves product feeds or protocols such as UCP and ACP. MCP gives connected clients a way to call your capabilities.
Should the server run on the same host as Magento?
Usually not. A separate service limits the impact of a compromise and lets you scale and secure it independently.
Next steps
If you are planning an MCP server or broader agent readiness for your store, Mistri's agentic commerce services start with a capability and risk review like the table above.
Sources
Model Context Protocol: Architecture overview; Model Context Protocol: Security best practices; Model Context Protocol: Specification; Adobe blog: Adobe Commerce commits to agentic commerce standards; Adobe blog: Adobe Commerce Summit 2026 announcements.
