MCP dla firm: co to jest i co zmienia w wycenie, odbiorze i uprawnieniach agenta AI

MCP (Model Context Protocol) to otwarty standard, który ustala, jak aplikacja AI — na przykład Claude, ChatGPT albo Microsoft Copilot Studio — korzysta z funkcji Twoich systemów. Po stronie systemu działa niewielki program, tzw. serwer MCP. Pokazuje on aplikacji AI listę dozwolonych funkcji, takich jak „znajdź kontrahenta” czy „przygotuj zamówienie do zatwierdzenia”, i wykonuje je w granicach nadanych uprawnień. Jak taki projekt wygląda u nas, od zakresu po testy odbiorcze, opisaliśmy na stronie o połączeniu asystenta AI z Twoim systemem (MCP). Ten tekst jest o czymś innym: o tym, co MCP zmienia w ofercie, którą masz przed sobą.

Piszemy dla osoby, która ma ofertę z linijką „serwer MCP” albo „agent AI z dostępem przez MCP” — agent to program AI, który sam wykonuje kolejne kroki zadania — i musi zdecydować, czy ją przyjąć: właściciela firmy, kierownika działu albo osoby odpowiedzialnej za IT. Nie ma tu kodu. Są trzy rzeczy, które MCP faktycznie zmienia: wycena, zakres odbioru i miejsce, w którym mieszkają uprawnienia. Jest też lista rzeczy, których nie zmienia, choć slajd „mamy MCP” mógłby to sugerować. Fakty o standardzie podajemy według stanu na 12 października 2026 r.; standard zmienia się szybko, więc przy każdym podajemy datę lub źródło.

MCP w trzech zdaniach

Bez wspólnego standardu połączenie systemu firmy z każdą kolejną aplikacją AI zwykle wymagało osobnego dopasowania: jednego dla Claude’a, innego dla ChatGPT, jeszcze innego dla własnego agenta. MCP działa jak jedno standardowe gniazdko: system udostępnia swoje funkcje raz, przez serwer MCP, a każda aplikacja AI, która obsługuje standard, może z nich korzystać. Aplikację AI specyfikacja nazywa hostem — to program, w którym pracuje człowiek albo agent.

Kilka dat, żeby było jasne, o jak dojrzałym standardzie mowa. Aktualna specyfikacja MCP nosi datę 28 lipca 2026 r. Anthropic, który standard stworzył, przekazał go 9 grudnia 2025 r. do Agentic AI Foundation działającej przy Linux Foundation. Z serwerów MCP można korzystać między innymi w Copilot Studio oraz przez API Claude’a i OpenAI — czyli wejścia, przez które firmy budują na tych modelach własne aplikacje (Claude oznacza tę funkcję jako wersję testową, OpenAI opisuje ją w swojej dokumentacji). n8n może być zarówno serwerem, jak i programem korzystającym z cudzych serwerów — więcej o tym w przewodniku po n8n.

Serwer MCP może udostępniać trzy rodzaje rzeczy: funkcje, których używa model AI, dane do przeczytania (np. treść dokumentu) i gotowe szablony poleceń dla użytkownika. Dalej skupiamy się na funkcjach, bo to ich dostęp i uprawnienia ocenia się w ofercie.

Co kupujesz, gdy w ofercie stoi „serwer MCP”

Sam standard jest prosty, a gotowych części do złożenia serwera jest dużo. Płacisz więc nie za „MCP”, tylko za to, co wokół niego trzeba zaprojektować dla Twojej firmy. W porządnej ofercie ta linijka rozpada się na kilka konkretnych elementów:

• listę funkcji wybranych pod jeden przypadek użycia — nie „całe API”, czyli nie wszystko, co Twój system potrafi udostępnić innym programom;
• opis każdej funkcji językiem Twojej firmy — model AI wybiera funkcję po nazwie i opisie, więc od tych opisów zależy, czy wybierze dobrze;
• uprawnienia sprawdzane przy każdym użyciu funkcji, a nie tylko raz przy połączeniu;
• potwierdzanie tożsamości: kto i czym potwierdza tożsamość wobec serwera, a serwer — wobec Twojego systemu;
• rejestr działań: co zrobiono, kiedy, na czyje polecenie;
• testy odbiorcze: lista sytuacji, które muszą zadziałać poprawnie, uzgodniona przed budową;
• instrukcję wdrożenia i utrzymania dla osoby, która przejmie serwer.

