Granice MCP: co asystent zrobi na koncie klienta, a czego nie

Serwer MCP platformy robi dokładnie to, co obiecuje dokumentacja, i nic ponadto. Ten materiał jest spisem granic: transportu, uprawnień, mechanizmów bezpieczeństwa i rzeczy, których świadomie nie ma. Powstał po to, żeby zespół wdrażający wiedział, co może obiecać klientowi, zanim obieca coś, czego nie dowiezie. Podstawy konfiguracji opisuje materiał wprowadzający o serwerze MCP; tu zakładamy, że masz go za sobą.

Granica pierwsza: transport wyłącznie lokalny

Serwer pracuje na stdio, uruchamiany komendą artisan, i nie wystawia żadnego punktu HTTP. Nie ma adresu, klucza API ani webhooka; jest proces na maszynie i asystent podłączony do tego procesu. Powód jest prosty: serwer nie ma własnej warstwy autoryzacji, więc wystawienie go do sieci oznaczałoby zbudowanie całej powierzchni uwierzytelniania wyłącznie po to, żeby zaoszczędzić jedną komendę w konfiguracji klienta MCP.

Konsekwencja dla sprzedaży: jeżeli klient oczekuje „API w chmurze", to nie jest ten produkt. Integracja przez MCP to praca asystenta na skonfigurowanej maszynie, nie żądania REST z dowolnego miejsca. W praktyce agencyjnej nie okazuje się to ograniczeniem, bo operacje wykonuje asystent operatora, nie system klienta, ale musi to być jasne przed podpisaniem czegokolwiek.

Granica druga: praca na koncie klienta wymaga planu klienta

Każde narzędzie serwera ma dwa tryby. Bez wskazania właściciela pracuje jako operator platformy. Ze wskazaniem właściciela wykonuje operację na rzecz konkretnego konta: wtedy plan tego konta musi zawierać flagę dostępu programistycznego (poziomy Scale), a konto musi być właścicielem witryny, której dotyczy operacja. Obie rzeczy sprawdza serwer przy każdym wywołaniu i odmawia czytelnym komunikatem, nie cichym pominięciem.

To rozstrzyga częste nieporozumienie: dostęp MCP nie jest „funkcją agencji, która działa na wszystkich klientów". Praca asystenta na koncie klienta to uprawnienie tego klienta, wynikające z jego planu. Limity planu właściciela (liczba stron, języków, podstron) obowiązują przy operacjach MCP dokładnie tak samo jak w panelu.

Granica trzecia: walidacja przed zapisem, rewizja przy zapisie

Dwa mechanizmy zdejmują z MCP większość ryzyka operacyjnego:

• Import na sucho. Każdy dokument witryny można przepuścić przez pełną walidację bez zapisu czegokolwiek. Procedura zespołowa powinna czynić to obowiązkiem: najpierw przebieg próbny, poprawki, dopiero potem import właściwy.
• Rewizje przy każdym zapisie treści. Zanim jakakolwiek operacja zmieni podstronę, jej stan zostaje zachowany jako wersja do przywrócenia. Asystent, który źle zrozumiał polecenie, jest o jedno przywrócenie wersji od naprawienia szkody.

Do tego zmiany strukturalne zachowują ciągłość: zmiana adresu podstrony przez MCP zakłada przekierowanie 301 i przenosi poddrzewo, tak samo jak w panelu. Nie ma osobnej, „gorszej" ścieżki dla operacji programistycznych.

Granica czwarta: zakres narzędzi jest zamknięty

Serwer wykonuje operacje na treści i strukturze witryn: import całości, podstrony, sekcje, kalkulatory, podstrony lokalne, wpisy bloga i pomocy. Lista rzeczy, których nie robi, jest równie ważna:

• nie zarządza domenami, płatnościami ani planami kont,
• nie czyta skrzynki leadów ani danych osobowych z formularzy,
• nie wysyła maili i nie wykonuje żadnych operacji poza platformą,
• nie omija limitów planu, blokad publikacji ani reguł antyspamowych treści.

Automatyzacja odbioru zapytań to osobny, niezależny mechanizm webhooków leadowych, dostępny od planu Pro i nie wymagający MCP w ogóle.

Granica piąta: człowiek zatwierdza przekaz

Ograniczenie nietechniczne, za to najczęściej łamane. Serwer przeniesie do platformy dokładnie tę treść, którą poda mu asystent. Walidacja wychwyci błędy struktury, ale nie wychwyci przekazu nietrafionego w rynek klienta. Procedura, która się sprawdza: asystent buduje, człowiek znający branżę klienta czyta przed publikacją, różnice wersji ogląda się w rewizjach. Skala bez tego etapu produkuje dużo stron przeciętnych, szybciej.

Checklista przed pierwszym wdrożeniem u klienta

1. Plan klienta zawiera flagę dostępu programistycznego; sprawdzone w panelu, nie w ofercie.
2. Konto operatora ma dostęp do witryny klienta (własność albo zespół), a owner_user_id wskazuje konto klienta.
3. Asystent pobrał kontrakt dokumentu jako zasób, zanim wygenerował pierwszy plik.
4. Pierwszy przebieg z preview: true, wynik pokazany osobie odpowiedzialnej za klienta.
5. Witryna klienta ma włączony noindex do chwili akceptacji (makiety bez śladu w Google).
6. Historia wersji sprawdzona po pierwszej zmianie: wiadomo, jak wygląda przywrócenie, zanim będzie potrzebne.

Ściąga do rozmowy z klientem

Można obiecać: budowę i aktualizację witryn z dokumentów, seryjne operacje na portfelu, prowadzenie treści przez asystenta, wszystko z walidacją, rewizjami i w granicach planu. Nie można obiecać: publicznego API, integracji przez webhooki MCP, operacji poza treścią i strukturą stron, ani działania na koncie klienta bez planu Scale po jego stronie. Ta druga lista bywa handlowo mniej efektowna; jest za to w całości prawdziwa, a różnicę między tymi dwiema listami klient odkryłby i tak, najpóźniej w drugim tygodniu wdrożenia.