PlatformDTC

Agentic commerce

What is MCP and what does it do for ecommerce?

Updated

MCP — the Model Context Protocol, published by Anthropic — is an open specification for how an AI agent discovers what tools it can call and then calls them with typed arguments. In ecommerce it is the mechanism by which an assistant learns that your store exposes operations like "search catalog", "create draft order" or "issue refund", and invokes them directly instead of simulating a human clicking through an admin UI. The protocol carries no permission model of its own, so scoping and audit are the merchant platform's responsibility.

What MCP is, precisely

MCP standardises the handshake between an agent and a tool provider. A server advertises a set of tools, each with a name, a description and a typed schema for its arguments. An agent connects, reads that list, and calls what it needs. That is genuinely the whole idea, and its value is in being boring and universal rather than clever.

It is not a commerce protocol. It says nothing about carts, prices, feeds or payment authorization. It is the layer beneath those: how the agent finds out that a commerce capability exists at all. ACP's April 2026 revision leans on exactly this, including a hook so ACP-aware agents can advertise checkout capability through MCP tool discovery.

What a commerce MCP server should expose

The tempting design is to mirror your REST API one-to-one. That produces a server with hundreds of tools, and agents choose badly from long lists of near-identical options.

The better design is to expose operations at the altitude a human operator would describe them, with the platform doing the orchestration underneath. "Launch a campaign with this budget against this audience" is one tool. The six API calls it decomposes into are not six tools.

  • Read operations — catalog search, order lookup, inventory levels, customer history, analytics queries. Safe, high-value, and where most agent usage actually lands.
  • Draft operations — build a draft order, prepare a discount, compose a campaign. Produce a reviewable artifact rather than a committed change.
  • Commit operations — publish, charge, refund, ship. These are the ones that need a gate.
  • Introspection — let the agent ask what it is permitted to do. An agent that can read its own scopes stops attempting calls it will be denied.

The part the protocol does not give you

MCP defines discovery and invocation. It does not define who is allowed to call what, what happens when the same call arrives twice, or how you reconstruct after the fact what an agent did and why. Those are the properties that decide whether an agent touching a live store is an asset or an incident, and every one of them is the platform's job.

Four controls are non-negotiable before an agent gets a key that can spend: per-key scopes so a key can be granted read-only or a narrow slice of write; idempotency so a retried call cannot double-charge; a durable audit record tying every action to the calling key and the initiating request; and an approval gate that stops money movement pending human sign-off.

PlatformDTC implements those four in the Agent Gateway and exposes the same operations over MCP, so the safety model does not depend on which transport the agent used to reach it.

Frequently asked questions

Is MCP a competitor to ACP or UCP?
No — it sits beneath both. MCP handles tool discovery and invocation generally; ACP and UCP specify commerce semantics like feeds, carts and checkout sessions. ACP explicitly integrates with MCP so agents can discover checkout capability through MCP tool listing.
Can I expose my Shopify or other platform admin through MCP?
You can put an MCP server in front of any API you control. The hard part is not the protocol binding, it is everything the platform underneath does not give you: scoped credentials narrower than a full admin token, idempotency on writes, and an audit trail attributing actions to an agent rather than to the app that owns the token.
What stops an agent from doing something destructive?
Nothing in MCP itself — that is the point worth internalising. The controls have to live in the server: scopes that make the destructive call unavailable to that key, an approval gate on irreversible actions, and idempotency so a retry storm cannot multiply an effect. Treat an agent key as you would a third-party integration key, not as a trusted internal caller.

Sources

Related