Serwer MCP dla sklepu, czyli AI z dostępem do prawdziwych danych

Problem, którego nie widać na początku

Pierwsze podejście do AI w e-commerce wygląda zwykle tak samo. Ktoś eksportuje zamówienia z ostatniego kwartału do arkusza, wkleja je do czatu i prosi o analizę. Odpowiedź bywa naprawdę dobra, więc procedura się utrwala: co miesiąc eksport, co miesiąc wklejenie, co miesiąc te same pytania.

Kłopot pojawia się przy trzecim czy czwartym powtórzeniu. Eksport jest zdjęciem stanu z konkretnej chwili, więc każda odpowiedź dotyczy przeszłości, a nie tego, co dzieje się teraz. Plik zawiera zwykle więcej danych, niż wymagało pytanie, łącznie z adresami i nazwiskami klientów, których nikt świadomie nie zamierzał nikomu wysyłać. Do tego każde nowe pytanie wymaga nowego eksportu, bo model nie ma jak sam sięgnąć po brakującą informację.

Kiedy tylko zapytania stają się regularne, opłaca się odwrócić kierunek. Zamiast wysyłać dane do modelu, daj modelowi możliwość zapytania o dane wtedy, kiedy są mu potrzebne, i tylko o te, których dotyczy pytanie.

Czym jest MCP

Model Context Protocol jest ustandaryzowanym sposobem opisania, jakie operacje aplikacja udostępnia modelowi językowemu. Serwer MCP wystawia listę narzędzi, każde z nazwą, opisem i zestawem parametrów, a model po drugiej stronie sam decyduje, które z nich wywołać, żeby odpowiedzieć na pytanie użytkownika. Zamiast wklejać tabelę z zamówieniami, pytasz o wynik ostatniego tygodnia, a model sięga po niego narzędziem przygotowanym do liczenia sprzedaży.

Kluczowa różnica względem zwykłej integracji polega na tym, kto układa kolejność kroków. W klasycznym rozwiązaniu programista z góry ustala, że po kliknięciu przycisku pobieramy zamówienia, filtrujemy je i liczymy sumę. Przy MCP opisujesz tylko dostępne operacje, a ich kolejność i dobór wynikają z pytania, które ktoś właśnie zadał. Pytanie o najlepiej sprzedający się produkt w kategorii i pytanie o klienta, który przestał kupować, składają się z tych samych klocków, ułożonych inaczej.

Po stronie CS-Cart takie połączenie nie wymaga przebudowy sklepu. Nasz serwer MCP jest osobną usługą, która rozmawia ze sklepem przez REST API, więc nie wchodzi w kod platformy ani nie zmienia jej zachowania. Ma to praktyczną konsekwencję dla starszych instalacji: skoro komunikacja idzie przez API, wersja PHP samego sklepu przestaje być przeszkodą, a serwer działa również ze sklepami wciąż stojącymi na PHP 7.4.

O co można w ten sposób zapytać

Zestaw narzędzi decyduje o tym, co model w ogóle jest w stanie zobaczyć, i to jest pierwsza decyzja projektowa, a nie szczegół konfiguracji. W naszym serwerze narzędzia odczytu obejmują katalog i kategorie, szczegóły produktu razem z kodem magazynowym i wagą, opinie, zamówienia z filtrowaniem po statusie, adresie e-mail i okresie, szczegóły pojedynczego zamówienia, porzucone koszyki, dane klienta wraz z podsumowaniem jego zakupów, statystyki sklepu za wybrany okres oraz ranking sprzedaży. Osobne, drobne narzędzie sprawdza po prostu, czy sklep odpowiada i jak szybko.

Praktyczne pytania, które z tego wynikają, brzmią zwykle bardzo zwyczajnie. Które produkty sprzedawały się najlepiej w zeszłym miesiącu w danej kategorii. Czy ten klient, który właśnie napisał do obsługi, kupował już wcześniej i co takiego zamawiał. Ile zamówień czeka w statusie oczekującym na płatność dłużej niż tydzień. Różnica względem raportów w panelu polega na tym, że pytanie formułujesz w zdaniu, a nie w formularzu, i że kolejne pytanie może pogłębić poprzednie bez klikania od nowa.

