What is MCP? The Model Context Protocol explained for e-commerce operators
Short answer: MCP is a standard plug. It lets an AI assistant ask questions of a system you already run — your order management, your accounts, your warehouse — and get the real, current answer back instead of a guess.
The problem it solves
An AI assistant on its own knows a great deal about the world and absolutely nothing about your business. Ask it how many of a SKU you have in stock and the honest answer is that it cannot know. So people paste. They export a CSV, paste a chunk of it into a chat window, ask the question, and get an answer about a snapshot that was already going stale when they copied it.
That is the gap. Not intelligence — access. The Model Context Protocol is the standard that closes it.
What it actually is
MCP is an agreed way for an AI client to discover and call tools. A tool is one specific, named capability with a defined shape: “search open orders”, “get stock levels for these SKUs”, “list customers”. A small piece of software — an MCP server — publishes the list of tools it offers, and the assistant picks the right one for the question you asked.
The analogy worth holding on to is the USB-C port. Before it, every device had its own cable and nothing worked with anything. The port did not make devices cleverer; it made them connectable. MCP is that for AI assistants and business systems.
The three parts
- The client. Where you type. Claude Desktop, Cowork, claude.ai — the assistant you are already using.
- The server. A small service that knows how to talk to one system, and exposes that system as tools. One per system: one for your order management, one for accounts, and so on.
- Your system. Untouched. The server reads it through the same API your other software already uses.
What MCP is not
It is not training. Your data is not absorbed into a model. The assistant asks a question, gets an answer, uses it in the reply, and that is the extent of it.
It is not a sync. Nothing is copied into a second database that then drifts out of date. Every answer is fetched when you ask.
It is not a dashboard. There is no new screen to learn and nobody has to be trained on a reporting tool. The interface is a sentence.
It is not automatically allowed to change things. What a server can do is exactly the list of tools it publishes, and nothing else. If no tool writes, nothing writes.
What it looks like over Linnworks
Concretely: someone in the office types “which open orders are more than three days old and what is holding them up?” The assistant recognises that as a job for the open-orders tool, calls it, gets the live list back from Linnworks, and writes the answer with the orders named. No export, no filter, no waiting for whoever owns the spreadsheet to come back from lunch.
Then you ask a follow-up, because you always do — “of those, which are for trade accounts?” — and that is the part no report has ever done well. Reports answer the question you anticipated. Conversation answers the one you actually have.
What you need to switch one on
A Linnworks.net account, a login for developer.linnworks.com to create the application credentials, a free Cloudflare account to run the server in, and Node 18 or later on the machine you deploy from. Four secrets go in, one deploy command goes out, and the connector is live in your own account.
If you would rather not write it, the Linnworks MCP server source is the connector we run against our own warehouse — complete TypeScript for Cloudflare Workers, deployed to your account with your credentials. The documentation walks the whole setup.
Where to start
Start read-only and start with questions you already ask weekly. If the answers are right and arriving in seconds, you have a new habit. If they are not, you have learned something cheaply. More context: where to start with AI in a small business.
Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.