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

> Serwer MCP platformy pracuje wyłącznie lokalnie, praca na koncie klienta wymaga flagi api_access u właściciela konta, a każdy zapis robi najpierw rewizję. Spisujemy pełną listę granic metody, zanim ktoś obieca klientowi rzeczy, których nie ma.

Opublikowano: 2026-09-08 · Aktualizacja: 2026-09-16
Źródło: https://kompasfirm.pl/kartografia/granice-mcp-praca-na-koncie-klienta

---
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](/kartografia/serwer-mcp-krok-po-kroku); 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](/kartografia/makieta-dla-klienta-bez-wycieku-do-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.