Husain Alhaboubi

If you build or architect ecommerce systems, your primary user is no longer a human holding a phone. In 2026, it is increasingly an AI agent holding a purchase mandate, and MCP ecommerce is the protocol layer that decides whether that agent can discover your catalog, reason about your inventory, and complete a checkout on your backend. The Model Context Protocol (MCP) went from an Anthropic side-project in November 2024 to the de-facto standard for agent-to-tool communication, with 97 million monthly SDK downloads by March 2026 and native support across OpenAI, Google, Microsoft, and AWS.

This MCP ecommerce guide is written for engineers, CTOs, and ecommerce architects who need to understand what the protocol actually is at the wire level, how it sits alongside complementary protocols like the Universal Commerce Protocol (UCP), the Agent Payments Protocol (AP2), and the Agentic Commerce Protocol (ACP), and what a production-ready MCP ecommerce server looks like for a Salla, Zid, Shopify, or custom Saudi ecommerce stack. I will skip the hype and go straight to the architecture, authentication flows, code, and concrete decisions you need to make this quarter for MCP ecommerce readiness.

What MCP Ecommerce Actually Means in Technical Terms

MCP ecommerce is the application of the Model Context Protocol to online retail: exposing your store’s catalog, inventory, cart, order, and checkout capabilities to AI agents through a single standardized interface rather than through one-off integrations per AI vendor. MCP uses JSON-RPC 2.0 for all client-server communication, which means every agent interaction with your store is a structured, schema-validated RPC call with predictable request and response shapes.

The reason this matters: before MCP, if you wanted your store to be discoverable by ChatGPT, Gemini, Claude, and Copilot, your team had to write four different integrations against four different agent frameworks, each with its own auth model, tool-calling syntax, and rate-limit quirks. The N×M integration problem made AI shopping a demo, not a channel. MCP collapses that matrix to N+M: you write one MCP server for your store, every compliant client can talk to it. The MCP project now operates under the Agentic AI Foundation within the Linux Foundation, co-founded by Anthropic, Block, and OpenAI, which removes the single-vendor risk that would otherwise make this a dangerous dependency.

For a decision-maker, the operational definition is simple: if an agent on any major platform cannot issue tools/call against your store to list products, add to cart, or submit a checkout payload, then agentic traffic is going to route around you. The strategic argument for agentic commerce covers the business case; this post is about the implementation.

MCP Architecture: Host, Client, Server, and Transport

MCP defines a three-role topology that every MCP ecommerce implementation inherits. The host is the LLM application the end user interacts with: Claude Desktop, ChatGPT, Gemini, a custom agent in your own product. The host spawns one or more clients, each of which maintains a 1:1 session with a server. The server is what you build and run; it exposes capabilities (tools, resources, and prompts) that the host can invoke on behalf of the user. This separation is not cosmetic: it is how MCP enforces isolation between sessions so one user’s shopping context cannot bleed into another’s.

The three MCP primitives

Every MCP server exposes some combination of three primitives. Tools are functions the agent can call with arguments and receive structured results, which is the primitive you will use most for ecommerce (search_products, add_to_cart, create_checkout). Resources are read-only data sources the agent can fetch, such as a product detail page, a merchandising feed, or a brand style guide. Prompts are server-defined templates the host can surface to the user, useful for things like guided reorders or returns workflows. An experimental fourth primitive, Tasks, wraps long-running operations so agents can poll for completion rather than block on synchronous responses.

Transports: stdio vs Streamable HTTP

MCP servers ship in two flavors. Local servers communicate over stdio and run on the same machine as the host; useful for developer tools but irrelevant for a hosted ecommerce backend. Remote servers use Streamable HTTP (which supersedes the older SSE transport) and live behind a URL your customers’ agents connect to over the internet. For any real ecommerce deployment, you are building a remote server with Streamable HTTP, TLS, and OAuth 2.1, period.

Streamable HTTP has a gotcha worth flagging early: servers can return either plain JSON or Server-Sent Events depending on whether a tool response is incremental. Your client integrations, and anything you build for testing, must set Accept: application/json, text/event-stream or you will get silent 406 responses on streaming tools.

