Serwer MCP: agent AI buduje i utrzymuje witryny klientów

W agencji, która prowadzi kilkadziesiąt witryn, wąskim gardłem nie jest projekt graficzny ani hosting. Wąskim gardłem są godziny ludzi przeklikujących te same układy sekcji na kolejnych stronach klientów. Każda nowa witryna kosztuje ten sam nakład co poprzednia, więc portfel rośnie liniowo razem z zatrudnieniem, a marża stoi w miejscu.

Serwer MCP zmienia tę zależność. Kompletną witrynę klienta, razem z podstronami, katalogiem, formularzami i wersjami językowymi, uruchamiasz z poziomu asystenta AI podłączonego do platformy. To funkcja produkcyjna planów Scale, dostępna od pierwszego dnia po zakupie.

Czym jest serwer MCP platformy

MCP (Model Context Protocol) to otwarty standard, którym asystenci AI łączą się z zewnętrznymi systemami. KOMPASFIRM udostępnia własny serwer MCP, dzięki czemu asystent przestaje doradzać, co kliknąć, a zaczyna wykonywać:

• buduje całą witrynę z jednego dokumentu JSON, razem z podstronami i wersjami językowymi,
• dokłada i przebudowuje pojedyncze sekcje na działającej stronie,
• generuje komplet podstron lokalnych pod miasta i dzielnice,
• zapisuje specyfikację kalkulatora wycen,
• prowadzi bloga, centrum pomocy i dokumentację.

Serwer pracuje wyłącznie na transporcie lokalnym (stdio). To świadoma decyzja architektoniczna: stdio nie ma własnej warstwy autoryzacji, więc wystawienie serwera po HTTP poszerzałoby powierzchnię ataku bez żadnej korzyści. Uruchamiasz go w swojej infrastrukturze i tylko Twój zespół ma do niego dostęp.

Wymagania wstępne

Zanim cokolwiek zadziała, potrzebne są trzy rzeczy: plan Scale (Scale, Scale Pro albo Enterprise) na koncie, które ma prowadzić operacje; klient MCP po stronie operatora (Claude Code, Claude Desktop, Codex albo inny obsługujący standard); oraz dostęp do uruchomienia serwera w środowisku, w którym pracuje asystent. Szczegóły techniczne konfiguracji i aktualną listę narzędzi utrzymujemy w dokumentacji planów Scale; ten materiał opisuje model pracy, nie zastępuje instrukcji.

Uruchomienie

php artisan mcp:start kompasfirm

Po stronie klienta MCP (Claude Code, Claude Desktop, Codex) wystarczy jedna sekcja konfiguracji:

{
  "mcpServers": {
    "kompasfirm": {
      "command": "php",
      "args": ["artisan", "mcp:start", "kompasfirm"],
      "cwd": "/sciezka/do/kompasfirm"
    }
  }
}

Po restarcie klienta asystent widzi serwer pod nazwą Kompasfirm wraz z listą narzędzi i schematów. Polecenia formułujesz jak zlecenia dla wykonawcy: „zbuduj stronę z tego dokumentu”, „dodaj do witryny 22 podstronę serwisu gwarancyjnego”, „opublikuj wpis o nowym pakiecie”.

Praca na koncie klienta: uprawnienia i limity

Ponieważ transport lokalny nie ma logowania, konto działające ustala zmienna MCP_USER_ID (domyślnie 1). To ono figuruje na przykład jako autor tworzonych wpisów.

Kluczowe jest rozróżnienie dwóch trybów pracy:

Flaga api_access należy do planów Scale. Jeżeli plan klienta jej nie zawiera, serwer odmówi operacji czytelnym komunikatem, zamiast po cichu zbudować witrynę poza limitem. Dla agencji to zabezpieczenie handlowe: zakres wykonanej pracy zawsze odpowiada temu, za co klient zapłacił, a rozliczenie limitów nie zależy od tego, czy stronę stawiał człowiek, czy agent.

Kolumna „strony” w panelu pokazuje realną skalę: największe witryny w portfelu liczą po kilkaset podstron wraz z wersjami językowymi i powstały z dokumentów, a nie z ręcznej pracy w edytorze.

Zakres narzędzi

Budowa całej witryny. import_site przyjmuje dokument JSON i tworzy z niego stronę razem z podstronami, sekcjami, formularzami i wersjami językowymi. Witryny korporacyjne B2B (CORPOTPL) mają odrębny kontrakt i własne narzędzie import_corpo_site. import_site świadomie odrzuca takie dokumenty, co chroni przed powstaniem konstrukcji łączącej dwa modele, której później nie da się utrzymać.

Praca na istniejącej witrynie. list_websites, list_pages i get_page służą do odnalezienia celu, a create_page, update_page, duplicate_page i delete_page operują na podstronach. Treść składasz sekcjami: add_section, update_section, move_section, delete_section, adresowanymi trójką (witryna, podstrona, indeks sekcji). Zmiana sluga w update_page automatycznie zakłada przekierowanie 301 i przenosi całe poddrzewo, więc porządkowanie architektury informacji nie kosztuje klienta pozycji w wyszukiwarce.

