Radosław Kmita
Najkrócej: MCP (Model Context Protocol) to otwarty standard, przez który aplikacja AI łączy się z narzędziami i danymi firmy, np. CRM, dyskiem czy kalendarzem, bez osobnej integracji dla każdej pary. Sam protokół nie pilnuje bezpieczeństwa: jego specyfikacja mówi wprost, że zasad nie da się wymusić na poziomie protokołu. Zanim podłączysz serwer MCP, ustal trzy rzeczy: komu ufasz, do jakich danych AI dostanie dostęp i które działania wymagają zatwierdzenia przez człowieka.
Przykład: w czacie AI, z którego korzysta Twój zespół, pojawia się przycisk „Połącz z CRM”. Jedno kliknięcie, logowanie i asystent widzi klientów, notatki oraz historię ofert. Wygodne. Tyle że od tej chwili model, który potrafi się pomylić i da się go oszukać, czyta i zmienia dane w systemie, od którego zależy sprzedaż.
Ten tekst tłumaczy, co dzieje się pod tym przyciskiem i jak zdecydować, czy go kliknąć.
Czym jest MCP w AI?
MCP (Model Context Protocol) to otwarty protokół, który określa, jak aplikacje AI pobierają dane i uruchamiają narzędzia z innych systemów. Chodzi o MCP w sztucznej inteligencji, nie o skrót znany z medycyny.
Firma Anthropic przedstawiła MCP 25 listopada 2024 roku jako sposób łączenia asystentów AI ze źródłami danych. Często porównuje się go do uniwersalnego gniazdka: jedna wtyczka zamiast osobnego kabla do każdego urządzenia. Porównanie dobre, dopóki pamiętasz, że gniazdko przewodzi prąd niezależnie od tego, co do niego podłączysz.
Jak działa MCP: host, klient i serwer
Specyfikacja MCP opisuje trzy role:
- host to aplikacja AI, z którą pracuje człowiek, np. czat albo edytor kodu z asystentem,
- klient to łącznik wewnątrz hosta, który utrzymuje kontakt z jednym serwerem,
- serwer to usługa, która udostępnia AI dane lub funkcje konkretnego systemu, np. CRM.
Serwer udostępnia trzy rodzaje elementów: narzędzia (funkcje, które model może uruchomić, np. „utwórz zadanie”), zasoby (dane do odczytu, np. dokument) i szablony (gotowe polecenia dla użytkownika). Narzędzia są najważniejsze z punktu widzenia ryzyka, bo to one coś zmieniają.
Aktualna wersja specyfikacji nosi datę 28 lipca 2026 roku. Wprowadziła żądania bezstanowe i opcjonalne rozszerzenia, m.in. Tasks (długie operacje), Skills over MCP i MCP Apps (interaktywne elementy w rozmowie). Część polskich tekstów o MCP powstała przed tą wersją, więc warto sprawdzać, której dotyczą.
Do czego służy serwer MCP?
Serwer MCP udostępnia aplikacji AI jeden system firmy w ustandaryzowany sposób: mówi, jakie dane i funkcje są dostępne, a potem je wykonuje na prośbę modelu. Ten sam serwer powinien zadziałać z każdym hostem obsługującym tę wersję MCP.
Trzy przykłady zastosowań:
- dokumenty: asystent wyszukuje procedurę na dysku firmowym i cytuje właściwy fragment,
- CRM: po spotkaniu zapisuje notatkę przy kliencie i proponuje kolejny krok,
- kalendarz: sprawdza wolne terminy zespołu i przygotowuje zaproszenie do wysłania.
Każdy z tych przykładów ma część „czytaj” i część „zrób”. Ta druga wymaga osobnej decyzji, o czym niżej.
MCP, API czy zwykła automatyzacja?
MCP nie zastępuje API ani automatyzacji. To warstwa, która pozwala modelowi samemu wybrać, z którego narzędzia skorzystać.
| Rozwiązanie | Kto decyduje o kolejnym kroku | Kiedy ma sens |
|---|---|---|
| API (bezpośrednia integracja) | program napisany przez człowieka | jedno stałe połączenie dwóch systemów |
| Workflow (automatyzacja z góry zaprojektowana) | schemat ustalony z góry, AI najwyżej w jednym kroku | powtarzalny proces o znanych krokach |
| Function calling (wywoływanie funkcji) | model wybiera jedną z funkcji zdefiniowanych w danej aplikacji, a wykonuje ją kod aplikacji | jedna aplikacja AI z kilkoma własnymi funkcjami |
| MCP | model AI w trakcie rozmowy lub zadania | asystent lub agent, który korzysta z wielu narzędzi zależnie od sytuacji |
Jeśli kroki da się zapisać z góry, zwykle prostszy i tańszy w kontroli jest workflow. Jak wybrać między tymi podejściami, opisujemy w artykule Automatyzacja procesów biznesowych z AI: kiedy wystarczy workflow, a kiedy potrzebny jest agent.
Gdy AI ma tylko odpowiadać na podstawie dokumentów firmy, bliższy jest temat z tekstu RAG po ludzku: jak AI korzysta z dokumentów Twojej firmy.
Kto stoi za MCP i czy otwarty standard jest bezpieczny?
Za MCP stoi dziś fundacja przy Linux Foundation, ale to, że standard jest otwarty i popularny, nie czyni go bezpiecznym.
9 grudnia 2025 roku firma Anthropic przekazała MCP do Agentic AI Foundation, nowej fundacji działającej w ramach Linux Foundation. Współzałożycielami są Anthropic, Block i OpenAI, a wsparcie zadeklarowały m.in. Google, Microsoft i AWS. Według Anthropic na dzień ogłoszenia działało ponad 10 000 aktywnych publicznych serwerów MCP, a pakiety SDK w Pythonie i TypeScripcie pobierano ok. 97 mln razy miesięcznie.
Z tej skali wynikają dwa wnioski. Część narzędzi, z których korzysta Twoja firma, ma już serwer MCP. A wśród tysięcy publicznych serwerów są też takie, których autora nie znasz.
Najważniejsze zdanie pada w samej specyfikacji: MCP daje dostęp do danych i ścieżki wykonywania kodu, ale protokół „nie może wymusić” zasad bezpieczeństwa. Zgody użytkownika, kontrola dostępu i ochrona danych to zadanie twórców hosta i serwera, a w praktyce także firmy, która je podłącza.
Jakie ryzyka niesie MCP?
Trzy główne ryzyka to: polecenia ukryte w danych (prompt injection), zatrute opisy narzędzi i zbyt szerokie uprawnienia. Każde z nich działa nawet wtedy, gdy sam model jest dobrze zabezpieczony.
1. Prompt injection przez dane. Model nie zawsze odróżnia treść, którą czyta, od poleceń, które ma wykonać. W maju 2025 roku zespół Invariant Labs pokazał atak na serwer GitHub MCP: ktoś umieścił instrukcje w zgłoszeniu w publicznym repozytorium. Agent poproszony o przejrzenie zgłoszeń wykonał ukryte w nich instrukcje, sięgnął do prywatnych repozytoriów użytkownika i opublikował ich dane w pull requeście.
Badacze użyli modelu Claude 4 Opus i podkreślili, że samo dostrojenie modelu nie wystarcza. W firmie tę samą rolę może odegrać mail od klienta, komentarz w dokumencie albo opis produktu na stronie.
2. Zatrute narzędzia. Serwer przekazuje modelowi opis każdego narzędzia. W kwietniu 2025 roku zespół Invariant Labs opisał ataki typu tool poisoning: ukryte w opisie instrukcje, których człowiek nie widzi, a model wykonuje, np. odczytuje pliki z kluczami. Ten sam tekst opisuje wariant, w którym serwer zmienia opis narzędzia już po zatwierdzeniu. Dlatego specyfikacja zaleca traktować opisy narzędzi jako niezaufane, chyba że pochodzą z zaufanego serwera.
3. Zbyt szerokie uprawnienia. Serwer działa z uprawnieniami konta, którym go podłączono. Jeśli to konto administratora, model ma w zasięgu wszystko, co administrator. Prompt injection z punktu 1 jest groźny właśnie wtedy, gdy agent ma dostęp do więcej niż potrzebuje.
Agent, który sam planuje kroki i korzysta z wielu serwerów, łączy te ryzyka. Jak nad nim panować, opisujemy w artykule Agenci AI w firmie: czym są, ile kosztują i jak nad nimi panować.
Jakie dane można udostępnić przez MCP?
Te same cztery kategorie danych, które obowiązują przy pracy z AI, wyznaczają też zakres dostępu przez MCP. Różnica polega na tym, że przy MCP dane nie są wklejane przez człowieka, tylko pobierane przez model, więc granicę trzeba ustawić w uprawnieniach serwera.
| Kategoria danych | Przez MCP | Zapis i działania |
|---|---|---|
| Materiały publiczne | odczyt dopuszczalny, z poszanowaniem praw do treści i danych osobowych | zwykle bez dodatkowych warunków |
| Dane wewnętrzne | tylko przez zatwierdzony host i serwer, z dostępem ograniczonym do potrzebnych zasobów | zapis po zatwierdzeniu przez człowieka |
| Dane osobowe i poufne | po ocenie zastosowania, w najwęższym zakresie, z logiem dostępu | każde działanie zatwierdza człowiek |
| Hasła i klucze API | nigdy w treści rozmowy, opisu ani zasobu | dostęp tylko przez mechanizm autoryzacji |
Ostatni wiersz ma w MCP konkretne znaczenie. Przy serwerach zdalnych specyfikacja przewiduje autoryzację opartą na OAuth 2.1, czyli logowanie z wyborem zakresu uprawnień. Przy serwerach lokalnych dane dostępowe pochodzą z konfiguracji środowiska. W obu wariantach klucz nie powinien trafiać do rozmowy z modelem; to zasada, której pilnuje host i konfiguracja, nie sam protokół.
Warto też wiedzieć, że autoryzacja w MCP jest opcjonalna, więc jej brak w danym serwerze to sygnał do zadania pytań.
Pełną klasyfikację danych i zasady zatwierdzania narzędzi opisujemy w tekście Polityka AI w firmie: co powinna zawierać i jak ją wdrożyć (ze wzorem).
Lista kontrolna przed podłączeniem serwera MCP
Konektory MCP bywają podłączane przez pracowników na własną rękę, bez wiedzy osoby odpowiedzialnej za narzędzia. Jak wykryć i ograniczyć takie użycie, opisujemy w tekście Shadow AI w firmie: co to jest i jak ograniczyć ryzyko.
Zanim ktoś w Twojej firmie podłączy nowy serwer, osoba odpowiedzialna za narzędzia sprawdza osiem punktów:
- Pochodzenie. Serwer udostępnia producent systemu albo zaufany dostawca. Nie instalujemy serwerów z przypadkowych repozytoriów.
- Zakres narzędzi. Wiemy, jakie narzędzia udostępnia serwer, i wyłączamy te, których nie potrzebujemy, zwłaszcza usuwanie i wysyłkę.
- Osobna tożsamość. Serwer łączy się kontem z minimalnymi uprawnieniami, nie kontem administratora ani prywatnym kontem pracownika.
- Zatwierdzanie działań. Każdy zapis, wysyłka, płatność i usunięcie wymaga zgody człowieka w hoście. Automatyczna zgoda najwyżej dla odczytu materiałów publicznych i danych wewnętrznych.
- Przypięta wersja. Instalujemy konkretną wersję serwera i aktualizujemy ją świadomie, po sprawdzeniu zmian w opisach narzędzi.
- Rozdzielenie źródeł. Agent, który czyta treści z zewnątrz (maile, strony, zgłoszenia), nie ma w tej samej sesji dostępu do danych osobowych i poufnych.
- Log. Wywołania narzędzi są zapisywane: kto, kiedy, które narzędzie i z jakimi parametrami.
- Wpis do rejestru. Serwer trafia do rejestru narzędzi z właścicielem, kategorią danych i datą przeglądu.
Przykładowy zapis: Serwery MCP podłączamy wyłącznie po wpisaniu do rejestru narzędzi. Wpis zawiera: dostawcę serwera, wersję, konto techniczne, kategorie danych, listę włączonych narzędzi oraz działania wymagające zatwierdzenia przez człowieka.
Punkt 6 bywa najtrudniejszy, bo kłóci się z wygodą: najbardziej przydatny asystent to ten, który widzi wszystko naraz, a to jednocześnie najbardziej ryzykowna konfiguracja.
Czy Twoja firma w ogóle potrzebuje MCP?
Nie każda. MCP ma sens, gdy AI ma korzystać z kilku systemów i samo decydować, z którego sięgnąć w danym zadaniu.
Jeśli potrzebujesz stałego przepływu, np. „nowy lead z formularza trafia do CRM, a handlowiec dostaje powiadomienie”, prostsza będzie automatyzacja w narzędziu do workflow. Porównanie takich narzędzi znajdziesz w tekście n8n w firmie: co to jest, ile kosztuje i kiedy warto (na tle Make i Zapiera).
MCP zaczyna się opłacać, gdy zespół pracuje z asystentem w wielu systemach naraz albo gdy budujesz agenta, który ma sięgać po różne narzędzia. Wtedy jeden standard zamiast kilku osobnych integracji upraszcza utrzymanie. Pod warunkiem, że ktoś w firmie odpowiada za listę podłączonych serwerów.
Zacznij od jednego pytania: gdyby asystent wykonał najgorsze możliwe polecenie ukryte w czytanym mailu, co mógłby zrobić z narzędziami, które mu dziś dajesz? Jeśli odpowiedź Cię niepokoi, zawęź uprawnienia, zanim cokolwiek podłączysz.
FAQ
Jak zbudować serwer MCP?
To zadanie dla programisty. Serwer pisze się z użyciem oficjalnych pakietów SDK, np. w Pythonie lub TypeScripcie, według specyfikacji MCP. Zanim zbudujesz własny, sprawdź, czy producent Twojego systemu nie udostępnia już oficjalnego serwera, i zastosuj tę samą listę kontrolną co przy serwerach gotowych.