The Agentic Commerce Protocol Landscape: MCP vs UCP vs ACP vs AP2 vs A2A

MCP does not stand alone. A full agentic commerce stack involves four overlapping protocols, and confusing them is the number one source of architectural drift I see in technical planning docs. Here is the clean mental model.

Protocol	Primary Owner	Scope	What It Does for Ecommerce
MCP (Model Context Protocol)	AAIF / Linux Foundation (originally Anthropic)	Generic tool and data access for LLMs	The transport and tool-calling layer. Agents discover and invoke your store’s capabilities.
UCP (Universal Commerce Protocol)	Google + Shopify, co-developed	Full commerce journey: discovery, checkout, orders, returns, loyalty	The commerce-specific vocabulary on top of transports like MCP and REST. Defines checkout state machines, payment handlers, fulfillment.
ACP (Agentic Commerce Protocol)	OpenAI + Stripe	Checkout layer only, ChatGPT-centric	Powers Instant Checkout in ChatGPT. Narrower in scope than UCP.
AP2 (Agent Payments Protocol)	Google and ecosystem partners	Payment authorization with cryptographic proof of user consent	The payments layer. Ensures the merchant and payment network can verify the agent had consent to spend.
A2A (Agent2Agent)	Google and ecosystem partners	Agent-to-agent communication	Lets your merchant-side agent negotiate with a shopper’s agent.

Here is the critical insight: UCP explicitly supports MCP as a transport binding. That means when you expose your capabilities via an MCP server, you can satisfy UCP-driven clients at the same time. UCP is built on industry standards including REST and JSON-RPC transports with A2A, AP2, and MCP support built in, so a well-designed MCP server is a prerequisite, not an alternative, for UCP readiness.

The Shopify engineering post on UCP puts it bluntly: the Checkout Capability can have a REST API binding or an MCP binding depending on your platform’s needs. You pick your transport; UCP gives you the commerce semantics on top.

Core MCP Ecommerce Use Cases for Engineering Teams

Before a line of code, you should be clear on which MCP ecommerce use cases pay for the engineering investment in your specific environment. Five MCP ecommerce patterns dominate across production deployments, and each maps to a concrete tool or small set of tools on your server.

Catalog exposure and product discovery

Exposing search, filter, and product detail tools so agents can discover your catalog without scraping. This is the table-stakes MCP ecommerce use case and the first tool every merchant MCP server should implement. The agent calls search_products with natural-language queries and structured filters; your server runs it against your search backend (Elasticsearch, Algolia, your platform’s native search) and returns inference-ready results with enough attribute depth to let the agent reason about fit.

Real-time inventory, pricing, and availability

Agents hate stale data. If an agent recommends a product that is out of stock by the time the user confirms, that is a conversion killed. Your MCP ecommerce server should expose a get_inventory or check_availability tool that reads from the same real-time source your checkout does, including location-aware stock for markets like Saudi Arabia where Riyadh and Jeddah fulfillment centers often have divergent availability.

Cart and checkout operations

The highest-value and highest-risk surface in any MCP ecommerce implementation. Tools like add_to_cart, update_cart, apply_discount, and create_checkout let agents progress a shopper from intent to payment. If you are building into Shopify, UCP via Shop Pay handles the payment step; if you are on Salla, Zid, or custom, you need to think carefully about where the human has to re-enter the loop for payment confirmation under Saudi Central Bank rules.

Order tracking and post-purchase

Customer support and order management are often the first place an MCP ecommerce server delivers measurable ROI. A get_order_status tool lets any connected agent answer “where is my order” without hitting your support team. Returns, reorders, and subscription management all fit the same pattern. Combined with AI agents handling inventory, customer service, and pricing, this is where most teams see the fastest payback on their MCP ecommerce investment.

Internal merchandising and operations

Not all your MCP ecommerce servers are customer-facing. Many teams build internal MCP servers that let their own analysts and buyers query inventory, generate promotional campaigns, or kick off bulk price updates through Claude or another in-house agent. These servers sit behind your VPN or SSO; the protocol is the same.

Building an MCP Server for an Ecommerce Backend