Generatory. generate_local_pages buduje komplet podstron lokalnych (szczegóły: podstrony lokalne w skali), a set_calculator zapisuje specyfikację kalkulatora wycen. Kalkulator nie wymaga rundy po zewnętrznym modelu: specyfikację przygotowuje Twój asystent, platforma ją waliduje i zapisuje, co eliminuje koszt tokenów i czas oczekiwania.

Baza wiedzy. list_posts, get_post, create_post, update_post i delete_post obsługują bloga, centrum pomocy i dokumentację, również na kontach klientów.

Zasady bezpiecznej pracy

Każde wdrożenie zaczynaj od preview: true. Tryb próby na sucho waliduje dokument, przedstawia listę tego, co powstanie, i sprawdza limity planu, nie zapisując niczego. Import produkcyjny uruchamiasz dopiero po akceptacji podsumowania. Bez tego kroku o przekroczeniu limitu podstron dowiesz się w połowie generowania witryny.

Pamiętaj, że update_section scala dane, ale wskazane klucze podmienia w całości. Przekazujesz data z jednym kluczem i reszta sekcji pozostaje nietknięta, jednak ten klucz zostaje nadpisany przekazaną wartością, bez łączenia w głąb. Przy listach (produkty, punkty oferty, pozycje FAQ) przesyłasz całą listę, nie pojedynczy element.

Każdy zapis treści poprzedza rewizja podstrony. Nieudaną zmianę wycofujesz z historii, a nie z kopii zapasowej bazy danych. Usunięte podstrony trafiają do kosza. Dzięki temu można powierzyć agentowi realną pracę bez ryzyka nieodwracalnej straty.

Asystent czyta kontrakt przed pracą

Najważniejsza część układu pozostaje niewidoczna: serwer udostępnia schematy jako zasoby MCP. Kontrakt dokumentu witryny, kontrakt treści lokalnych i specyfikację kalkulatora asystent pobiera samodzielnie, zanim cokolwiek zbuduje.

Efekt jest mierzalny w czasie wdrożenia. Asystent, który zna kontrakt, przygotowuje dokument przechodzący walidację za pierwszym razem. Asystent zgadujący format generuje serię błędów i pytań, a każda iteracja to kolejne minuty pracy operatora.

Pełna specyfikacja narzędzi wraz z argumentami znajduje się w dokumentacji planów Scale, oznaczonej odrębnym akcentem kolorystycznym, aby nie mieszała się z instrukcjami dla użytkownika końcowego.

Co to zmienia w rachunku agencji

• Czas wdrożenia witryny spada z dni do godzin, bo struktura powstaje z dokumentu, a nie z klikania.
• Koszt jednostkowy strony przestaje rosnąć razem z portfelem, więc kolejni klienci poprawiają marżę zamiast obciążać zespół.
• Standard wykonania jest powtarzalny: ta sama jakość struktury, danych strukturalnych i wersji językowych na każdej witrynie.
• Zmiany masowe stają się wykonalne, na przykład dołożenie sekcji na wszystkich stronach jednej branży.
• Zespół pracuje wyżej w łańcuchu wartości: mniej odtwórczej pracy w edytorze, więcej strategii i treści.

Powyżej efekt jednego wdrożenia: katalog sprzętu budowlanego w sześciu językach, z przełącznikiem, poprawnym hreflang i sparowanymi podstronami. Jeden dokument, jedna operacja, sześć kompletnych wersji.

Najczęstsze pytania zespołów wdrażających

Czy operacje przez MCP zużywają tokeny platformy? Nie. Treść powstaje w modelu asystenta, na rozliczeniu operatora z jego dostawcą; platforma przyjmuje gotowy materiał i go waliduje. Tokeny platformy płacą wyłącznie za generatory w panelu. Rachunek rozpisaliśmy w materiale o tokenach.

Co się dzieje, gdy import zatrzyma się w połowie? Walidacja preview sprawdza dokument i limity w całości przed zapisem, więc typowe błędy (brak wymaganego pola, przekroczony limit podstron) wychodzą przed importem, nie w jego trakcie. Każdy zapis treści na istniejącej podstronie ma rewizję, do której można wrócić.

Czy klient widzi, że zmianę zrobił agent? W historii wersji podstrony zmiana jest podpisana kontem wskazanym jako operator, tak jak każda inna. Klient z rolą podglądu widzi efekt, nie mechanizm.

Czy jeden serwer obsłuży wiele kont klientów? Tak, przez parametr owner_user_id przy każdym wywołaniu, pod warunkiem, że plan wskazanego konta zawiera flagę api_access. Bez niej serwer odmawia.

Kolejny etap to sam dokument witryny: struktura, tryby importu i walidacja.