MCP AI agenci e-commerce Python automatyzacja RecznikiHaftowane

Własny MCP server zamiast klikania w panelu admina

Jak napisałem własny MCP server dla sklepu RecznikiHaftowane i dlaczego agent AI radzi sobie z dodaniem produktu lepiej niż ręczne klikanie.

Panel admina e-commerce vs czysty interfejs czatu z agentem AI

Dodanie nowego produktu do sklepu to z pozoru prosta sprawa. W praktyce wygląda tak: logujesz się do panelu admina, wpisujesz nazwę, opis, cenę, przypisujesz kategorie, wgrywasz zdjęcia, ustawiasz warianty kolorów, konfigurujesz sloty do personalizacji, ustawiasz sortowanie, klikasz "opublikuj". Błędy zdarzają się przy każdym z tych kroków — i każdy trzeba poprawić ręcznie.

W projekcie RecznikiHaftowane — sklepie z ręcznie haftowanymi ręcznikami — zamiast robić to ręcznie, napisałem własny MCP server. Teraz robi to agent.

Czym jest MCP i skąd pomysł na własny server

MCP (Model Context Protocol) to protokół, który pozwala agentowi AI korzystać z zewnętrznych narzędzi. Agent zamiast odpowiadać na podstawie tekstu, który mu wkleiłeś — pyta narzędzie o aktualne dane i działa na ich podstawie.

W projekcie mam łącznie 19 MCP serwerów: Plane do zarządzania zadaniami, Obsidian do bazy wiedzy, Playwright do testowania, Google Search Console, Analytics, Toggl do logowania czasu i kilka innych. Większość to gotowe narzędzia napisane przez community.

Ale dwa serwery napisałem sam — bo żadne gotowe narzędzie nie wiedziało nic o specyfice tego sklepu: jakie produkty istnieją, jakie kolory ręczników są dostępne, jakie wzory haftu można wybrać, jak zbudowany jest konfigurator personalizacji.

Ten server to własny serwer Python — około 900 linii Pythona, korzystający z biblioteki mcp od Anthropic.

Co agent wie dzięki temu serverowi

Serwer wystawia kilkanaście narzędzi, które agent może wywołać. Podzielę je na dwie grupy.

Odczyt — agent wie:

  • Jakie produkty istnieją w sklepie (łącznie z nieaktywnymi), jakie mają ceny bazowe i aktualne, opisy
  • Jakie warianty fizyczne są dostępne w każdym produkcie — konkretne kolory ręczników z kodami hex, cenami i kosztem zakupu (do liczenia marży)
  • Jakie wzory haftu istnieją i do jakich kategorii należą — agent może wybrać odpowiedni do konkretnego produktu
  • Jakie kolory nici są dostępne (z kodami hex)
  • Jakie fonty do haftu tekstu są aktywne
  • Jak skonfigurowany jest kreator personalizacji — jakie sloty, w jakiej pozycji na płótnie, co można personalizować
  • Jakie są przykłady realizacji klientów — gotowe zdjęcia ręczników z haftem, pogrupowane po produkcie i wzorze
  • Opinie klientów, ustawienia sklepu, metody wysyłki

Zapis — agent potrafi:

  • Wgrać zdjęcie do biblioteki mediów (z alt text, tagami, do 20 MB)
  • Utworzyć nowy produkt — z nazwą, opisem, ceną, typem (towel/bathrobe), galerią ze zdjęciami, slotami do konfiguracji
  • Zaktualizować istniejący produkt — dowolne pole, łącznie z galerią i wariantami
  • Przypiąć lub odpiąć zdjęcie od realizacji klienta
  • Zgłosić URL do indeksowania w Google (przez Indexing API)

Jak agent dodaje produkt

Konkretny przykład: chcę dodać nowy ręcznik z haftem inicjałów w kolorze bordo.

Bez MCP: otwieram panel admina, sprawdzam jakie kolory bordo są dostępne, wgrywam zdjęcia, wpisuję opis, ustawiam cenę, konfiguruję sloty.

