Your CS-Cart store
within reach of AI models
The MCP server is a translator between a language model and your store. The model asks about products, orders and customers in a plain sentence, the server turns that question into a store API call and hands back a ready answer. It runs as a separate service beside the store, so you install nothing inside CS-Cart and touch none of its code.
- Twelve read-only tools, writing disabled by default
- Ready for n8n and for a local MCP client
- The PHP version of the store does not matter, 7.4 included
What the MCP server gives you
A single service that opens up store data to automations and assistants, without handing them the right to change anything.
A store you can simply ask
Instead of clicking through the panel and assembling a report by hand, you ask an assistant about stock levels, recent orders or last week's revenue. The server fetches the data from the store and hands it to the model in a form it understands.
Separate from the store, with no code changes
The server stands next to the store and talks to it through the public REST API. Because of that the PHP version of the store itself is irrelevant, and older installations on PHP 7.4, where modern libraries simply could not run, are covered too.
Analytics the store API does not have at all
The CS-Cart core API returns neither sales broken down by product, nor a single customer's spending, nor a ready revenue total. Our ss_mcp store add-on gives it four read-only entities that work all of this out in a single query, using the very core functions the admin panel relies on. The server reaches for them whenever the store has them, and when it does not find them it falls back to the slower route and says so plainly in the answer.
Reading by default, writing behind a switch
The twelve tools the model receives on connection only read. The two writing tools, changing an order status and correcting a stock level, do not appear on the list at all until an administrator turns them on with a separate switch. A model will not reach for a tool it does not know exists.
Named access tokens
Without a configured token the server will not even come up over HTTP. Tokens are named, so you can issue a separate one for each tool and revoke a single one without touching the rest, immediately and with no restart. Only their cryptographic hashes are stored on disk, never the tokens themselves.
Ready for n8n
The server exposes two transports. Streamable HTTP serves remote clients, n8n among them, while standard input and output stays for a local client that launches the server as its own child process.
An intermediary, not a data store
The server has no database and copies no store content into itself: it fetches what you ask for, hands it to the model and that is the end of it. The whole configuration goes through environment variables, so the same Docker image will serve another store with no rebuild.
Questions you can ask
Every one of these means logging into the panel, setting a filter and reading a table today. With the server connected you just ask in a plain sentence, and the answer is built from data fetched at that very moment.
- How many orders came in yesterday and for what amount?
- Show me orders that have been awaiting payment for more than three days.
- Which carts were abandoned in the last twenty-four hours and do we have e-mail addresses for them?
- What did jan.kowalski@example.com order and to which address?
- How many units of this product are left in stock and what is the price?
- What ratings did this product collect and what exactly do customers write?
- What categories do we have and how many products sit in each of them?
- What sold best this month and for how much?
- How did we do against the previous month?
- How much has this customer spent with us and what do they buy most often?
The answers come from your store, fetched at the moment the question is asked. The model does not guess, it reads. The last three questions are answered with figures worked out inside the store itself, by the ss_mcp add-on, because the core API exposes no such totals.
The tools the model gets
The model does not get a free hand in the store. It receives a closed set of tools with a fixed scope, and that is all it can do. The first twelve only read and work straight away, the last two write and are disabled by default.
health_check Connection check
Checks whether the store responds and measures the response time. The first tool to reach for when something needs diagnosing.
get_products Product list
Name, price, stock level and status. The basis for questions about availability and about what is missing from the shelf.
get_product_details Product details
The complete data of a single item: the stock code, both prices, the weight and a description stripped of HTML markup.
get_categories Category tree
The store's category structure together with the product count in each of them. This is how you know where the assortment is growing and where the shelf is bare.
get_product_reviews Product reviews
The ratings and the text of the comments on a chosen product. Reviews come from the reviews add-on, so a store without it gets a note about its absence instead of a list.
get_orders Order list
Orders filtered by status, customer e-mail address and period. This is where answers about what happened in the store yesterday come from.
get_order_details Order details
The order lines, the amounts, the customer data and the shipping address, meaning everything needed to answer a question about one particular case.
get_abandoned_carts Abandoned carts
Carts left untouched for longer than a given time, one hour by default, together with their contents and a contact if the customer left one. In a store running the ss_mcp add-on, a customer standing at the checkout right now drops off the list, and a guest's cart can be found by their address.
get_customer_info Customer data
A customer found by e-mail address or user number, together with the data support needs.
get_customer_summary needs the ss_mcp add-on Customer purchase summary
How much a customer has spent, how many orders they placed, when they last bought and what they buy most often, in a single answer. The core API works out no such total, so without the add-on you would have to fetch all their orders and add them up yourself.
get_store_stats Store statistics
The product count, the order count and the revenue for a chosen period. In a store running the ss_mcp add-on the store works the revenue out itself, and the answer gains a comparison with the previous period together with a ready difference in both amount and percent.
get_top_products needs the ss_mcp add-on Product sales ranking
The best selling products in a period, with unit counts and sales value, optionally narrowed to a category. Product variants count separately. Sales broken down by product is something the core API does not expose at all.
update_order_status write, off by default Order status change
Moves an order to a chosen status. Available only after writing has been deliberately enabled, and the change made goes to the log together with the status from before the operation.
update_product_stock write, off by default Stock level correction
Sets a product's stock level to a given value. It likewise requires writing to be enabled, and the log keeps the level from before the change and after it.
Periods in queries about orders and statistics are given with CS-Cart codes, from today and yesterday through to last year. Status names are not hardcoded in the server, because stores add their own: it reads them straight from the store and returns them next to the code. The writing tools are enabled with a single environment variable, and every write goes to the server log with the value before and after the change. The two tools marked with the add-on work out what the core API does not expose at all, so without ss_mcp they answer with a note about its absence rather than a figure pulled out of thin air.
The limits we state upfront
Each of these constraints would surface on first serious use, so we would rather say them now than explain them later.
Without the add-on, revenue is calculated from fetched orders
The store's core API returns no ready sales total, so on that route revenue is built from the orders fetched for a given period, at most five hundred of them, and the answer states plainly whether the sum covered them all. The limit disappears in a store with the ss_mcp add-on, because then the figure comes from the store itself, in a single query and regardless of how many orders the period holds.
Without the add-on, an abandoned cart is our judgement, not a store state
CS-Cart records no abandonment status, so without the add-on we count it from the cart's idle time, one hour by default, and return the threshold used alongside the answer. The criterion is weak then, because the list also catches a customer who has just come back to an old cart and is standing at the checkout. The ss_mcp add-on turns this into an answer from the store, where a cart has to be both old and without an owner present in the store at that moment.
Reviews depend on the reviews add-on
Product comments and ratings come from an add-on, not from the store core. A store without it gets a note about its absence in the answer, instead of an empty list pretending there are no reviews.
One instance serves one store
The API address, the user and the key are the configuration of one instance, so a second store means a second instance. The same Docker image will serve it with no rebuild, but the separation is deliberate here, because it keeps store data apart.
In Multi-Vendor a vendor will not see carts
A vendor asking with their own API key gets sales statistics, a product ranking and a customer summary narrowed strictly to their own company. Abandoned carts are closed to them permanently, and that is not caution on our part but a consequence of the database: in Multi-Vendor a cart has no field tying it to a vendor, so it cannot be honestly attributed. The store core has exactly the same limitation here.
Pricing
The server code is open and free. You pay for keeping it running: for hosting, deployment, updates to new CS-Cart versions and support.
Hosted instance
For a store that wants a working MCP server right away, without its own Docker and without maintaining yet another service.
per month · net
Setup from 800 PLN, one-off
- An instance on our infrastructure, with its own address and certificate
- API key configuration on your side and tests against your store
- Updates for new CS-Cart versions
- Ready-made n8n workflows to start with
- Support whenever the connection gives trouble
Self-hosting
For a company with its own infrastructure that prefers to keep the service in-house, next to the store.
for the server itself · net
Deployment and support billed hourly
- Open server code, with no licence fee
- Docker, or PHP 8.1 with the curl and json extensions
- Deployment and team training billed hourly
- An optional support contract with a fixed yearly fee
- Public documentation and a package for running it yourself
Net prices. A yearly contract lowers the subscription. Self-hosting costs nothing, and that is the point of the open core model: the code stays open, while deployment, maintenance and support are paid.
Frequently asked questions
What exactly is MCP and why would my store need it?
The Model Context Protocol is an open standard that AI assistants use to talk to outside systems. Without it a model knows only what you paste into the chat window. With an MCP server it can reach for store data itself and answer a question about a specific order or about stock levels, and an n8n automation can do the same without writing an integration from scratch.
Can the server change anything in my store?
By default it cannot. The twelve tools the model receives on connection only read. Writing does exist, today as an order status change and a stock level correction, but it is switched off with a single environment variable and such tools do not appear on the list visible to the model at all. Turning them on is your deliberate decision, and then every change goes to the server log with the value from before the operation and after it.
Where does my customers' data go?
The server is an intermediary, not a warehouse. It has no database and copies no store content into itself: it fetches what you ask for, hands it to the model and that is the end of it, while all that stays on the instance disk are token hashes and technical session files. The data you ask about does reach the model you use, so during the rollout we settle which model that is and which questions are meant to be asked at all. If personal data must not leave the company, there is the option of a model running on your own infrastructure, because the protocol is open and ties you to no provider.
What is the ss_mcp add-on and do I have to install it?
It is an add-on for the store itself, extending its REST API with four read-only entities. You do not have to have it: without it the server works and answers every question except two the core API cannot work out at all, namely the sales ranking and a customer's spending summary. The rest of the difference is a matter of accuracy and speed, because without the add-on we build revenue from fetched orders and judge cart abandonment by idle time instead of asking the store about it. The add-on changes nothing in the store and collects nothing, it only computes on data that already sits there, and switching it off in the panel is safe, because the server simply falls back to the slower route.
Do I have to upgrade PHP or install anything in the store?
You do not. The server runs as a separate service and connects to the store through its public REST API, so the store's PHP version is irrelevant and installations on PHP 7.4 are covered as well. All you need on your side is a panel user with API access and their key.
Will this work on Multi-Vendor?
It will, and we checked that on a working Multi-Vendor installation, not merely in the sources. A vendor's API key sets their company context by itself, so whoever asks with their own key gets sales statistics, a product ranking and a customer summary worked out from their orders alone. The marketplace owner sees everything, and can switch any of those three off for vendors with an ordinary permission in the panel. One limitation stays: a vendor will not see abandoned carts, because the store database ties no cart to a vendor, and the core has that same limitation.
Can I run the server myself, without your hosting?
Yes, and that is not a way around our model but a part of it. The server code is open, so with Docker or PHP 8.1 with the curl and json extensions you can set it up yourself. In that case we earn on deployment and support rather than on a licence.
What does access security look like?
On three levels. Over HTTP the server demands a token with every request and will not even start without one, and it rejects connections from outside the list of allowed domains. Then there is the store API key, issued to a separate user created for this service alone, with no right to delete orders or manage accounts, so even a leaked key opens no path to irreversible damage. Finally there is the scope of the tools themselves, in which writing operations are invisible by default.
What stage is the project at?
The server sits at version 0.9.0 and we say plainly what is in it. Both transports work, HTTP access is guarded by a named token, twelve read-only tools are verified against the API of working CS-Cart and Multi-Vendor installations, with Claude and n8n on the other side, and two writing tools sit there disabled. We also say the other half of the truth: the project is young and has no customer deployment yet, so the first agreements are made on early-entry terms. If you want a say in what gets built first, get in touch.
Let's talk about your deployment
Book a live demo or send us a question. We reply quickly and to the point.
office@cs-cart.com.pl · +48 661 661 964
SoftSolid · ul. Sportowa 14, 62-090 Rokietnica
NIP PL8421361047