MCP for Ecommerce: What I Exposed, What I Didn't

Once I had the product feed sorted, the next job was giving an agent a way to act on it. That means an MCP server: a set of tools an agent can call to browse, build a cart, and check out.

The interesting part was not writing the tools. It was deciding which ones to hand over at all. Because an MCP tool is a door, and every door you open is a door someone can walk through. So this post is about where I drew the line.

The mindset: tools are permissions, not features

Early on I thought of MCP tools as features — the more I expose, the more capable the agent. Wrong frame. A better frame: every tool is a permission I am granting to software I do not control.

Once I thought of it that way, the design got easy. The question for each tool stopped being "would this be useful?" and became "am I comfortable letting an agent do this, on its own, at 3am, with no human watching?" That question quietly sorts everything.

What I exposed

These are the tools an agent genuinely needs to shop, and that are safe to grant:

search_products — find items matching a query. Read-only. Safe.
get_product — full, fresh detail on one item, including the purchasable signal. Read-only. Safe.
check_availability — is this exact item buyable right now? Read-only, and the one agents call most.
create_cart / update_cart — build a basket. This changes state, but a cart is cheap and reversible. Low risk.
get_shipping_options — quote delivery for an address. Read-only.
start_checkout — begin a checkout session. Importantly, this starts the process; it does not move money by itself.

Notice the shape: almost everything is read-only or cheaply reversible. The agent can look all it likes, and build a cart, without anything irreversible happening.

What I did not expose

This is the more important list. These are things an agent cannot do through my server, on purpose:

No raw payment tool. The agent never gets a "charge this card" button. Payment goes through a scoped, single-use token and the proper authorization step — not a tool call the agent can fire at will.
No price or discount writes. An agent can read prices. It can never set them. That door stays locked, full stop.
No inventory writes. The agent cannot change stock levels. It reads the truth; it does not edit it.
No account or personal-data tools. No reading other customers, no changing account settings, no exporting data. None of that is the agent's business.
No bulk or admin actions. Nothing that touches many records at once. The blast radius of a confused agent has to stay small.

The rule underneath all of these: the agent can read freely, act narrowly, and never do anything irreversible without a real authorization step.

The checkout line is the sharpest one

The place I thought hardest about was checkout. It is tempting to give an agent a single "buy this" tool that does everything. Do not.

I split it. start_checkout sets up the purchase and returns what is needed for authorization. The actual money movement happens behind a separate step that requires a scoped token tied to one amount and one merchant — the kind of thing I will dig into in a future post on authorization. The agent can get right up to the payment, but it cannot be the payment. That separation is the whole safety model in one design choice.

Why this matters beyond my server

This is not just my preference. It is, I think, the right default for anyone building a commerce MCP server, and it is one of the principles going into Sarvex: give agents a clean, powerful read surface, a narrow and reversible write surface, and a hard wall in front of money and admin.

Get this wrong and you have handed autonomous software the keys to your store. Get it right and an agent is just a very fast, very literal shopper — which is exactly what you want it to be.

The short version

When you build a commerce MCP server:

Treat every tool as a permission, not a feature.
Expose read freely; expose writes narrowly and reversibly.
Keep payment, pricing, inventory and account data behind hard walls.
Split checkout so the agent can start it but never complete payment alone.

For how the catalog underneath feeds these tools, see the product feed post. For where MCP sits among the other protocols, see the protocol stack.

Next time: what happened when I let an agent run a checkout from end to end.