Z MCP mówię agentowi co chcę, a on:

  1. Wywołuje get_products — sprawdza co już istnieje, żeby nie duplikować
  2. Wywołuje get_product_by_id na podobnym produkcie — widzi jak skonfigurowane są sloty i dostępne kolory
  3. Wywołuje get_wizzard_options — dostaje listę wszystkich wzorów haftu, nici i fontów; wybiera odpowiedni wzór i kolor nitki pod bordo
  4. Wywołuje upload_media — wgrywa zdjęcia z lokalnego dysku
  5. Wywołuje create_product — tworzy produkt z pełną konfiguracją: nazwa, opis, cena, galeria z wgranymi zdjęciami, sloty z wariantami kolorowymi
  6. (Opcjonalnie) wywołuje google_index_url — zgłasza nową stronę produktu do Google

Cały ten przepływ agent obsługuje sam, po jednym potwierdzeniu z mojej strony przed operacjami zapisu.

Agent jako interfejs zamiast panelu admina

Najciekawszy efekt uboczny tego rozwiązania to nie oszczędność czasu developera — to sposób w jaki z danych sklepu korzystają teraz pozostałe osoby.

Osoba zajmująca się marketingiem może zapytać agenta "które produkty są teraz w promocyjnych cenach?" i dostaje odpowiedź w kilka sekund. Bez logowania do panelu, bez szukania po zakładkach, bez ryzyka że przez przypadek coś kliknie, usunie albo nadpisze cenę.

Bez MCP opcje były dwie: albo dajesz komuś dostęp do panelu admina — i liczysz się z tym, że coś się może posypać — albo sam musisz odpowiadać na każde pytanie o dane sklepu. Oba warianty są słabe.

Z własnym MCP serverem jest trzecia opcja: agent jako bezpieczna warstwa nad danymi. Może odpowiedzieć na pytanie, może wykonać operację, ale tylko tę, do której ma narzędzie. Nie ma przycisku "usuń wszystkie produkty" — bo nikt takiego narzędzia nie zdefiniował.

Co to daje w praktyce

Po pierwsze: agent nigdy nie działa na danych z głowy. Wywołuje narzędzia za każdym razem — dane są aktualne. Jeśli wczoraj dodałem nowy kolor ręcznika, agent go widzi dzisiaj bez żadnych dodatkowych instrukcji z mojej strony.

Po drugie: spójność. Agent dobiera ceny i konfigurację na podstawie tego co już istnieje w sklepie — nie wymyśla. Jeśli wszystkie ręczniki welurowe kosztują między 89 a 129 zł, agent zaproponuje cenę w tym zakresie i wyjaśni dlaczego.

Po trzecie: mniej błędów przy operacjach zapisu. Zanim agent stworzy produkt, sprawdza co już istnieje i jak skonfigurowane są podobne produkty. Trudniej mu stworzyć produkt z brakującymi polami albo złą konfiguracją slotów.

Jak to napisać

Biblioteka mcp od Anthropic daje gotowy szkielet. Definiujesz funkcje w Pythonie z dekoratorem @mcp.tool(), opisujesz parametry w docstringu — i server gotowy. Każda funkcja to jedno narzędzie, które agent może wywołać.

W moim przypadku każde narzędzie to HTTP call do wewnętrznego API sklepu. Server nie ma własnej logiki biznesowej — jest warstewką tłumaczącą polecenia agenta na zapytania do API i formatującą odpowiedzi w czytelny sposób.

Najważniejsza część to narzędzie get_agent_instructions — zwraca agentowi mapę: jakie zadanie → jakie narzędzie wywołać. Dzięki temu agent nie błądzi i nie próbuje używać Playwrighta do sprawdzenia ceny produktu.

Jeśli masz podobny sklep lub system

Jeśli masz aplikację z własnym API — własny MCP server to kilka godzin pracy. Efekt: agent przestaje być oderwany od Twojego systemu i zaczyna w nim działać — jako narzędzie dla developera i jako bezpieczny interfejs dla reszty zespołu.

Jeśli chcesz porozmawiać jak to wdrożyć w konkretnym projekcie — napisz do mnie.

Czytaj też