Every e-shop has a database that knows every product down to the last detail. And then there are people — sales reps, support staff, marketing colleagues — who need that database but don't have it memorised. Every time a product question comes in, they open the admin, log in, click through to the right place, and find the answer. Then they close the tab. An hour later, the process repeats.
The work nobody wants to do
It's not difficult work. But it is slow work. Logging into the admin takes thirty seconds, navigating the catalogue another thirty, and if you're hunting for a specific SKU or product variant, you can easily spend two minutes per query. Ten queries a day — that's twenty minutes lost not to thinking, but to clicking.
For a mid-sized e-shop with thousands of items and a team of five in support and sales, that time compounds into hours per week. It's not a flaw in the platform — Shoptet or Upgates work well. The issue is that an admin interface is built for managing a catalogue, not for quick lookups on the fly.
"Log in, search, copy the SKU, switch tab, paste — then do it again twenty minutes later for a different product."
— Support agent, electronics e-shop, average working day
What it actually means: Claude with direct catalogue access
AI stack places a single MCP server between Claude and your product database. The server has read access to the catalogue — products, variants, stock levels, prices, descriptions, categories. But it accesses them under your identity and with your permissions. Claude never sees more than the person asking would see.
The result: a sales rep types into Claude "How many units of the black version of model XY in size L do we have in stock?" and gets an answer in five seconds. No logging in. No switching tabs. The catalogue stays exactly where it is — a read layer is added on top, making it accessible through plain language.
Concretely: Shoptet or a custom database
Most mid-sized Czech e-shops run on Shoptet, Upgates, or a custom solution with a SQL database underneath. The MCP server connects to the product API or directly to the database — the catalogue stays exactly where it is, not moved or copied to any external system. A single MCP server handles catalogues with tens of thousands of items; illustratively, an e-shop with five thousand SKUs and fifty internal queries per day might reclaim two to three hours per week just from time spent on catalogue lookups.
- Natural-language query: "What's the cheapest variant of product X that qualifies for free shipping?" — Claude searches the catalogue and answers.
- Variant comparison: "What's the difference between model A and model B in the garden equipment category?" — no manual admin navigation.
- Stock levels: "Which products in the winter footwear category have fewer than ten units in stock?" — a one-sentence overview.
- Internal onboarding: a new sales rep doesn't need to learn the admin structure to find a product number or EAN code.
- Customer support: a support agent answers a specific technical question during a call, without putting the customer on hold or switching screens.
An illustrative case: a small Czech electronics e-shop, three-person support team. They handle roughly thirty internal product queries a day — availability, compatibility, variants. Before the MCP server, the support lead estimates an average of four minutes per query. After deploying the bridge: answer in under ten seconds, no login required. Roughly an hour and a half saved per day — time the team moved to more complex tickets.
What AI catalogue search will not do — and why that's good
Claude reads the catalogue via the MCP server. It does not set prices. It does not order stock. It does not add products. It does not publish edits. Every change to the catalogue — a new price, a new product, an updated description — requires a person with edit rights in the admin.
That boundary is not a shortcoming — it's the design. The bridge is built to be reliable in daily operations without supervision. If it could write, it would need an approval workflow, an audit trail, a rollback mechanism. A read-only layer needs none of that — and yet it removes ninety percent of the friction that brings people to the admin in the first place.
What it would take
Deploying the bridge requires no data migration, no new platform, and no year-long project. The MCP server connects to your existing product database or catalogue API — Shoptet, Upgates, custom SQL — and runs on your infrastructure. Your data goes nowhere; it is not copied to any external cache. Each user's identity and permissions travel through the bridge: a sales rep sees what a sales rep is allowed to see; a support agent sees what a support agent is allowed to see.
What's left
The model is not the bottleneck. Claude can search a catalogue with tens of thousands of items faster and more accurately than a person clicking through the admin. The bottleneck is the gap between Claude and your product database — the gap that requires someone to log in, navigate, and answer every single day. That's the gap we close.
If you run an e-shop and have a team that looks up products in the admin daily, write to us. A short call is enough to gauge how large your catalogue is, where the bridge fits best, and what deployment would involve. No long project, no migration — just a read layer that makes the catalogue available to everyone who needs it.