You hand Claude a contract to summarise without a second thought, so why does a question as small as where is my order still need three browser tabs and a stock spreadsheet?
That gap is what this article closes. I run IndiaNIC, where my team builds MCP servers and AI agents into other people's workflows, and in e-commerce I keep meeting the same situation. The assistant is trusted with words. It is not trusted with data. MCP for e-commerce is how a store gives an assistant safe, named access to the systems that actually run the business.
One honest framing before the design. What follows is an illustrative build, not a product you can install this afternoon. I am not going to tell you that your store platform already ships an MCP server, because the sources I checked do not say that.
Why an online store is the easiest place to start
A store runs on three questions asked over and over. Which orders are late? What is about to run out? What do I tell this customer who has been waiting since Tuesday? Every answer already exists, sitting in a different system behind a different login.
According to the Model Context Protocol documentation, MCP is an open-source standard for connecting AI applications to external systems, and the same page compares it to a USB-C port for AI applications. That comparison is worth keeping. A store does not need a private bridge for every assistant it may adopt next year. It needs one socket.
If the vocabulary is still new, the wider map is in my guide to how MCP servers, skills and plugins fit together, and the plain-English version is in what an MCP server actually is. The one sentence to carry forward comes from the specification itself: an MCP server is a program that provides context to MCP clients.
So why a store, rather than something grander? Because the value shows up by tomorrow morning. Nobody has to believe a slide deck. The owner asks one question in chat, gets a real answer from real data, and the argument ends there.
What would an MCP server for an online store actually do?
An MCP server for an online store would wrap three systems and expose each one as a named tool. Claude would call list_orders to find late shipments, check_stock to see what is running low, and draft_customer_reply to prepare an answer inside the helpdesk. Any tool that moves money or changes stock would stop and ask a human first.
The MCP architecture documentation sets out three server primitives: Tools, defined there as executable functions that AI applications can invoke to perform actions, plus Resources and Prompts. Underneath, the data layer speaks JSON-RPC 2.0 and the transport layer is either stdio for a local process or Streamable HTTP for a remote one. Your developer cares about that detail. You do not.
The three systems worth wrapping first
Start narrow, with one server for the boundary you understand best.
- The order database, read first. Order status, shipping dates, a customer's history with you.
- The inventory system, read before write. Stock on hand, incoming purchase orders, low-stock thresholds.
- The helpdesk, drafts only at the beginning. Open tickets, the customer's last few messages, and a reply the assistant has written but has not sent.
Small apparel brands are usually the first to ask my team about this, and their opening question is never about the protocol. It is always the same practical worry: can the assistant just issue the refund? My answer has not changed in any of those conversations. The assistant can prepare a refund perfectly, and it should never be the thing that finalises one. That single distinction is what separates a store server people keep from one they switch off within a fortnight.
Read-only tools first, write tools later
Here is the tool list I would sketch on a whiteboard for a first version. The last column is the only one that matters in week one.
| Start read-only. The expensive mistake is handing one server write access to orders, stock and payments in the first week, because a single wrong tool call then costs real money. Ship the read tools, live with them for a week, and add write tools one at a time. |
Which store actions need a two-step confirm?
Every action that changes money, stock or a customer's inbox needs a two-step confirm. The assistant drafts, a person approves, and only then does the action run. Reading an order, checking stock levels and searching tickets are safe to run freely. Refunds, cancellations, stock edits and outbound replies are not.
MCP has a place for this inside the protocol. The documentation lists Elicitation as a client primitive that allows servers to request additional information from users or ask for confirmation of an action. At protocol version 2026-07-28 that is the supported route, while Sampling and Logging are both marked deprecated.
We built the same pattern into mailman, our open-source MCP server for Gmail. It exposes 29 tools and no raw send tool at all. An assistant calls draft_email, a human reads the preview, and confirm_send is a separate call that only a person triggers. Nothing leaves the outbox until someone approves it, and a bulk run aborts at roughly a 25% failure rate instead of pushing on. That one design decision has saved us more embarrassment than any clever prompt ever has.
A tool that can spend a customer's money should never be one sentence away from spending it.
What a day with one store server looks like
Morning, around the time the first courier pickup is booked. The owner types a single line asking which products will run out this week and which orders shipped late yesterday. Two read-only calls answer it. No dashboard, no export, no filter.
Mid-morning brings a customer whose parcel is four days late. The assistant reads the ticket, pulls the order, sees where the courier scan stopped, and writes a reply that names the real delay instead of an apology template. The reply sits there as a draft. A support person reads it, changes one line, and sends it.
The afternoon is the interesting part. A customer asks for a refund on a returned jacket. The assistant checks the return, confirms the item arrived at the warehouse, and prepares the refund with the amount and the reason already filled in. Then it stops and waits. A person approves, and only at that point does the money move.
Each of those three steps would normally cost someone between ten and twenty minutes of clicking. That range is my own estimate from daily use of tools built this way, not a measured benchmark, and your numbers will land somewhere else.
What this design does not solve
Plenty, and pretending otherwise is how pilots quietly die.
- Bad data stays bad. If your stock counts are wrong in the warehouse, a tool that reads them faithfully will report the wrong number faster than before.
- A helpdesk still needs people. Customers want a human for the hard conversations, and an angry one is exactly where a draft reply is not enough.
- Slow APIs stay slow. If an order lookup takes nine seconds today, the assistant waits nine seconds too.
- Policy is still yours to write. Whether a refund is allowed after thirty days is a business rule, and somebody has to decide it before a tool can apply it.
Here is where I part company with most of what is written about AI in retail. The hard part of this project is neither the model nor the prompt. It is the approval map: a written list of what the assistant may do alone, what it must ask about, and what it may never touch. Teams spend their first month tuning prompts and their last week arguing about refunds, and that order should be reversed. If I am wrong about the sequencing, the cost is a fortnight of a project plan, which I will happily take over a wrongly refunded order.
How to start this week
- Write down the ten questions you or your team look up every day. Rank them by how often somebody asks.
- Pick the three that are pure reads and name them as tools. list_orders, get_order and check_stock is a perfectly respectable first server.
- Build it read-only, then use it for a full week, including a bad week with a courier problem in it.
- Add one write tool with a confirm step, and watch it for a month before you add the second.
Two places to look before your developer writes any code. The official reference servers repository publishes implementations you can read in an afternoon, among them Fetch for web content, Filesystem for file operations with configurable access controls, and Memory for a knowledge graph that persists between sessions. That same repository says you can browse published servers on the MCP Registry, which is the honest way to find out what exists today rather than trusting a vendor claim.
The conversation worth starting with your team this week is not a technology conversation at all. Sit down with whoever handles refunds and returns, and ask them which decisions they would hand over tomorrow and which they would keep for themselves. Write the answers down. That document is your real specification, and in 2026 the server is the easy half of the job.
Frequently asked questions
Do I need a developer to build an MCP server for my store?
Yes, for anything that touches your own order database or inventory. Someone has to write the server and give it credentials. A read-only first version is a small job, and the reference servers in the modelcontextprotocol/servers repository give your developer a working pattern to copy rather than a blank page.
Can an MCP server issue refunds without asking a human?
Technically yes, which is exactly why the design should forbid it. Keep issue_refund behind a two-step confirm, where the assistant prepares the refund and a person approves it. MCP supports this through Elicitation, the client primitive that lets a server ask a user to confirm an action before it runs.
Does my store platform already have an official MCP server?
Do not assume so, and do not take a vendor's word for it without checking. The reference implementations maintained by the MCP steering group are published in the modelcontextprotocol/servers repository, and that repository points to the MCP Registry as the place to browse published servers. Check the registry before you plan around a claim.