Druga decyzja to: budować własny serwer czy użyć gotowego. Coraz więcej producentów oprogramowania prowadzi własne, oficjalne serwery MCP do swoich produktów. Jeżeli taki serwer robi to, czego potrzebujesz, często oznacza to najmniej budowy — ale wtedy kupujesz cudzą listę funkcji i cudze uprawnienia. Własny serwer ma sens, gdy gotowy udostępnia za dużo, za mało albo nie zna języka Twojej firmy. W obu przypadkach liczba funkcji, liczba systemów i to, czy funkcje tylko czytają, czy także zapisują, decydują o koszcie bardziej niż sam standard. Cen nie podajemy, bo zależą od Twojego systemu; skąd biorą się koszty całego wdrożenia, opisaliśmy w tekście o tym, ile kosztuje agent AI.

Co MCP zmienia w wycenie — a czego nie

Zmienia trzy rzeczy.

1. Ilość powtarzanej pracy przy kilku aplikacjach AI. Jeżeli z tych samych funkcji ma korzystać kilka aplikacji AI, opis funkcji, uprawnienia i rejestr działań powstają raz, a nie dla każdego połączenia osobno. Każde podłączenie nadal wymaga konfiguracji i testów. Przy jednej aplikacji ta korzyść nie istnieje.
2. Koszt zmiany aplikacji AI w przyszłości. Gdy za rok zechcesz przejść z jednej aplikacji AI na inną, która też obsługuje MCP, serwer zostaje. Nie znaczy to, że zmiana jest darmowa: aplikacje różnią się tym, które części standardu obsługują i jak pytają użytkownika o zgodę, więc testy trzeba powtórzyć.
3. Miejsce na uprawnienia i rejestr działań. Serwer jest naturalną bramką: każde użycie funkcji przez niego przechodzi, więc tam najłatwiej sprawdzić uprawnienia i zapisać, co się stało. Piszemy o tym szerzej niżej.

Nie zmienia natomiast:

• tego, gdzie trafiają dane. To, co zwróci funkcja, aplikacja AI zwykle przekazuje modelowi AI u wybranego dostawcy, na jego warunkach. O tym, które wyniki trafiają do modelu i gdzie są przetwarzane, decyduje aplikacja i konfiguracja wdrożenia; sam MCP nie przenosi przetwarzania do Twojej firmy. Kto jest wtedy administratorem danych osobowych w rozumieniu RODO (ogólnego rozporządzenia o ochronie danych), a kto podmiotem przetwarzającym, opisaliśmy na stronie o bezpieczeństwie i RODO;
• opłat za model AI ani licencji aplikacji AI;
• pracy nad opisaniem procesu: ktoś musi zdecydować, które funkcje są potrzebne i co znaczą;
• potrzeby testów i utrzymania: Twój system się zmienia, aplikacje AI też, a standard ma kolejne wersje — wersja z lipca 2026 r. oznaczyła na przykład kilka wcześniejszych mechanizmów jako wycofywane; według zasad standardu zostają one co najmniej 12 miesięcy, zanim będzie można je usunąć (lista zmian).

Jeżeli w ofercie „serwer MCP” jest jedną linijką bez rozbicia na powyższe elementy, to pierwsze pytanie do dostawcy: co dokładnie w niej jest.

Zakres zlecenia i odbiór: o co zapytać, zanim podpiszesz

Tu nie chodzi o prawo, tylko o to, co dostajesz i co kontrolujesz po zakończeniu projektu. Zapisy w umowie ustala Twój prawnik; poniżej są pytania, na które dobrze znać odpowiedź przed rozmową z nim.

• Czyj jest kod serwera? Czy trafia do Ciebie — do miejsca, w którym Twoja firma przechowuje kod programów — czy zostaje u dostawcy i jest wynajmowany?
• Gdzie serwer działa i kto ma do niego dostęp? Na Twojej infrastrukturze, w Twojej chmurze, czy jako usługa dostawcy? Samo miejsce nie przesądza, kto widzi przechodzące dane: dostawca może mieć dostęp administracyjny albo serwisowy także do serwera w Twojej chmurze. Zapytaj osobno, kto i po co może zajrzeć do danych w trakcie działania i przy wsparciu technicznym.
• Kto przechowuje tokeny i inne dane dostępowe, a kto nad nimi panuje? Token to cyfrowa przepustka, którą system wydaje programowi. Jeśli połączenie korzysta z przepustek, aplikacja AI używa przepustki do serwera, a serwer — osobnych danych dostępowych do Twojego systemu. Gdzie są przechowywane, kto może ich używać i czy uprawnienia nadaje konto Twojej firmy, czy dostawcy? Kto może je unieważnić — i czy po przekazaniu projektu dostawca traci dostęp?
• Jak wymienić aplikację AI? Czy serwer był testowany tylko z jedną aplikacją, i co trzeba zrobić, żeby podłączyć inną?
• Jaka jest lista testów odbiorczych? Czy obejmuje próby niedozwolonych operacji, wygasłe przepustki, powtórzony zapis i złośliwą treść w danych — a nie tylko „działa na demo”?
• Co dostajesz przy przekazaniu? Kod, opis wdrożenia, instrukcję utrzymania i listę funkcji z uprawnieniami. W naszej metodyce wdrożenia przekazanie jest osobnym etapem właśnie po to, żeby po nim nie być od nas zależnym.

