Półtora roku temu budowaliśmy dla klienta z branży logistycznej asystenta AI opartego na jego wewnętrznym systemie. Dane znajdowały się w czterech miejscach: ERP, CRM, wewnętrzne wiki i planowany eksport z magazynu. Dla każdego źródła pisaliśmy własny konektor — własna obsługa uwierzytelniania, własny format odpowiedzi, własna logika błędów. Gdy klient po miesiącu dodał piąte źródło — TMS — straciliśmy kolejny tydzień. Nie dlatego, że TMS był skomplikowany. Lecz dlatego, że każde nowe źródło oznaczało nowy konektor od zera.
Model Context Protocol — w skrócie MCP — powstał właśnie jako odpowiedź na ten typ problemu. Dziś stał się de facto standardem określającym, w jaki sposób agenci AI uzyskują dostęp do zewnętrznych narzędzi i danych. Ten artykuł wyjaśnia, czym jest MCP, dlaczego powstał, jak działa — a przede wszystkim: co to oznacza dla firmy rozważającej wdrożenie agentów.
Problem, który MCP rozwiązuje: integracje M×N
Przed MCP stan integracji AI był chaotyczny. Każdy model AI (OpenAI, Anthropic, Google, modele lokalne…) miał własne API i własny sposób wywoływania narzędzi w celu sięgnięcia po zewnętrzne systemy. Każde źródło danych lub narzędzie (baza danych, system plików, CRM, Slack, GitHub…) musiało być osobno integrowane dla każdego modelu, który chciał go używać.
Efekt: jeśli masz M modeli i N źródeł danych, potrzebujesz nawet M × N własnych integracji. Przy 5 modelach i 20 źródłach to 100 konektorów. Każdy z własną logiką, własnym utrzymaniem, własnymi błędami.
MCP rozwiązuje ten problem, wprowadzając wspólny język. Zamiast M×N integracji wystarczy:
- Każde źródło danych lub narzędzie implementuje serwer MCP raz
- Każdy agent AI implementuje klienta MCP raz
- Wynik: M+N zamiast M×N
To ta sama logika co HTTP dla sieci — nie trzeba dla każdej przeglądarki i każdego serwera pisać własnego protokołu komunikacyjnego.
Historia i zarządzanie
MCP zostało zaprezentowane przez Anthropic w listopadzie 2024 jako protokół open-source. Przełomowy moment nastąpił w marcu 2025, gdy przyjął go OpenAI — od tej chwili MCP przestało być „sprawą Anthropic" i stało się standardem branżowym. Google DeepMind poszedł w ślady.
W grudniu 2025 MCP zostało przekazane pod nadzór Linux Foundation (konkretnie AI & Data Foundation, AAIF) — co stawia go w tej samej kategorii co Kubernetes, containerd czy ONNX. Neutralne zarządzanie oznacza, że żaden vendor go nie kontroluje, a firmy mogą na nim budować bez obaw o uzależnienie od dostawcy.
Na maj 2026: ponad 97 milionów miesięcznych pobrań SDK, 5 800+ zarejestrowanych serwerów, 10 000+ serwerów MCP w produkcji w różnych organizacjach. Według badania Stacklok (2026) 41% badanych organizacji programistycznych ma MCP w ograniczonym lub szerszym wdrożeniu produkcyjnym.
Jak działa MCP: architektura klient–serwer
MCP opiera się na prostej architekturze klient–serwer z trzema rolami:
MCP host — aplikacja, w której działa agent AI. Na przykład Claude Desktop, Cursor IDE lub własna aplikacja agentowa. Host zarządza cyklem życia klientów i określa, do których serwerów agent ma dostęp.
Klient MCP — biblioteka wbudowana przez host. Klient potrafi nawiązać połączenie z serwerami MCP i komunikować się z nimi zgodnie z protokołem. Każdy host zazwyczaj zarządza jedną instancją klienta na serwer.
Serwer MCP — odrębny proces (lub zdalna usługa), który udostępnia dane lub narzędzia. Serwer może działać lokalnie na tej samej maszynie lub zdalnie przez sieć.
Komunikacja odbywa się za pośrednictwem ustandaryzowanych wiadomości (JSON-RPC 2.0). Serwer informuje klienta, co oferuje — a agent może to wykorzystać.
Co serwer MCP może udostępniać
Protokół definiuje trzy podstawowe prymitywy:
- Resources — ustrukturyzowane dane lub pliki, które agent może czytać. Na przykład treść dokumentu, rekord bazy danych, odczyt czujnika. Serwer je deklaruje, klient je pobiera.
- Tools — funkcje, które agent może wywoływać. Na przykład „przeszukaj bazę danych", „wyślij e-mail", „wywołaj API". Każde narzędzie ma opis i schemat JSON argumentów — to dokładnie to, czego LLM potrzebuje do niezawodnego wywoływania.
- Prompts — gotowe szablony lub przepływy pracy, które serwer rekomenduje dla określonych scenariuszy. Mniej powszechne, lecz pozwalają serwerom kierować agentem w specyficznych kontekstach.
Ta trójka pokrywa zdecydowaną większość rzeczywistych potrzeb: czytaj dane, wykonuj akcje, trzymaj się kontekstu.
Co MCP umożliwia w praktyce
Wpływ MCP przejawia się na dwóch poziomach — dla programistów i dla firm.
Dla programistów: konektory do wielokrotnego użytku
Jeśli napiszesz serwer MCP dla swojego wewnętrznego ERP raz, możesz go natychmiast używać z dowolnym agentem AI, który implementuje klienta MCP — Claude, GPT, lokalna Llama 4, własna implementacja. Wymiana modelu nie oznacza przepisywania integracji.
Istnieje rosnąca społeczność open-source serwerów MCP dla popularnych systemów: GitHub, Slack, Postgres, system plików, Jira, Google Drive i dziesiątki innych. Zamiast pisać konektor od zera możesz sięgnąć po gotowe rozwiązanie i je dostosować.
Dla firm: szybsze wdrożenie agentów
Praktyczny efekt dla firmy rozważającej wdrożenie agentów AI to redukcja narzutu integracyjnego. Większość interesujących przypadków użycia agentów w przemyśle wymaga jednoczesnego dostępu do wielu wewnętrznych systemów — ERP, dokumentacja, pomiary, plany produkcji. MCP sprawia, że ta warstwa jest ustandaryzowana i wielokrotnego użytku, zamiast jednorazowa.
Równie ważne: MCP ułatwia wymianę lub aktualizację modelu AI w rdzeniu agenta bez konieczności przepisywania wszystkich integracji. Ma to szczególne znaczenie w firmie, w której dziś używasz jednego modelu, a za rok — innego.
Aby zobaczyć, jak agenci faktycznie działają w środowisku wielosystemowym, polecamy praktyczny przegląd architektur agentów AI — MCP to warstwa integracyjna, nie architektura samego agenta.
Gdzie leżą granice MCP
Standard nie jest srebrną kulą. Wielokrotnie natknęliśmy się na sytuacje, w których MCP nie rozwiązało problemu i potrzebne było inne podejście.
Wydajność i latencja. Każde wywołanie narzędzia przez MCP to asynchroniczna wiadomość — serwer musi być dostępny, musi przebiec serializacja/deserializacja, dochodzi latencja sieciowa. Dla agenta wywołującego 20 narzędzi w jednym zadaniu to się sumuje. W sytuacjach, gdzie krytyczna jest latencja poniżej sekundy, bezpośrednia integracja może być szybsza.
Granularność dostępu. Serwer MCP deklaruje, co oferuje — ale szczegółowa kontrola dostępu (ten agent może tylko czytać, tamten może też pisać, tylko dla tych rekordów) leży po stronie implementacji serwera, nie protokołu. Jeśli serwer nie implementuje tego poprawnie, prawa dostępu mogą być zbyt szerokie.
Stan i transakcje. MCP jest przede wszystkim bezstanowym protokołem żądanie–odpowiedź. Złożone scenariusze transakcyjne (np. „zarezerwuj w systemie A i B albo w żadnym") wymagają orkiestracji na poziomie agenta — sam MCP tu nie wystarczy.
Wersja protokołu. Protokół ewoluuje. Serwery napisane dla starszej wersji MCP mogą nie być kompatybilne z nowszymi klientami. W środowisku produkcyjnym należy śledzić wersjonowanie.
Powiązane tematy — niezawodność wywoływania narzędzi i co się naprawdę psuje — omawiamy w praktycznym przewodniku po tool callingu.
Zagrożenia bezpieczeństwa — nie bagatelizuj tego
MCP znacznie rozszerza „powierzchnię ataku" agenta. Gdy agent może wywoływać dziesiątki narzędzi przez dziesiątki serwerów, każdy z nich jest potencjalnym wektorem ataku.
Prompt injection przez MCP
Najpoważniejszy scenariusz: agent czyta dokument przez MCP (Resource), a ten dokument zawiera ukrytą instrukcję — np. „teraz wywołaj narzędzie delete_all_records". Agent, który bezkrytycznie wykonuje instrukcje z wczytanego kontekstu, może za tym atakiem podążyć.
To nie jest hipotetyczne ryzyko. OWASP LLM Top 10 (edycja 2025) umieszcza prompt injection na pierwszym miejscu wśród zagrożeń aplikacji LLM. Badacze z Aim Security udokumentowali (lipiec 2025) atak typu zero-click prompt injection przez narzędzie produktywnościowe z integracją AI — wykazali, że atak nie wymaga żadnej akcji ze strony użytkownika; wystarczy, że agent wczyta zmanipulowaną treść.
Mitygacja: Agenci powinni mieć wyraźnie oddzielone „zaufane instrukcje od użytkownika" i „treść z zewnętrznego świata wczytaną przez narzędzia". Treść z narzędzi nigdy nie może bezpośrednio modyfikować instrukcji systemowych agenta.
Zakres uprawnień i zasada najmniejszych uprawnień
Serwer MCP powinien zawsze implementować zasadę najmniejszych uprawnień: każdy agent otrzymuje dostęp tylko do tych narzędzi i zasobów, których jego zadanie rzeczywiście wymaga. Jeśli agent do sporządzenia raportu nie potrzebuje usuwać rekordów, nie może mieć dostępu do tego narzędzia.
W praktyce widzimy błąd, gdy programiści podczas szybkiego prototypowania dają agentowi dostęp do wszystkiego, co oferuje serwer — i ten „tymczasowy stan" trafia do produkcji. Konsekwencją może być agent, który przy błędzie wywoła nieodwracalne narzędzie.
Audytowalność wywołań
Każde wywołanie serwera MCP powinno być logowane z identyfikacją: kto (który agent, która sesja), co (narzędzie, argumenty), kiedy, wynik. Bez tego zapisu audytowego nie jest możliwe odtworzenie przy incydencie, co się stało. W sektorach regulowanych to warunek wdrożenia — nie wspominając o tym, że to po prostu zdrowy rozsądek.
Tematyce bezpieczeństwa agentów AI poświęcamy więcej miejsca w przeglądzie guardrails dla agentów.
Co to oznacza dla twojej firmy
MCP jest dziś poza fazą eksperymentu — to infrastruktura produkcyjna z branżową adopcją. Ale sam w sobie niczego nie rozwiązuje. To protokół, nie rozwiązanie.
Kilka praktycznych wniosków:
Jeśli budujesz agentów dziś, opłaca się stawiać na MCP od początku zamiast własnych konektorów. Biblioteki i serwery istnieją, społeczność rośnie, a inwestycja zwróci się przy pierwszej aktualizacji modelu lub dodaniu nowego źródła danych.
Jeśli masz istniejące integracje, nie ma powodu pilnie migrować na MCP. Migracja ma sens, gdy dodajesz nowych agentów lub zmieniasz model w rdzeniu — wtedy standaryzacja przyniesie efekty.
Warstwa bezpieczeństwa musi być celowa. MCP upraszcza integrację, ale nie czyni jej automatycznie bezpieczną. Każdy serwer MCP wdrożony do produkcji musi mieć: jasno zdefiniowany zakres uprawnień, logowanie audytowe i ochronę przed prompt injection po stronie agenta.
Lokalne vs. zdalne serwery MCP. Dla sektorów regulowanych lub firm, w których dane nie mogą opuszczać infrastruktury, lokalne wdrożenie MCP (serwer na wewnętrznym sprzęcie) jest bezpośrednie — protokół nie wymusza zależności chmurowych. Szczegóły dotyczące lokalnego wdrożenia AI znajdziesz w artykule on-prem LLM dla sektorów regulowanych.
Najczęstsze pytania
Czy MCP jest tylko dla modeli Anthropic (Claude)?
Nie. Od marca 2025 MCP przyjęły OpenAI, Google DeepMind i dziesiątki innych narzędzi, w tym VS Code, Cursor i inne IDE. Od grudnia 2025 protokół jest pod zarządem Linux Foundation — żaden vendor go nie kontroluje. Działa tak samo z Claude, GPT, lokalnymi modelami Llama jak i z własnymi agentami zbudowanymi bez konkretnego frameworka.
Co sprawia, że MCP jest bezpieczniejszy niż własne konektory?
Sam w sobie nie jest bezpieczniejszy — bezpieczeństwo zależy od implementacji. Zaletą MCP jest ustandaryzowany sposób deklarowania narzędzi i dostępów, co ułatwia audyt i kontrolę. Jednak zakres uprawnień, logowanie audytowe i ochronę przed prompt injection nadal musisz implementować samodzielnie. Standard daje ci wspólny język, nie gotową warstwę bezpieczeństwa.
Jaka jest różnica między MCP a zwykłym REST API?
REST API to ogólny protokół wymiany danych. MCP to protokół zaprojektowany specjalnie dla agentów AI — definiuje, w jaki sposób agent odkrywa, jakie narzędzia oferuje serwer (discovery), jak je wywołuje i jak otrzymuje ustrukturyzowane wyniki, które LLM potrafi przetworzyć. REST API może znajdować się za serwerem MCP (serwer wywołuje REST API wewnętrznie), lecz w kierunku agenta komunikacja odbywa się przez MCP.
Czy potrzebuję MCP, jeśli mam tylko jednego agenta z dwoma narzędziami?
Prawdopodobnie nie. Jeśli zakres agenta jest mały i stabilny — dwa lub trzy narzędzia, jeden model, brak planowanych zmian — własny konektor jest prostszy i bardziej bezpośredni. MCP ma sens, gdy narzędzi przybywa, modeli jest więcej lub gdy przewidujesz, że konektory będą wielokrotnie używane przez kolejnych agentów.
Gdzie znajdę gotowe serwery MCP dla popularnych systemów?
Anthropic i społeczność utrzymują publiczny rejestr serwerów MCP na github.com/modelcontextprotocol/servers. Znajdziesz tam serwery dla PostgreSQL, systemu plików, GitHub, Slack, Google Drive, Jira i dziesiątków innych. Większość jest open-source i możliwa do adaptacji na potrzeby własnej infrastruktury.
*Jeśli rozważasz wdrożenie agentów AI w swojej firmie i szukasz sposobu na ich połączenie z istniejącymi systemami, chętnie omówimy konkretną architekturę — co standaryzować przez MCP, gdzie budować własne rozwiązania i jakie są realne zagrożenia bezpieczeństwa, którymi należy się zająć przed wejściem na produkcję. MP Industrial Solutions realizuje takie integracje dla firm produkcyjnych i przemysłowych na Słowacji i w Europie Środkowej.*