Let me show the skeleton of a minimal but production-shaped MCP ecommerce server for an ecommerce backend using the TypeScript SDK. This is not meant to be copy-paste production code; it is the smallest example that exposes the patterns you need for a real MCP ecommerce deployment.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";
import express from "express";

const server = new McpServer({
  name: "store-commerce",
  version: "1.0.0"
});

// Tool: product search
server.tool(
  "search_products",
  "Search the store catalog by natural language query and optional filters.",
  {
    query: z.string().describe("Shopper's search query in any language"),
    category: z.string().optional(),
    max_price: z.number().optional(),
    in_stock_only: z.boolean().default(true)
  },
  async ({ query, category, max_price, in_stock_only }, { authInfo }) => {
    const results = await catalog.search({
      q: query,
      filters: { category, max_price, in_stock: in_stock_only },
      market: authInfo?.user?.market ?? "SA",
      limit: 20
    });
    return {
      content: [
        { type: "text", text: JSON.stringify(results, null, 2) }
      ]
    };
  }
);

// Tool: add to cart
server.tool(
  "add_to_cart",
  "Add a product variant to the shopper's cart.",
  {
    cart_id: z.string(),
    variant_id: z.string(),
    quantity: z.number().int().min(1).default(1)
  },
  async ({ cart_id, variant_id, quantity }, { authInfo }) => {
    requireScope(authInfo, "cart.write");
    const cart = await carts.addItem(cart_id, variant_id, quantity, authInfo.user.id);
    return {
      content: [
        { type: "text", text: `Added. Cart total: ${cart.total} ${cart.currency}` }
      ]
    };
  }
);

const app = express();
const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
await server.connect(transport);
app.all("/mcp", (req, res) => transport.handleRequest(req, res));
app.listen(3000);

A few things are non-obvious but important in that skeleton. First, authInfo flows in on every tool call because every request is OAuth-protected; we will cover that in the next section. Second, the market hint on catalog.search is how you personalize Saudi vs. UAE vs. global results without exposing market selection as a tool parameter that agents can spoof. Third, schema definitions with Zod are not optional; MCP clients use the generated JSON Schema to validate arguments before they ever hit your handler, which catches a huge class of agent hallucinations at the edge.

Designing tool granularity

The biggest design decision is how many tools to expose and at what granularity. Too few and agents are stuck doing N round-trips to accomplish one user goal; too many and the agent’s context window fills up with tool descriptions and its tool-selection accuracy degrades. As a rule of thumb, aim for 8 to 15 tools that each map to a clear user intent, not 50 tools that mirror your internal REST endpoints one-for-one.

OAuth 2.1, PKCE, and Securing Your MCP Ecommerce Server

The MCP Authorization spec is based on OAuth 2.1 with mandatory PKCE, and this is where most prototypes break when they hit production. If your MCP ecommerce server is exposed over HTTP, authentication is not a nice-to-have; it is required by the spec. Here is the minimum viable auth footprint for a production MCP ecommerce deployment.

Required discovery endpoints

Your server must expose two static JSON metadata endpoints so clients can discover how to authenticate. /.well-known/oauth-protected-resource tells clients where your authorization server lives; /.well-known/oauth-authorization-server publishes the actual OAuth endpoints (authorize, token, JWKS). Skipping these is the single most common reason clients fail silently against a freshly deployed server.

Token validation in middleware

Every incoming MCP request carries a Bearer token in the Authorization header. Your middleware should verify the token’s signature, issuer, audience, and scope before handing off to the MCP server. A reference implementation in Node.js:

import jwt from "jsonwebtoken";
import jwksClient from "jwks-rsa";

const jwks = jwksClient({
  jwksUri: process.env.JWKS_URI,
  cache: true,
  cacheMaxAge: 24 * 60 * 60 * 1000 // 24h
});

function getKey(header, callback) {
  jwks.getSigningKey(header.kid, (err, key) => {
    callback(err, key?.getPublicKey());
  });
}