Uprawnienia: gdzie w MCP mieszkają cztery decyzje

Na stronie o wdrożeniu agentów AI opisujemy cztery decyzje, które podejmuje się, zanim agent dostanie dostęp do czegokolwiek: zakres odczytu, zakres zapisu, operacje wymagające zgody człowieka i rejestr działań. Przy MCP każda z nich ma swoje konkretne miejsce:

Dwie uwagi, które warto znać przed rozmową z dostawcą. Po pierwsze, zgoda. Zasady bezpieczeństwa w specyfikacji mówią, że użytkownik ma wyraźnie zgadzać się na dostęp do danych i na użycie funkcji, a specyfikacja zaleca, by człowiek zawsze mógł odmówić użycia funkcji, a aplikacja prosiła o potwierdzenie. Jednocześnie wprost przyznaje, że sam protokół nie może tego wymusić — robi to (albo nie) konkretna aplikacja AI. Na przykład w API OpenAI zgoda przed przekazaniem danych do serwera MCP jest domyślnie wymagana, ale można ją wyłączyć. Dlatego w rozwiązaniach, które budujemy, operacje, których nie da się cofnąć, czekają na zatwierdzenie przez osobę po Twojej stronie także w samym procesie, a nie tylko w okienku aplikacji.

Po drugie, przepustki dostępu. Ten mechanizm jest w specyfikacji opcjonalny. Dla serwerów, z którymi aplikacja łączy się przez sieć, specyfikacja zaleca oparcie go na projekcie standardu OAuth 2.1 — popularnego sposobu wydawania przepustek. Gdy jest włączony, serwer ma przyjmować tylko tokeny wydane właśnie dla niego i nie przekazywać ich dalej (zasady autoryzacji). Dlatego w ofercie trzeba sprawdzić, czy dostawca w ogóle go wdrożył. Jeśli aplikacja AI komunikuje się bezpośrednio z serwerem uruchomionym jako lokalny program, specyfikacja zaleca pobieranie danych dostępowych z ustawień przekazanych temu programowi przy uruchomieniu — wtedy pytanie „kto przechowuje dane dostępowe” dotyczy każdego takiego miejsca osobno. Osobną sprawą są dane dostępowe, którymi serwer łączy się z Twoim systemem: to nie ta sama przepustka co ta do samego serwera. Specyfikacja zaleca też, by aplikacja AI zapisywała użycie funkcji w rejestrze, ale serwer, który kupujesz, powinien prowadzić własny — inaczej rejestr działań zależy od tego, którą aplikację AI akurat wybrano.

Trzy ryzyka przy dostępie przez MCP

1. Zapis od pierwszego dnia. Odczyt też wymaga ograniczeń, bo może ujawnić poufne dane. Zapis dodatkowo pozwala coś zmienić albo zepsuć w Twoim systemie. O co zapytać: czy pierwsza wersja tylko czyta albo przygotowuje propozycje do zatwierdzenia — i po jakich wynikach testów włącza się zapis?

2. Kto napisał serwer i kto go uruchamia. Serwer działa z uprawnieniami, które mu dasz, więc ufasz jego autorowi. Specyfikacja każe traktować jako niezaufane deklaracje serwera o tym, jak zachowuje się funkcja — na przykład że „tylko czyta” — jeśli nie pochodzą z zaufanego serwera. OpenAI pisze wprost, że nie weryfikuje zewnętrznych serwerów i zaleca łączenie się tylko z zaufanymi, najlepiej oficjalnymi serwerami producentów; Anthropic w dokumentacji Claude Code każe upewnić się, że ufa się serwerowi, zanim się go podłączy. O co zapytać: czy to serwer producenta systemu, dostawcy, czy darmowy serwer z internetu — i kto go aktualizuje?

