MCP for e-commerce: giving agents a safe way to shop and sell

The Model Context Protocol (MCP) is a specification for how an AI agent discovers what tools exist and calls them. For e-commerce, it’s the difference between an agent scraping your storefront and an agent being handed a menu of exactly what it’s allowed to do.

What MCP actually is

Under the hood MCP is not magic. An MCP server advertises a list of tools — each with a name, a description, and a typed schema for its inputs and outputs. An agent connects, reads the list, and calls the tools it needs. That’s the whole shape of it. The value isn’t novelty; it’s standardization. Any MCP-speaking agent can use any MCP server without a bespoke integration written for that one model.

If you’ve built a REST API, your first instinct is “so it’s REST with extra steps.” Not quite. A REST API documents itself to humans, who then write client code. MCP documents itself to the agent, at runtime, so the model can decide which tool fits the task it was given. The tool descriptions are prompt material, not just developer docs. Writing them well is closer to writing good error messages than writing OpenAPI.

Why a store is a good fit — and a sharp risk

A store is a natural set of tools: search products, get a product, add to cart, start checkout, look up an order, file a return. Each maps cleanly to an MCP tool. That’s the appealing part.

The risk is that an MCP endpoint is a door an autonomous program walks through without a human reading the screen first. Three things have to be true before that door is safe to open:

• Auth is the same as everywhere else. The MCP tools must run through the identical authentication and role checks as the human UI. If refund_order is exposed as a tool, it must demand the same permission a staff member needs to click Refund. A separate, weaker “API auth” path is how stores get robbed.
• Scope is explicit. Buyer agents and merchant agents are not the same actor and must not share a tool registry blindly. A shopper’s agent should never even see set_price.
• Every call is logged and idempotent. Retries are normal in agent land. Without idempotency keys, a flaky network turns one order into three.

These are the same properties that make agentic commerce work at all. MCP is the transport; the discipline underneath is what keeps it from being a liability.

Two endpoints, one registry

The pattern that has held up best is to expose two MCP endpoints backed by one shared tool registry:

• /mcp/customer — cookie-authenticated, for buyer agents acting as a signed-in shopper. Read the catalog, manage a cart, check out, track an order, open a return.
• /mcp/admin — scoped API key, for merchant agents. Catalog edits, pricing within guardrails, return triage, bulk operations — each gated by the same role-based access control the human admin uses.

Because both endpoints draw from the same registry, a capability the UI gains is a capability the agents gain, with no drift between what a human can do and what a bot can do. That symmetry is the point: one set of rules, enforced once.

Don’t forget the agents that don’t speak MCP

MCP is young. Plenty of automation will hit your store over plain HTTP for years yet. A pragmatic setup keeps a conventional OpenAPI surface alongside the MCP endpoints, and publishes a /llms.txt so even a model with no tool-calling can find its way around. Betting the whole integration story on one protocol is the kind of purity that ages badly.

Where Wardenclyffe lands

The Wardenclyffe AI Engine ships the two-endpoint MCP pattern above as a built-in, not an add-on, with tool auth wired straight into the same identity and RBAC the storefront and admin use. It also exposes OpenAPI and an /llms.txt for the non-MCP world. Because it’s self-hosted and source-available, you can audit exactly how a tool call is authorized before you let an agent anywhere near your orders — which, for a door that autonomous software walks through, is the only responsible way to run it.