export function validateMcpToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith("Bearer ")) {
    res.set("WWW-Authenticate", `Bearer resource_metadata="${process.env.RESOURCE_METADATA_URL}"`);
    return res.status(401).json({ error: "unauthorized" });
  }
  const token = authHeader.slice(7);
  jwt.verify(token, getKey, {
    algorithms: ["RS256"],
    issuer: process.env.OAUTH_ISSUER,
    audience: process.env.MCP_SERVER_AUDIENCE
  }, (err, decoded) => {
    if (err) return res.status(401).json({ error: "invalid_token" });
    req.auth = { user: { id: decoded.sub }, scopes: (decoded.scope ?? "").split(" ") };
    next();
  });
}

Four details matter here. JWKS keys should be cached for around 24 hours to avoid hitting your identity provider on every request. The WWW-Authenticate header on a 401 is how compliant clients discover where to start the OAuth flow; without it, many clients fail silently. The audience check per RFC 8707 prevents token replay across services. And PKCE with S256 is mandatory in the authorization flow; the days of public clients using implicit flow are over.

Scope design for ecommerce

Start with coarse scopes and split as you learn what agents actually need. A reasonable starting set: catalog.read for product search and detail, cart.read and cart.write for cart operations, checkout.create for initiating checkout, order.read for post-purchase, and admin.* for internal tools. Enforce scope checks inside each tool handler, not only at the transport layer, so a narrow token cannot be escalated by calling the wrong tool.

MCP Ecommerce in the Saudi Stack: Salla, Zid, and Custom Builds

If you are operating in the Kingdom, the platform question has a real answer. The Saudi ecommerce market is estimated at USD 31.29 billion in 2026, projected to reach USD 54.87 billion by 2031 at an 11.92% CAGR, with Salla and Zid dominating the SME and mid-market segment and Shopify, custom carts, and WooCommerce holding the rest. MCP ecommerce readiness varies significantly across that stack, and your implementation strategy depends directly on which platform you are on.

Platform	Native MCP support	Path to MCP Ecommerce	Effort
Shopify	Native, embedded in every store	Enable agentic storefronts; UCP handlers via Shop Pay	Low (platform-managed)
Salla	No native MCP; open token-based REST API	Build custom MCP server that wraps Salla API with OAuth	Medium
Zid	No native MCP; local-integration-focused API	Same pattern: MCP facade on Zid API, mind rate limits	Medium
Custom cart / WooCommerce	Varies; WooCommerce has community MCP servers	Build directly against your data layer; full control, full responsibility	High
Magento / Enterprise	No native support yet	MCP gateway in front of commerce APIs; consider managed MCP providers	High

For Salla specifically, the practical pattern is an MCP facade service: a separate Node.js or Python service that authenticates each merchant’s access token, translates MCP tool calls into Salla API requests, and normalizes the responses into agent-friendly shapes. Because Salla’s API is token-based, you can scope an MCP server per-merchant relatively cleanly. Same architectural pattern works for Zid with slightly different rate-limit handling.

PDPL, SAMA, and data residency considerations

Running an MCP ecommerce server that touches Saudi consumer data pulls in the Personal Data Protection Law (PDPL). Two non-negotiables: every tool response that includes customer PII must be logged with purpose-of-use metadata, and your token and session stores should be hosted in-Kingdom if your merchants include regulated sectors. If your checkout flow triggers a payment, SAMA rules around payment initiation apply regardless of whether an agent is in the loop, and open banking providers must hold the relevant SAMA license. The Saudi digital wallets landscape covers the payment rails your MCP ecommerce checkout tool will ultimately dispatch to.

Arabic content and bidirectional catalogs

Agents reason about what they can read. If your product descriptions are English-only but your shoppers query in Arabic, conversion drops sharply. Your MCP ecommerce server should return both language variants in product responses, and your search tool should accept Arabic queries with proper RTL handling. This is not an MCP issue per se, but it is a gap I see constantly in MENA merchant implementations of MCP ecommerce.

A 90-Day Implementation Roadmap for MCP Ecommerce

If I were standing up MCP ecommerce for a Saudi mid-market merchant this quarter, here is the sequence I would actually follow. This MCP ecommerce roadmap assumes a team of two to three developers and a merchant with a reasonably clean catalog.

Days 1 to 30: foundation and read-only tools