Dwa narzędzia zapisu, zmiana statusu zamówienia i ustawienie stanu magazynowego, są w naszym serwerze wyłączone domyślnie. Włącza je świadoma zmiana konfiguracji, a dopóki tego nie zrobisz, w ogóle nie pojawiają się na liście dostępnej modelowi. To celowa asymetria: odczyt niewłaściwych danych jest problemem, ale zapis niewłaściwej wartości jest incydentem.

Bezpieczeństwo, czyli miejsce, w którym łatwo się przewrócić

Podłączenie modelu do sklepu przesuwa granicę zaufania. Do tej pory dane wychodziły ze sklepu wtedy, kiedy człowiek świadomie kliknął eksport. Po podłączeniu wychodzą wtedy, kiedy model uzna, że są potrzebne do odpowiedzi. Dlatego kilka rzeczy trzeba ustawić, zanim cokolwiek zostanie uruchomione produkcyjnie.

Pierwsza to uwierzytelnianie i to, żeby nie dało się go obejść przez zapomnienie. W naszej implementacji serwer bez ustawionego tokenu po prostu nie startuje, więc nie istnieje stan, w którym działa otwarty dla wszystkich. Tokeny są nazwane i można wydać osobny dla każdego narzędzia po drugiej stronie, a na dysku serwera nie leży żaden z nich, tylko ich skróty kryptograficzne. Do tego dochodzi lista dozwolonych domen, spoza której połączenia są odrzucane.

Druga to konto, na którym serwer rozmawia ze sklepem. Kuszące jest podpięcie istniejącego klucza administratora, bo to jedna rzecz mniej do zrobienia, ale wtedy zakres dostępu modelu równa się zakresowi uprawnień administratora. Osobny użytkownik API, bez prawa kasowania zamówień i zarządzania kontami, kosztuje kwadrans i domyka temat.

Trzecia to świadomość, dokąd trafia treść odpowiedzi. Sam serwer MCP nie ma bazy i niczego nie kopiuje, ale dane, o które model zapyta, przechodzą przez ten model. Jeżeli stoi on w chmurze dostawcy, to właśnie tam trafi wycinek danych potrzebny do odpowiedzi. Jeśli Twoje dane nie mogą opuszczać firmy, wniosek jest prosty i dotyczy nie tyle protokołu, ile modelu: musi stać lokalnie.

Czwarta to rejestr zmian. Każdy zapis warto logować z wartością sprzed i po operacji, bo przy pytaniu „dlaczego to zamówienie ma inny status” odpowiedź „zmienił je model, o tej godzinie, z tej wartości na tę” jest jedyną, która kończy dyskusję.

Czego taki serwer nie zrobi

Uczciwa lista ograniczeń jest ważniejsza niż lista funkcji, bo to ona decyduje o rozczarowaniu po miesiącu. Jedna instancja serwera obsługuje jeden sklep, więc przy kilku sklepach mówimy o kilku instancjach. W Multi-Vendor sprzedawca pytający własnym kluczem dostaje dane zawężone do swojej firmy, ale porzuconych koszyków nie zobaczy w ogóle, bo baza CS-Cart nie wiąże koszyka ze sprzedawcą, i jest to ograniczenie rdzenia, a nie integracji.

Model nie zastąpi też raportowania księgowego. Odpowiada na pytania w oparciu o to, co zwrócą narzędzia, a więc dobrze radzi sobie z rozeznaniem i analizą, a gorzej z liczbami, które muszą się zgadzać co do grosza w dokumencie urzędowym. Do tego drugiego nadal służą raporty sklepu i księgowość.

Od czego zacząć

Zacznij od spisania pytań, które naprawdę zadajesz albo chciałbyś zadawać. Zwykle okazuje się, że są ich trzy albo cztery i że wszystkie dotyczą odczytu. To wystarczy, żeby ocenić, czy zestaw narzędzi w ogóle je pokrywa, i żeby zdecydować, czy potrzebujesz zapisu, czy jednak nie.

Potem zdecyduj, gdzie stoi model, bo od tego zależy odpowiedź na pytanie o poufność danych. Dopiero na końcu zajmij się uruchomieniem, tokenami i kontem API, bo to część najprostsza i najlepiej opisana.

Jeżeli chcesz zobaczyć, jak to wygląda na Twoich danych, napisz do nas. Kod serwera jest otwarty, więc możesz go uruchomić samodzielnie, a my zajmujemy się wdrożeniem, hostowaniem i utrzymaniem u tych, którzy wolą mieć to z głowy. Szczegóły obu dróg opisuje strona serwera MCP.