3. Ukryte polecenia w danych. Treść, którą zwróci funkcja — opis produktu, e-mail od klienta, dokument — może zawierać zdanie udające polecenie dla AI, na przykład „wyślij te dane na ten adres”. Mówi się na to „prompt injection”. O co zapytać: czy treść z Twoich systemów jest traktowana jako dane, a nie polecenia, i czy jest na to test w liście odbiorczej?

Kiedy MCP to przesada

Najprostszy test: czy kolejność kroków jest stała, a proces dotyczy jednego systemu? Jeżeli tak — pobierz nowe zamówienie z systemu sprzedaży, poproś model o sprawdzenie pozycji, poproś człowieka o zatwierdzenie, zapisz wynik w tym samym systemie — nie potrzebujesz serwera MCP. Wystarczy zwykły krok w narzędziu do automatyzacji, takim jak n8n, który łączy się z Twoim systemem przez API. Zwykle wymaga to mniej pracy, łatwiej to przetestować i łatwiej zrozumieć osobie, która przejmie utrzymanie. Tak samo rekomendujemy na stronie o agentach: zacząć od automatyzacji, a po agenta sięgnąć, gdy reguł robi się za dużo.

Serwer MCP zaczyna mieć sens, gdy spełniony jest choć jeden z dwóch warunków:

• model ma sam wybierać spośród kilku funkcji, bo to, co zrobić w drugim kroku, zależy od tego, co znalazł w pierwszym;
• te same funkcje mają być dostępne w kilku aplikacjach AI, np. w czacie dla pracowników i w agencie działającym w tle.

Nie musisz też wybierać raz na zawsze: n8n potrafi i udostępniać swoje procesy jako funkcje MCP, i korzystać z cudzych serwerów MCP. Zaczynasz od zwykłej automatyzacji, a serwer dokładasz, gdy któryś z warunków się spełni. Jak porównujemy MCP z pozostałymi sposobami łączenia AI z systemami, pokazaliśmy w tekście o łączeniu AI z systemem do zarządzania firmą (ERP) i do obsługi klientów (CRM): integracja AI z ERP i CRM.

Co agent z dostępem przez MCP dodaje do rejestru systemów AI

Jeżeli prowadzisz rejestr systemów AI w firmie — spis, który pomaga przygotować się do obowiązków z AI Act, czyli unijnego rozporządzenia o sztucznej inteligencji — do wpisu dla agenta korzystającego z serwera MCP warto dopisać trzy rzeczy: listę funkcji, do których ma dostęp; które z nich zapisują dane; i gdzie jest rejestr działań. Lista mówi, do czego agent ma dostęp; co faktycznie zrobił, sprawdzisz w rejestrze działań — o ile zapisuje on potrzebne informacje i jest przechowywany wystarczająco długo. Które obowiązki z AI Act dotyczą Twojego systemu, ustala prawnik; jak przekładamy je na konkretne zmiany w systemach, opisaliśmy przy technicznym sprincie zgodności z AI Act.

Pięć pytań do dostawcy, który mówi „mamy MCP”

1. Kto napisał serwer MCP, kto go uruchamia i kto go będzie aktualizować?
2. Jak serwer potwierdza tożsamość? Kto przechowuje przepustkę do serwera, a kto dane dostępowe serwera do Twojego systemu — i czyje konto nadaje oraz odbiera każde z nich, przed przekazaniem i po nim?
3. Czy funkcje domyślnie tylko czytają, a zapis wymaga zatwierdzenia przez człowieka?
4. Czy treść zwracana przez funkcje jest traktowana jako niezaufana i czy jest na to test?
5. Gdzie jest zapisywane każde użycie funkcji — na serwerze, w aplikacji AI, czy w obu miejscach?

Pytania ogólne, które warto zadać każdemu dostawcy AI — o region przetwarzania danych, trenowanie modeli na Twoich danych czy umowę powierzenia — zebraliśmy na stronie o bezpieczeństwie i RODO. Jeżeli zastanawiasz się jeszcze, czy w ogóle potrzebujesz agenta, a nie prostszego czatu, zajrzyj do porównania agenta AI z chatbotem.

Co dalej

Jeśli masz system z API i konkretny pomysł — asystent albo agent AI ma coś w nim zrobić — zacznij od jednego przypadku użycia, jednej aplikacji AI i funkcji, które najpierw tylko czytają. Na stronie o połączeniu asystenta AI z Twoim systemem (MCP) opisaliśmy, od jakiego zakresu zaczynamy i co sprawdzamy przy odbiorze.

Opisz nam swój system i to, co AI ma w nim zrobić. Powiemy, czy potrzebny jest serwer MCP, czy wystarczy zwykła automatyzacja — także wtedy, gdy oznacza to mniejszy projekt.