Pick an SDK (TypeScript or Python), stand up OAuth with a provider that supports Dynamic Client Registration and PKCE out of the box, deploy a Streamable HTTP server behind TLS, and ship exactly three MCP ecommerce tools: search_products, get_product, and get_order_status. Wire up structured logging, per-user rate limits, and audit trails. Test against Claude Desktop and the MCP Inspector. This is the minimum viable agent-ready store and the foundation every later MCP ecommerce capability builds on.

Days 31 to 60: cart and write operations

Add add_to_cart, update_cart, apply_discount, and create_checkout. Critically, the checkout tool should not complete payment end-to-end from the agent; it should return a secure checkout URL or signed payload that the human completes on an authenticated surface. This is both a SAMA-compliance move and a fraud-prevention move, since you want a human confirmation before money moves. If you are on Shopify, this is where UCP and AP2 take over; if you are on Salla or Zid, you build the handoff yourself.

Days 61 to 90: observability, governance, and protocol extensions

Now you instrument. Track which tools agents actually call, which arguments they send, where they get stuck, and where they hallucinate. Add an error_help resource that describes common failure modes in structured form so agents can self-correct. If you are targeting Google AI Mode and Gemini, this is the window to start your UCP profile and expose your MCP server as a UCP binding. If you are targeting ChatGPT’s Instant Checkout audience, evaluate ACP separately since its scope is narrower but its integration is tighter.

Common Pitfalls and Production Gotchas

Five mistakes I see consistently in MCP ecommerce rollouts, in descending order of pain. Each of them shows up in production after the server has already shipped, which is why budgeting time to fix them before launch pays back quickly.

Treating MCP servers as stateless REST

MCP sessions carry context. Your MCP ecommerce server should track conversation state at the session level, not only the request level, or agents will churn through redundant discovery calls and your latency will spike.

Exposing every internal API as a tool

If your REST API has 80 endpoints, you do not want 80 MCP tools. Agents pick tools by reading their descriptions, and a cluttered tool list degrades selection accuracy measurably. Pick the 10 that map to real shopper intents and leave the rest for internal automation.

Skipping PKCE and audience validation

I have seen teams ship servers with Bearer tokens that have no audience claim and no PKCE on the auth flow. That is a token-replay vulnerability waiting to be exploited the moment any single downstream service is compromised. Follow the spec.

Using synchronous tools for long operations

Bulk imports, catalog syncs, and report generation should use the experimental Tasks primitive or return a poll URL, not block the tool call for 45 seconds. Hosts will time out, and you will return 504s that look to the agent like tool failure.

Launching without observability

You cannot improve agent performance against your store if you cannot see which tool calls succeed, which fail, and what arguments agents are passing. Treat MCP traffic as a first-class observability domain: tool name, scope used, latency, success, and structured error on every call, flowing into the same pipeline as your HTTP traffic.

FAQ: MCP Ecommerce

Is MCP ecommerce just a replacement for my existing API?

No. MCP ecommerce is an agent-facing abstraction that typically sits on top of your existing APIs rather than replacing them. Your mobile app, your storefront, and your third-party integrations still use REST or GraphQL. MCP ecommerce adds a new, AI-native surface without disturbing what already works. Most teams build an MCP ecommerce server as a facade service that translates tool calls into the right downstream API calls.

If my store is on Shopify and MCP is native, do I still need to do anything?

Yes, but less. Shopify handles the protocol plumbing, but you still need to clean up your product catalog so it is inference-ready (rich attributes, clear variant structure, Arabic and English descriptions), enable Agentic Storefronts, configure UCP handlers including Shop Pay, and decide which AI channels to surface in. The technical lift is smaller; the merchandising and data-quality lift is the same.

How do I add MCP ecommerce to a Salla or Zid store?

Build a facade MCP server as a separate service that authenticates against your Salla or Zid merchant credentials, exposes a curated set of tools (search, inventory, cart, order status), and handles OAuth for downstream clients. Deploy it on infrastructure you control (AWS Riyadh, Google Cloud Dammam, or a local provider for PDPL compliance) and register it as the MCP endpoint you give to agent platforms. Expect two to three developer-weeks for a solid v1.

