Serwer MCP daje asystentowi AI dostęp do zewnętrznego systemu, a gdy ten dostęp obejmuje budżet reklamowy, o bezpieczeństwie decydują bezpieczniki w kodzie, nie prompt. Dla klienta e-commerce zbudowaliśmy serwer MCP do obsługi Meta Ads: Claude audytuje konto, pisze teksty reklam i tworzy kampanie, czyli może wydać prawdziwe pieniądze. Opisujemy, jakie zabezpieczenia ma taki serwer, dlaczego 56 zielonych testów nie wychwyciło 11 wymogów Meta i czemu obok serwera MCP powstało CLI dla Claude Cowork.
Czym jest serwer MCP i do czego służy w firmie?
MCP (Model Context Protocol) to otwarty standard, przez który asystent AI korzysta z narzędzi spoza czatu. Serwer MCP to program, który wystawia listę takich narzędzi, każde z nazwą, opisem i parametrami. Model czyta opisy i sam wybiera, czego użyć, żeby wykonać polecenie.
Dla firmy oznacza to, że Claude przestaje być rozmówcą bez dostępu do danych. Zamiast eksportować raport z panelu, wklejać go do czatu i przepisywać wnioski z powrotem, piszesz „które zestawy reklam mają rosnący koszt pozyskania” i dostajesz odpowiedź z konta. Gotowe serwery MCP istnieją dla wielu popularnych usług. Własny buduje się wtedy, gdy system jest Wasz albo gdy gotowy serwer nie ma ograniczeń, których potrzebujecie przy zapisie.
Chcesz podłączyć asystenta AI do swojego systemu? Budujemy serwery MCP i CLI dla Claude Code i Cowork z trybem próbnym, potwierdzeniem i limitami w kodzie. Opisz system i to, co asystent ma w nim robić. Serwery MCP →
Co potrafi serwer MCP, który zbudowaliśmy do Meta Ads?
Serwer napisaliśmy w Pythonie (3.11) z biblioteką MCP w wersji 2.x i klientem HTTP httpx. Kod źródłowy to około 3,6 tys. linii, a serwer wystawia 28 narzędzi. Nad nimi działa sześć skilli, czyli instrukcji prowadzących model przez całe zadanie:
- audyt konta z oceną 0–100: część liczy deterministycznie Python, część ocenia model; przy wydatkach poniżej ok. 500 zł w ostatnich 30 dniach skill odmawia oceny wydajności, bo danych jest za mało;
- teksty reklam w limitach znaków i zgodne z polityką Meta;
- tworzenie kampanii w dwóch fazach, z bramką człowieka pośrodku;
- formularze lead ads i pobieranie leadów;
- raporty miesięczne i tygodniowe;
- diagnostyka sygnałów: piksel, Conversions API, deduplikacja zdarzeń.
Odczyt i raporty to najprostsza część. Cała praca projektowa poszła w narzędzia, które coś zmieniają na koncie.
Jakie bezpieczniki powinien mieć serwer MCP, który może wydawać pieniądze?
Założyliśmy, że model kiedyś się pomyli: źle zrozumie polecenie, pomyli konto albo dopisze zero do budżetu. Każdy bezpiecznik ma więc działać niezależnie od tego, co model „chciał”.
| Bezpiecznik | Jak działa | Przed czym chroni |
|---|---|---|
| Tryb próbny domyślnie | Każdy zapis zwraca podgląd zapytania, nic nie trafia do Meta | Przypadkowa zmiana przy testowaniu polecenia |
| Fraza potwierdzenia | Zapis na żywo tylko po wpisaniu „ZATWIERDZAM”, sprawdzane w jednym miejscu kodu | Obejście bramki przez inne narzędzie |
| Status wstrzymany | Kampania, zestaw i reklama powstają jako PAUSED | Wydatki przed sprawdzeniem przez człowieka |
| Sufity budżetu | Limit dzienny i całkowity, sprawdzany także dla sumy zestawów | Dziesięć zestawów tuż pod limitem pojedynczym |
| Dziennik mutacji | SQLite, każda zmiana z identyfikatorem paczki (batch_id) | Niewiadome „co to utworzyło?” |
| Rollback ostatniej paczki | Podgląd listy, drugie potwierdzenie, kasowanie tylko ostatniego uruchomienia | Skasowanie działających kampanii |
| Walidacja offline | Plik campaign.yaml sprawdzany przed pierwszym zapytaniem | Kampania-sierota po błędzie w połowie |
| ID tylko w konfiguracji | Konto, strona i piksel w pliku klienta, test „zero ID w kodzie” | Zmiana na cudzym koncie po skopiowaniu kodu |
Wersję Graph API przypięliśmy w jednym miejscu, bo Meta regularnie wycofuje starsze wersje i lepiej zmieniać jedną stałą niż szukać adresów po kodzie.
Przed pierwszym uruchomieniem na żywo zrobiliśmy audyt bezpieczeństwa: 15 sprawdzeń, z których 4 wskazały realne ryzyko. Najgroźniejsze dotyczyło rollbacku. W symulacji z dwoma uruchomieniami, tygodniowym i dzisiejszym, cofanie objęłoby 50 ostatnich obiektów konta, a więc także kampanię, która już wydawała budżet i miała historię wyników. Stąd identyfikator paczki przy każdej zmianie i rollback ograniczony do ostatniej z nich.
Dlaczego 56 zielonych testów nie wystarczyło?
Testy jechały na atrapie klienta Meta. Sprawdzały, czy serwer wysyła zapytania o właściwym kształcie, czy bramki trzymają i czy rollback cofa to, co trzeba. Nie mogły sprawdzić, czego wymaga prawdziwe API, bo atrapa znała tylko to, co do niej wpisaliśmy.
Pierwszy launch na żywo zrobiliśmy 28 sierpnia 2026 r. na koncie testowym, z założeniem, że żadna reklama nie zostanie opublikowana. Meta zwraca pierwszy błąd, a nie listę, więc wymogi wychodziły po kolei, próba po próbie. Przy 56 zielonych testach wyszło 11 wymogów, których atrapa nie znała. Kilka przykładów:
- pola beneficjenta i płatnika reklamy wymagane przez unijny DSA;
- minimalny budżet dzienny zestawu, ok. 3,71 zł;
- wymagana strategia stawek przy zestawie;
- miniatura dla kreacji wideo, którą serwer generuje teraz przez ffmpeg i wysyła przed kreacją;
- różne nazwy pól o tym samym znaczeniu w kreacji wideo i kreacji z linkiem;
- aplikacja Meta w trybie deweloperskim i brak metody płatności na koncie.
Każdy wymóg trafił do walidacji albo do kodu, więc następny launch zatrzymuje się na nim przed wysłaniem zapytania. Ostatecznie przeszedł pełny łańcuch: kampania, zestaw, dwie kreacje (wideo z miniaturą i obraz) i dwie reklamy, wszystko wstrzymane. Stan sprawdziliśmy w Meta, a nie w odpowiedzi narzędzia. Rollback cofnął 6 z 6 obiektów i konto testowe zostało puste.
Atrapa sprawdza kształt zapytań, a to, czego naprawdę chce API, pokazuje dopiero pierwsze uruchomienie. Kto buduje serwer MCP z zapisem, powinien wpisać ten dzień do planu jako osobny etap, z czasem na kilka poprawek, bo testy jednostkowe go nie zastąpią.
Jakie błędy Meta zwraca z mylącym komunikatem?
Jeden z ostatnich błędów mówił, że administrator firmy musi zaakceptować zasady antydyskryminacyjne. Akceptacja nic nie dała. Przyczyną był token wygenerowany z automatycznie utworzonego użytkownika systemowego z rolą pracownika, a taki użytkownik nie może tworzyć reklam. Pomógł dopiero token z użytkownika systemowego z rolą administratora.
Narzędzie sprawdzające dostęp rozpoznaje teraz tę sytuację i zwraca werdykt „rola za niska”. Serwer pokazuje też komunikat błędu, który Meta przysyła po polsku, zamiast ogólnej podpowiedzi zależnej od kodu błędu.
MCP czy CLI: co wybrać, gdy asystent działa w Claude Cowork?
Na co dzień serwer działa w Claude Code i Claude Desktop przez transport stdio. Klient chciał jednak, żeby z narzędzia korzystała osoba nietechniczna w Claude Cowork. Z logów aplikacji ustaliliśmy, że Cowork w wersji z sierpnia 2026 r. to lokalna maszyna wirtualna z dostępem do dysku, Pythonem i siecią, ale serwerów MCP z konfiguracji Claude Desktop nie ładował.
Rozwiązaniem okazało się drugie wejście do tej samej logiki. Moduły z narzędziami nie wiedzą nic o transporcie. Nad nimi stoi serwer MCP i CLI z tymi samymi komendami, a test parzystości pilnuje, żeby żadna komenda nie istniała tylko w jednym wejściu. Skille w folderze wołają CLI przez Bash.
| Serwer MCP | CLI ze skillami | |
|---|---|---|
| Gdzie działa | Claude Code, Claude Desktop | Claude Cowork, terminal |
| Jak model widzi narzędzia | Lista narzędzi z opisami w protokole | Skill opisuje komendy i ich użycie |
| Instalacja u odbiorcy | Wpis w konfiguracji aplikacji | Folder z instrukcją, biblioteki doinstalowują się przy starcie |
| Bezpieczniki | Te same, bo siedzą w modułach pod oboma wejściami | |
Klient dostaje paczkę zip z instrukcją. Otwiera folder w Cowork, pisze „sprawdź, czy działa”, a skill startowy sprawdza środowisko, przenosi token do pliku z uprawnieniami tylko dla właściciela i pokazuje dostępne konta.
Czego kod serwera MCP nie zabezpieczy?
Limit zapisany w pliku konfiguracyjnym chroni tylko wtedy, gdy asystent nie może tego pliku zmienić. W środowiskach, w których model ma terminal i prawo zapisu w folderze, zasada „nie obchodź limitów” w instrukcji jest prośbą do modelu, a nie zabezpieczeniem.
Dlatego twardy limit trzeba trzymać poza zasięgiem asystenta: w osobnym procesie, na serwerze albo jako limit wydatków w samym koncie reklamowym. Omawiamy to z klientem przed wdrożeniem.
Od czego zacząć budowę własnego serwera MCP?
- Spisz operacje i podziel je na odczyt i zapis. Zaznacz te, które kosztują pieniądze albo są nieodwracalne.
- Zacznij od narzędzi tylko do odczytu i daj zespołowi z nich korzystać.
- Zapis buduj od razu z trybem próbnym, potwierdzeniem w jednym miejscu kodu i dziennikiem zmian.
- Każdy bezpiecznik obłóż testem, który pada, gdy ktoś go wyłączy.
- Pierwsze uruchomienie zrób na koncie testowym i weryfikuj wynik w docelowym systemie.
- Zdecyduj, gdzie będą pracować użytkownicy: jeśli w Cowork, zaplanuj CLI obok serwera MCP.
Jeśli chcesz podłączyć asystenta do własnego systemu, opisaliśmy ten zakres w ofercie serwerów MCP, a szerzej o agentach z dostępem do firmowych systemów piszemy na stronie agentów AI.
