MCP (Model Context Protocol) w praktyce jest warstwą transportową: model pyta, serwer MCP odpowiada. Sam w sobie nie zna jednak logiki Twojego sklepu Shopify — nie wie, czym różni się wariant od produktu, jak Shopify mapuje kolekcje i metapola, ani w jakiej kolejności trzeba zapisać zmiany przez GraphQL Admin API Shopify, żeby nic się nie rozjechało.
Dlatego u nas agent nie odpytuje MCP o każdą informację z osobna. Najpierw pobieramy dane z Shopify do pamięci agenta — ma do nich natychmiastowy dostęp, bez setek round-tripów po każdy szczegół. To szybsze i tańsze niż dopytywanie „po kawałku”, a agent widzi cały katalog naraz, zanim cokolwiek zmieni.
Prawdziwą robotę odwala wiedza agentów o workflow Shopify: jak GraphQL Admin API przyjmuje masowe zmiany, gdzie są limity kosztów zapytań, jaki jest poprawny ciąg operacji. Bez tej wiedzy samo MCP to puste złącze — przepustka do narzędzi, która nie wie, co i jak nimi zrobić. Zadania na katalogu wykonują agenci, którzy tę logikę znają, a GraphQL Admin API Shopify jest dla nich kontrolowanym kanałem zapisu.
Brzmi technicznie? Wyjaśnijmy po ludzku. Załóżmy, że bierzesz sam model — Claude Opus — i podpinasz go do sklepu Shopify przez MCP. Dostajesz bystry silnik z wtyczką do danych, ale o bezpieczeństwo, kopie zapasowe i kontrolę nad każdą zmianą musisz zadbać sam. Witly ma to wszystko w środku. Oto co realnie dostajesz w obu wariantach:
Rozpoznanie katalogu (research)
Model dopytuje MCP o produkty po kawałku, w trakcie rozmowy
Cały katalog pobrany z góry do pamięci agenta — analizuje go naraz, zanim ruszy
Znajomość workflow sklepu
Agent musi sam przeanalizować specyfikację i serią testów ustalić, w jakiej kolejności bezpiecznie wykonać zadanie
Agenci mają workflow przekazany od Witly — kolejność i zależności operacji znają z góry, bez testowania na ślepo
Praca na danych
Każda informacja to osobne zapytanie do sklepu — wolno i kosztownie przy tysiącach pozycji
Dane lokalnie przy agencie, operacje liczone hurtowo, bez setek round-tripów
Kopia przed zmianą (backup)
Brak — zapis idzie od razu, nikt nie robi migawki
Stan produktów zapisany tuż przed operacją — zawsze masz do czego wrócić
Zatwierdzanie planu
Opus potrafi rozpisać plan, ale sama jego akceptacja nie chroni przed błędem w trakcie wykonania
Podwójna akceptacja — najpierw zatwierdzasz plan, a potem jeszcze potwierdzasz wykonanie; sama zgoda na plan to za mało, by mieć pewność
Pojedyncze operacje zapisu (UPDATE / DELETE / CREATE)
Po starcie leci wszystko naraz, bez kontroli nad każdą zmianą
Każdą operację zapisu możesz potwierdzać osobno — zwłaszcza usuwanie
Historia przeprowadzonych operacji
Zależne od konfiguracji, zwykle bez pełnego śladu zmian
Każda operacja zapisana w dzienniku — widać dokładnie, co i kiedy agent zrobił
Cofnięcie zmian (rollback)
Ręczne odkręcanie — trzeba wiedzieć, co i jak przywrócić
Większość zmian odwracalna ze stanu sprzed operacji, praktycznie jednym kliknięciem