Should I implement MCP, UCP, ACP, or all of them?

MCP is foundational; build that first because it is the transport your UCP and A2A integrations will lean on. UCP is the commerce-specific vocabulary, useful if you want native checkout on Google AI Mode and Gemini. ACP is narrower and ChatGPT-specific; evaluate it based on where your customers are. AP2 is the payments layer and comes in the moment you allow agents to authorize transactions. You do not have to ship all four on day one; ship MCP with read-only tools, then layer the rest based on which agent surfaces drive actual revenue.

How do I secure an MCP ecommerce server against prompt injection and malicious agents?

Defense in depth. Every tool validates its arguments against a Zod or JSON Schema before any business logic runs. Enforce scopes at the tool level, not only the transport level. Never trust the agent to pass a user ID; derive it from the OAuth token’s sub claim. Rate-limit per user and per tool. Log every tool call with its arguments and who invoked it. For write-intensive tools like checkout creation, require idempotency keys and a fresh cryptographic proof of user consent, which is exactly what AP2 is designed to provide.

What performance characteristics should an MCP ecommerce server target?

Tool calls in a healthy MCP ecommerce deployment should return under 500ms p95 for read operations and under 2 seconds for write operations; anything slower and agents will retry or time out. Your JWKS cache should hit on 99%+ of requests. Session state should be externalized to Redis or similar so you can scale horizontally. Plan for 10x to 50x the traffic of a typical REST API once agent adoption picks up in your vertical, because agents often make multiple tool calls per user intent during reasoning.

Are there Saudi-specific constraints I should plan for?

Four. PDPL compliance on any tool response that includes personal data. SAMA rules on payment initiation that typically require a human confirmation step before money moves. ZATCA e-invoicing requirements that your order-creation tools must respect. And bilingual Arabic and English product data so agents can serve both markets from the same catalog. None of these are MCP-specific; they are Saudi-specific, and they apply to your agent surface the same way they apply to your web storefront. The broader Saudi digital economy context frames why these constraints exist.

Conclusion: Ship the Server, Then Iterate

MCP ecommerce is not a speculative trend you can afford to wait on. The infrastructure has stabilized under the Linux Foundation, every major AI vendor has converged on the standard, and the commerce-specific layers on top (UCP, AP2, ACP) are live and accepting integrations. The competitive question is not whether agentic traffic will route through your store; it is whether your store is ready to receive it when it does. For Saudi merchants specifically, the combination of Vision 2030 digital commerce growth, Salla and Zid’s growing API maturity, and the SAMA and PDPL regulatory clarity creates a window where early technical investment compounds quickly.

My concrete MCP ecommerce recommendation: get a read-only server live against your catalog in the next 30 days. Do not wait for UCP, AP2, or ACP to stabilize further; they are designed to sit on top of MCP, not replace it. Start with search, product detail, and order status, measure agent traffic, then layer in cart and checkout tools once you understand the patterns. The engineering cost of MCP ecommerce is modest; the opportunity cost of being invisible to agentic traffic through the rest of 2026 is not.

---

Related reading:

• AI Shopping Agents Ecommerce: The Complete 2026 Guide to Agentic Commerce, Protocols, and How to Get Your Store Ready
• AI Agents for eCommerce: Automate Inventory, Customer Service, and Pricing in 2026
• Sovereign AI Saudi Arabia and the Saudi-First Customer Experience
• Generative Engine Optimization for Ecommerce
• Best AI Models and Agents in 2026
• Digital Wallets Saudi Arabia: Cashless Payment Guide

Sources: Model Context Protocol documentation (modelcontextprotocol.io), Anthropic MCP announcement and roadmap, Shopify Engineering (UCP architecture), Google Developers Blog (Universal Commerce Protocol), Universal Commerce Protocol specification (ucp.dev), Truto SaaS PM Guide (MCP adoption metrics), Mordor Intelligence (Saudi Arabia Ecommerce Market 2026), Salla and Zid platform documentation, Linux Foundation Agentic AI Foundation announcements, SAMA Open Banking program, Saudi Personal Data Protection Law (PDPL).