An MCP server for your store, or AI with access to real data

The problem you do not see at first

The first approach to AI in e-commerce usually looks the same everywhere. Somebody exports last quarter’s orders into a spreadsheet, pastes them into a chat and asks for an analysis. The answer is often genuinely good, so the routine sticks: an export every month, a paste every month, the same questions every month.

Trouble shows up around the third or fourth repetition. An export is a snapshot of one moment, so every answer describes the past rather than what is happening now. The file usually carries more data than the question required, including customer names and addresses nobody consciously meant to send anywhere. On top of that, each new question needs a new export, because the model has no way to reach for the missing piece itself.

As soon as the questions become regular, it pays to reverse the direction. Instead of sending data to the model, give the model a way to ask for data when it needs it, and only for the part the question is about.

What MCP actually is

The Model Context Protocol is a standard way of describing which operations an application exposes to a language model. An MCP server publishes a list of tools, each with a name, a description and a set of parameters, and the model on the other side decides which of them to call in order to answer the user. Instead of pasting a table of orders, you ask about last week’s results, and the model reaches for them through a tool built to calculate sales.

The key difference from a classic integration is who arranges the sequence of steps. In the traditional approach a developer decides up front that clicking a button fetches orders, filters them and sums them up. With MCP you describe only the available operations, and their order and selection follow from the question somebody has just asked. A question about the best selling product in a category and a question about a customer who stopped buying are built from the same blocks, arranged differently.

On the CS-Cart side, such a connection requires no rebuild of the store. Our MCP server is a separate service that talks to the store over the REST API, so it does not touch platform code and does not change its behaviour. That has a practical consequence for older installations: since communication goes through the API, the PHP version of the store itself stops being an obstacle, and the server works with stores still running on PHP 7.4.

What you can ask this way

The set of tools decides what the model is able to see at all, and that is a design decision rather than a configuration detail. In our server the read tools cover the catalogue and categories, product details including the stock keeping code and weight, reviews, orders filtered by status, e-mail address and period, the details of a single order, abandoned carts, customer data together with a summary of their purchases, store statistics for a chosen period and a sales ranking. A separate, small tool simply checks whether the store responds and how quickly.

The practical questions that follow tend to sound very ordinary. Which products sold best last month in a given category. Whether the customer who has just written to support has bought before and what exactly they ordered. How many orders have been waiting for payment for more than a week. The difference from panel reports is that you phrase the question in a sentence rather than in a form, and that the next question can dig into the previous one without clicking through from scratch.

The two write tools, changing an order status and setting stock levels, are disabled by default in our server. Enabling them takes a deliberate configuration change, and until you make it they do not appear on the list the model can see at all. This asymmetry is intentional: reading the wrong data is a problem, but writing the wrong value is an incident.

Security, the place where it is easy to fall over

Connecting a model to a store moves the trust boundary. Until now data left the store when a human deliberately clicked export. Once connected, it leaves when the model decides it needs it for an answer. That is why a few things have to be settled before anything goes live.

The first is authentication, and making sure it cannot be skipped by forgetting about it. In our implementation the server does not start at all without a token configured, so there is no state in which it runs open to everyone. Tokens are named, you can issue a separate one for each client on the other side, and none of them sit on the server’s disk, only their cryptographic hashes. On top of that comes a list of allowed domains, with connections from anywhere else rejected.

The second is the account the server uses to talk to the store. Plugging in an existing administrator key is tempting, because it is one thing less to do, but then the model’s reach equals an administrator’s permissions. A dedicated API user, without the right to delete orders or manage accounts, takes fifteen minutes and closes the subject.

The third is knowing where the content of an answer ends up. The MCP server itself has no database and copies nothing, but the data the model asks for passes through that model. If it runs in a vendor’s cloud, that is exactly where the slice of data needed for the answer will go. If your data cannot leave the company, the conclusion is simple and concerns the model rather than the protocol: it has to run locally.

The fourth is an audit trail. Every write is worth logging with the value before and after the operation, because when somebody asks why an order has a different status, the answer “the model changed it, at this hour, from this value to that one” is the only one that ends the discussion.

What such a server will not do

An honest list of limitations matters more than a list of features, because it is the one that decides whether you are disappointed a month later. A single server instance serves a single store, so several stores mean several instances. In Multi-Vendor a seller asking with their own key gets data narrowed to their own company, but will not see abandoned carts at all, because the CS-Cart database does not tie a cart to a seller, and that is a core limitation rather than an integration one.

The model will not replace accounting reports either. It answers on the basis of what the tools return, so it is good at exploration and analysis and weaker at figures that must match to the cent in an official document. Store reports and your accountant still handle that part.

Where to start

Start by writing down the questions you actually ask, or would like to ask. It usually turns out there are three or four of them and that all of them are about reading. That is enough to judge whether the available tools cover them at all, and to decide whether you need write access or not.

Then decide where the model runs, because the answer about data confidentiality follows from that. Only at the end deal with deployment, tokens and the API account, because that is the simplest and best documented part.

If you would like to see how this works on your own data, get in touch. The server code is open, so you can run it yourself, and we handle deployment, hosting and maintenance for those who would rather have it off their desk. Both routes are described on the MCP server page.