MCP: how to let an AI assistant use your shop — and what nobody asks about first
MCP lets an assistant call your stock lookup instead of guessing at it. The protocol is a week of work. Deciding what an assistant may see and do on behalf of a customer is the actual project.
Photo: free stock photography (Unsplash licence) — see imprint
An assistant that cannot look things up will invent an answer
Every chatbot built on a language model alone has the same failure mode: asked whether article 4471-B is in stock, it produces a fluent, confident sentence that has no connection to your warehouse. It is not lying — it was never given a way to look. The fix is not a better model or a longer prompt. The fix is giving the model a function it can call, and MCP is now the ordinary way to hand it one.
Model Context Protocol is a standard way to describe tools and data to an assistant: here is a function called stock_lookup, it takes an article number, it returns a number and a date. The assistant decides when to call it and gets back your real answer instead of a plausible one. That is the whole idea, and it is genuinely useful — stock, order status, delivery dates and product search stop being guesswork the moment they come from your database.
The protocol is the easy part — that is the trap
If you already have a working API, an MCP server in front of it is not a hard build. You declare a handful of tools, describe their arguments, wire them to endpoints you have had for years, and an assistant can use them. A competent developer gets a read-only server talking to a Shopware Store API in a week, most of it spent on writing tool descriptions that are clear enough for a model to choose correctly.
That ease is exactly why the projects go wrong. A week of work feels like a small decision, so it gets made like one — by a developer, in a sprint, without anyone senior asking what the thing is allowed to touch. Six weeks later there is a tool called create_order on a server nobody has audited, and the question of who authorised what has never been discussed. The engineering is small. The consequences are not proportional to the engineering.
Read-only first, and stay there longer than feels necessary
The single rule that saves the most money: an MCP tool that only reads cannot ruin your week. A wrong stock answer is embarrassing and correctable. A wrong order is a credit note, an angry buyer and a support thread. Start with the read side, run it against real customer questions for a quarter, and look at the logs before you let anything write.
The read-only phase is not a warm-up you skip when you are confident. It is how you find out that the model calls product_search with the customer name in the query field, or asks for stock on a variant identifier that your catalogue does not use. Those are cheap discoveries on the read side and expensive ones on the write side.
- Read: stock, price for this customer, order status, delivery date, product search.
- Write, but reversible: build a cart, prepare a quote, draft a return request.
- Write, and binding: place an order, change an address, cancel a delivery.
- Never: anything touching payment data, credentials or another customer's records.
The real question is whose customer the assistant is
An MCP server has no idea who is on the other end. It receives a call for order status on order 88421 and it will answer, because that is what you built it to do. Identity has to come from somewhere else — a token that belongs to one authenticated customer, minted for one session, that scopes every tool call to that customer's own data. If your tools take a customer ID as an argument, you have built a lookup service for anyone who can guess an integer.
This is harder in B2B than it looks, because B2B customers are not people, they are companies with roles. The apprentice in the workshop and the managing director both authenticate as the same account number, and one of them should not see the annual rebate agreement. Scoping in B2B means per-user, not per-account, and if your shop does not already model that, MCP will make the gap visible in an unpleasant way.
Plan for the assistant being wrong, because it will be
Tools remove hallucinated facts. They do not remove hallucinated judgement. The model can call stock_lookup correctly, get 0, and still tell your customer the part ships Tuesday because the conversation drifted that way. So log every tool call with its arguments and its result, keep those logs somewhere a support agent can read them, and make sure any binding action leaves a trail you can reconstruct three weeks later when someone disputes it.
And decide, in writing, what happens when it is wrong in your favour or against it. If an assistant quotes a price that is no longer valid, do you honour it? That is not an engineering question, and it is the one that ends up on someone's desk. Answer it before you launch, not during the first complaint.
| Tool | Access | Worst realistic outcome | Ship it when |
|---|---|---|---|
| product_search | Public catalogue | Irrelevant results | Day one |
| stock_lookup | Read, per customer | A wrong promise you must correct | Scoped token works |
| order_status | Read, own orders only | Data of another customer leaks | Per-user scoping is proven |
| build_cart | Write, reversible | Customer deletes a wrong line | After a quarter of read-only logs |
| place_order | Write, binding | Credit note, dispute, lost trust | There is a human confirmation step |
- MCP is worth doing because a tool call replaces a guess — that is the entire benefit.
- The week you spend on the protocol is not the project; the scoping decisions are.
- If a tool takes a customer ID as an argument, you built a data leak with good manners.
- Read-only for a quarter is not timidity — it is how the expensive mistakes stay cheap.
Frequently asked questions
It is a standard way to tell an AI assistant which functions it may call and what they expect. Instead of the model guessing whether something is in stock, it calls your stock function and reports the real number. Think of it as a menu of tools you hand the assistant — you decide what is on the menu, and everything not on it stays out of reach.
A read-only server on top of an existing API is roughly one to two weeks, including decent tool descriptions. Everything after that is the expensive part: per-user authentication, scoping rules, logging, and agreeing internally what an assistant may do on a customer's behalf. Budget the second part at several times the first, and be suspicious of anyone who quotes only the first.
You need it only if you want assistants to use that API without a custom integration per assistant. MCP does not replace your API — it describes it in a form models can discover and call. If your only consumer is your own chatbot, a hand-written function layer works fine. MCP pays off when you stop knowing in advance which assistant will show up.
Not yet, in most shops — and the honest answer is that you probably do not need it. The value is in the lookups, not the checkout. If you do it anyway, put a human confirmation between the assistant's intent and the binding order, cap the value, and log everything. An assistant that fills a cart and hands it over gets you most of the benefit with a fraction of the exposure.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer