V každém e-shopu existuje databáze, která zná každý produkt do posledního detailu. A pak existují lidé — obchodníci, pracovníci podpory, kolegové z marketingu — kteří tuto databázi potřebují, ale nemají ji v hlavě. Pokaždé, když přijde dotaz na konkrétní produkt, otevřou admin, přihlásí se, proklikají se na správné místo a najdou odpověď. Pak zavřou záložku a postup se za hodinu opakuje.
Práce, kterou nikdo nechce dělat
Není to složitá práce. Ale je to pomalá práce. Přihlášení do adminu trvá třicet sekund, orientace v katalogu dalších třicet, a pokud hledáte konkrétní SKU nebo variantu produktu, snadno se dostanete na dvě minuty za dotaz. Při deseti dotazech denně jsou to dvacet minut ztracených ne na myšlení, ale na klikání.
U středně velkého e-shopu s tisíci položkami v katalogu a týmem pěti lidí v zákaznické podpoře a obchodu se tento čas sčítá do hodin za týden. Nejde o chybu platformy — Shoptet nebo Upgates fungují dobře. Jde o to, že administrační rozhraní je navržené pro správu katalogu, ne pro rychlé prohledávání za pochodu.
„Přihlásím se, vyhledám, zkopíruju číslo, přepnu tab, vložím — a pak totéž za dvacet minut pro jiný produkt."
— Pracovník podpory, e-shop s elektrem, průměrný pracovní den
Co to znamená v praxi: Claude s přímým přístupem ke katalogu
AI stack postaví mezi Claude a vaši produktovou databázi jeden MCP server. Server má čtecí přístup ke katalogu — produkty, varianty, skladové stavy, ceny, popisy, kategorie. Ale přistupuje k nim pod vaší identitou a s vašimi oprávněními. Claude nikdy nevidí víc, než by viděl člověk, který se ptá.
Výsledek: obchodník napíše do Clauda „Kolik kusů černé verze modelu XY ve velikosti L máme na skladě?" a dostane odpověď do pěti sekund. Žádné přihlašování. Žádné přepínání tabů. Katalog zůstane tam, kde je — přibyde pouze čtecí vrstva, která ho zpřístupní přirozeným jazykem.
Konkrétně: Shoptet nebo vlastní databáze
Většina středních e-shopů na českém trhu běží na Shoptetu, Upgates nebo vlastním řešení s SQL databází v pozadí. MCP server se napojí na produktové API nebo přímo na databázi — katalog zůstane přesně tam, kde je, nepřesouvá se nikam, nekopíruje se do žádného externího systému. Jeden MCP server zvládne katalog s desítkami tisíc položek; pro ilustraci: e-shop s pěti tisíci SKU a denním objemem padesáti interních dotazů může ušetřit odhadem dvě až tři hodiny týdně jen na čase stráveném prohledáváním.
- Dotaz přirozeným jazykem: „Jaká je nejlevnější varianta produktu X s dopravou zdarma?" — Claude prohledá katalog a odpoví.
- Porovnání variant: „Jaký je rozdíl mezi modelem A a modelem B v kategorii zahradní technika?" — bez ruční navigace v adminu.
- Skladová dostupnost: „Které produkty z kategorie zimní obuv mají skladem méně než deset kusů?" — přehled v jedné větě.
- Interní onboarding: nový obchodník se nemusí učit strukturu adminu, aby našel číslo produktu nebo EAN kód.
- Podpora zákazníků: pracovník odpoví na specifický technický dotaz během hovoru, aniž by zákazníka přepínal nebo žádal o chvilku.
Ilustrativní případ: menší český e-shop s elektronikou, tříčlenný tým podpory. Každý den vyřídí přibližně třicet interních dotazů na produktové specifikace — dostupnost, kompatibilitu, varianty. Před napojením MCP serveru odhaduje vedoucí podpory průměrně čtyři minuty na dotaz. Po nasazení bridge: odpověď do deseti sekund, bez přihlašování. Celkem ušetřeno přibližně hodinu a půl denně — čas, který tým přesunul na složitější tikety.
Co AI katalogové vyhledávání neudělá — a proč je to dobře
Claude prostřednictvím MCP serveru katalog čte. Necení. Neobjednává zásoby. Nepřidává produkty. Nepublikuje úpravy. Každá změna v katalogu — nová cena, nový produkt, aktualizovaný popis — vyžaduje člověka s editačními právy v adminu.
Tato hranice není nedostatek — je to záměr. Bridge je navržen tak, aby byl spolehlivý pro každodenní provoz bez dohledu. Pokud by mohl zapisovat, potřeboval by schvalovací proces, audit trail, rollback mechanismus. Čtecí vrstva nic z toho nepotřebuje — a přitom odstraní devadesát procent friction, kvůli které lidé do adminu chodí.
Co by to obnášelo
Nasazení bridge nevyžaduje migraci dat, novou platformu ani roční projekt. MCP server se připojí k vaší stávající produktové databázi nebo API katalogu — Shoptet, Upgates, vlastní SQL — a běží na vaší infrastruktuře. Vaše data nikam neodcházejí, nekopírují se do žádného externího cache. Identita a oprávnění každého uživatele se přenášejí přes bridge: obchodník vidí, co smí vidět obchodník; pracovník podpory vidí, co smí vidět pracovník podpory.
Co zbývá
Model není bottleneck. Claude umí prohledat katalog s desítkami tisíc položek rychleji a přesněji, než to zvládne člověk proklikávající admin. Bottleneck je gap mezi Claudem a vaší produktovou databází — ta mezera, přes kterou se musí každý den přihlásit, proklikat a odpovědět. Tuto mezeru zavíráme.
Pokud máte e-shop a tým, který denně hledá produkty v adminu, napište nám. Krátký hovor stačí na to, abychom odhadli, jak velký je váš katalog, kde bridge sedí nejlépe a co by nasazení obnášelo. Žádný dlouhý projekt, žádná migrace — jen čtecí vrstva, která zpřístupní katalog všem, kdo ho potřebují.