People searching for "MCP server Rohlik" usually want one of two things: to know whether they can shop through an assistant, and to know what it means for their own company. The first question belongs to the shop. The second is the interesting one, because it touches something you control: the ordering that runs through mail, a spreadsheet and one person who holds it all together.
The work nobody wants
In a smaller company the weekly order looks like this. Three separate emails, each from someone different: we are out of coffee, we need 40×30 boxes, somebody reorder those gloves. Next to that sits a stock spreadsheet last honestly reconciled with the storeroom sometime in spring. And there is the supplier account, whose order history already contains 80 percent of the answer.
Someone opens all of it across three windows and starts retyping. They compare it with last time, check whether pack sizes changed, add the two items requested verbally in the corridor, and send. Days later the invoice arrives and its lines have to be matched by hand against what actually turned up. None of this is hard. It just repeats every week in exactly the same shape and never goes away.
Forty line items, three emails and one spreadsheet that never agrees with the storeroom.
— A weekly order, abridged
What MCP actually means
MCP is an open standard published by Anthropic in late November 2024. It solves one specific thing: how to describe a system so an assistant can work with it, without writing a bespoke one-off integration for every system. The analogy that fits is a socket. It is not a new power station, it is a standard connector you can reliably plug something into.
An MCP server offers a handful of named actions and nothing more: find a product in the catalogue, return order history, add a line to the basket. Claude calls those actions, and it calls them under the identity of the person asking. The specification treats authorization as part of the design, not as something taped on later. Whether a particular shop runs a public MCP server is a question for that shop. What we deal with here is the other end of the bridge, yours.
Concretely: the order that runs through a supplier e-shop and Pohoda
Nothing you already have changes. The supplier account stays yours, the stock spreadsheet stays where it is, the invoice lands in accounting as before. The only new thing is the bridge: a small server that knows four or five clearly bounded actions. The scope really is small, because nobody is building a new purchasing system, only opening the one you already use.
- Reads the requests out of mail and the spreadsheet you already keep.
- Compares them with current stock and with what was ordered last time.
- Assembles a draft basket in the supplier account, under the identity of whoever asked.
- Lists the differences against the previous order, so there is something to check.
- After delivery, matches the received lines against the invoice in accounting, in Pohoda for example.
Picture a bistro with two locations where the manager places the order every Tuesday after closing. Connected, that operation would find a draft waiting on Tuesday morning: what is running out, what was ordered last week, what got more expensive. What is left is reading the list and sending it. This is an illustrative example rather than a measured case, but the shape of the work is the same everywhere.
What Claude will not do with your orders, and why that is good
It will not send an order without approval. It will not raise a purchase limit, because it has no way to: limits live in your system and the bridge only respects them. It will not invent a product it cannot find in the catalogue, and when it is unsure it says so instead of guessing. Above all, it does not decide whether this year you buy two hundred boxes or three hundred.
That boundary is not a limitation we apologise for. It is the reason the arrangement is worth trusting. At the moment money leaves the company, a named human should be standing there. The bridge prepares the ground so that decision takes two minutes instead of forty.
What it would take
An afternoon on how an order really comes together in your company, who is allowed to send it, and where the invoice ends up. Then one small server running on your infrastructure, under your access, with an audit trail showing who asked what and what happened next. It is not a year-long project and it does not start by replacing systems that already work.
What is left
The model is not the bottleneck. Claude can assemble and compare an order far better than this job requires. The bottleneck is the gap between it and the data you already hold: the requests in mail, the stock sheet, the supplier history, the invoices in accounting. As long as someone crosses that gap by hand, they cross it again every week.
Closing that gap is what we do. Write to us, a short call is enough to walk through your ordering week and say where the bridge would run and what it would report back first.