Model Context Protocol (MCP) 2026: co to, kto go używa i dlaczego stał się standardem 

Model Context Protocol (MCP) to otwarty standard, który pozwala modelowi językowemu sięgać po dane i funkcje Twojej firmy bez pisania osobnej integracji do każdego narzędzia. Wypadł w listopadzie 2024 roku jako projekt Anthropic, a w grudniu 2025 trafił do Linux Foundation. Dziś wspierają go OpenAI, Google, Microsoft, GitHub, Cloudflare i Salesforce, a protokół ma kilkanaście tysięcy publicznych serwerów. Nie jest jednak pozbawiony wad: audyt ponad 5200 serwerów pokazał, że ponad połowa z nich opiera się na statycznym kluczu API, a tylko 8,5% używa OAuth.

W tym artykule rozkładam MCP na cztery pytania: czym jest, kto go używa, ile tego naprawdę jest i co z tym zrobić w firmie, która nie ma działu IT. Bez encyklopedycznych definicji i bez obietnic. Przy każdej liczbie podaję, skąd pochodzi i kiedy ją zmierzono, bo w tym temacie liczby rozjeżdżają się nawet dziesięciokrotnie.

Czym jest Model Context Protocol

MCP to otwarty standard, który łączy systemy AI z aplikacjami zewnętrznymi. Analogia, którą powtarza Cloudflare w swojej dokumentacji, jest tu trafna: tak jak USB-C dało jeden port do podłączania różnych akcesoriów, tak MCP daje jeden sposób podłączania agenta do różnych usług.

Google Cloud ujmuje to w jednym zdaniu: MCP dostarcza bezpiecznego i ustandaryzowanego „języka”, przez który modele językowe komunikują się z zewnętrznymi danymi, aplikacjami i usługami. W praktyce chodzi o coś bardzo prostackiego. Zamiast pisać kod, który mówi modelowi „w tej chwili wywołaj to API i wklej mi odpowiedź”, piszesz raz opis narzędzia i ten opis działa z każdym klientem, który mówi po protokole MCP.

Warto odróżnić MCP od dwóch rzeczy, które często się z nim mieszają. Po pierwsze, to nie jest API. Twoje API nadal tam jest - MCP nie zastępuje go, tylko ujednolica sposób, w jaki agent po nie sięga. Po drugie, to nie jest RAG. Google Cloud rozróżnia to wprost: RAG znajduje informacje i używa ich do tworzenia tekstu, MCP jest szerszym systemem interakcji i działania. Przez MCP agent nie tylko czyta dokument, tylko wywołuje funkcję, która zmienia stan w systemie.

Problem, który MCP rozwiązuje: N razy M

Zanim powstał standard, każdy model i każde narzędzie wymagały osobnego połączenia. Trzy modele i trzy systemy firmowe to dziewięć integracji, pięć modeli i pięć systemów to dwadzieścia pięć. Google Cloud nazywa to wprost problemem „N x M”: liczba wymaganych połączeń rosła bardzo szybko przy każdym nowym modelu lub narzędziu. Salesforce opisuje to identycznie, tylko jako wzrost wykładniczy.

Ten problem jest szczególnie bolesny w firmach, gdzie systemów jest dużo: CRM, księgowość, magazyn, e-mail, kalendarz, wewnętrzne narzędzia. Każda para „model + system” to osobny projekt, osobne utrzymanie, osobne miejsce, w którym coś się psuje. Przy pięciu narzędziach i dwóch modelach zamiast dwunastu połączeń robisz dwa.

Jak to działa: host, klient, serwer

Protokół dzieli role na trzy warstwy i warto je rozumieć, bo większość nieporozumień przy wdrożeniach wynika właśnie z tego pomieszania.

• Host - aplikacja, w której pracuje człowiek: asystent AI, agent, IDE, platforma typu Salesforce Agentforce.
• Klient MCP - wbudowany w hosta connector, który łączy się z serwerem i wywołuje jego narzędzia. Jedna instancja klienta ma jedno połączenie z jednym serwerem.
• Serwer MCP - aplikacja, która wystawia narzędzia, zasoby i szablony promptów.

Red Hat zwraca uwagę na szczegół, który często pomija się w opisach: MCP nie łączy bezpośrednio modelu z narzędziem. Komponent klienta odpowiada za dostęp do modelu, komponent serwera za dostęp do narzędzia. Zwykły użytkownik może podłączyć dowolną liczbę serwerów do jednego klienta, ale każde połączenie jest osobne i osobno autoryzowane.

Komunikacja idzie przez JSON-RPC 2.0, czyli ten sam format wiadomości, którego używa się w komunikacji klient-serwer w wielu innych protokołach. Dzięki temu ruch MCP da się rozpoznać w logach bez zgadywania: każde żądanie ma pole „method” z wartościami typu „tools/call”, „prompts/get” albo „initialize”. Zespoły bezpieczeństwa używają tego do wykrywania ruchu na brzegu sieci.

Trzy rzeczy, które serwer wystawia

Serwer MCP udostępnia trzy rodzaje prymitywów, a klient dodaje trzy własne. Nie trzeba tego uczyć się na pamięć, ale warto wiedzieć, bo to wyznacza, co da się zrobić.

• Zasoby (resources) - dane tylko do odczytu, do których model może sięgnąć jako do kontekstu.
• Narzędzia (tools) - wykonywalne funkcje, dzięki którym agent może działać, a nie tylko czytać.
• Szablony promptów (prompts) - przygotowane wzorce i przepływy, które prowadzą zachowanie modelu.

Po stronie klienta są: sampling (serwer może poprosić klienta o wywołanie modelu, ale zgodą klienta), roots (granice dostępu do systemu plików i URI, czyli co klient w ogóle udostępnia) oraz elicitation (serwer może poprosić użytkownika o dodatkową informację w trakcie pracy).

Ostatnie dwie są mniej znane, a mają spore znaczenie praktyczne. Roots dają Ci sposób na powiedzenie: „ten agent ma dostęp tylko do folderu faktur, nie do całego dysku”. Elicitation zamienia serię zgadywania w pytanie do człowieka w trakcie wykonania zadania.

Transport: stdio i Streamable HTTP

Są dwa transporty i różnią się tym, gdzie działa serwer. Lokalnie, czyli na tej samej maszynie co agent, MCP używa stdio, czyli komunikacji wejście-wyjście między procesami. Zdalnie, przez internet, transportem jest Streamable HTTP, a dostęp do zasobów użytkownika autoryzuje się przez OAuth.

Zmiana z 26 marca 2025 roku była istotna: Streamable HTTP zastąpił wcześniejszy HTTP+SSE. Starszy wariant jest oznaczony jako przestarzały i wciąż pojawia się w dokumentacji firm, które nie aktualizują jej od roku - jeśli czytasz opis MCP i widzisz „Server-Sent Events dla zdalnych zasobów”, to masz przed sobą tekst sprzed połowy 2025 roku.

Oficjalny projekt świadomie nie dodaje kolejnych transportów. W roadmapie na 2026 rok napisano wprost, że w tym cyklu nie dodają nowych oficjalnych transportów, tylko rozwijają istniejące, i że utrzymanie małego zbioru to świadoma decyzja wynikająca z zasad projektu MCP.

Kto używa MCP w 2026 roku

To jest najmocniejszy argument za standardem: nie jest to inicjatywa jednej firmy, tylko wspólny kontrakt między konkurentami. Według danych producentów przywołanych w analizach, protokół wspierają między innymi:

Kto	Co zrobił w ramach MCP
Anthropic	Autor protokołu, premiera 25 listopada 2024 roku wraz z SDK i serwerami dla własnych narzędzi. W grudniu 2025 przekazała protokół fundacji Agentic AI Foundation przy Linux Foundation.
OpenAI	Wspieranie MCP w ChatGPT Desktop, Agents SDK oraz przez powierzchnię narzędzi w Responses API, w tym konektory i zdalne serwery MCP.
Google	Obsługa MCP w Gemini SDK z automatycznymi pętlami wywoływania narzędzi oraz wsparcie w Agent Development Kit dla Vertex AI Agent Builder.
Microsoft	Podłączanie agenta do istniejącego serwera MCP w Copilot Studio przez transport strumieniowy.
GitHub	Oficjalny serwer MCP GitHuba, publiczne podglądowe wydanie ogłoszone w kwietniu 2025 roku.
AWS	AgentCore Bedrock uruchamia MCP obok protokołów komunikacji między agentami, jako wartości domyślne, które się uzupełniają.
Cloudflare	Własne wdrożenie na poziomie strategii AI firmy, hosting serwerów zdalnych i referencyjna architektura dla przedsiębiorstw z 14 kwietnia 2026 roku.
Salesforce	Agentforce jako przykład hosta MCP: agent pobiera dane z narzędzia marketingowego, porównuje je z kwotami w CRM i przygotowuje kampanię.

Fundacja Agentic AI Foundation powstała przy Linux Foundation, a założyły ją Anthropic, Block i OpenAI, przy wsparciu Google, Microsoft, AWS, Cloudflare i Bloomberg. To w praktyce oznacza, że protokół ma już status prawny typu „Model Context Protocol, a Series of LF Projects, LLC” zamiast pozostawać w repozytorium jednej firmy. Opis całego obecnego rozwoju protokołu znajdziesz w oficjalnej dokumentacji MCP.

Oficjalna roadmapa na 2026 rok opublikowana 9 marca 2026 roku wyznacza cztery priorytety: ewolucja transportu i skalowalność, komunikacja między agentami, dojrzewanie governance i gotowość przedsiębiorcza. Dwie rzeczy warto odnotować, bo często zakłada się odwrotnie. Po pierwsze, od listopada 2025 roku nie wydano nowej wersji specyfikacji, choć projekt nie stał w miejscu. Po drugie, dedykowana grupa robocza do spraw przedsiębiorstw jeszcze nie istnieje, a problemy, które zgłaszają firmy, są przewidywalne: ścieżki audytu, autoryzacja zintegrowana z logowaniem jedno-kliknięciem, zachowanie gatewaya i przenośność konfiguracji.

Ile tego naprawdę jest

Tutaj zaczyna się problem, bo w sieci krąży kilka zupełnie różnych liczb i wszystkie obecnie w obiegu.

• Ponad 10 000 aktywnych publicznych serwerów - to liczba z aktualizacji ekosystemu Anthropic z 9 grudnia 2025 roku, cytowana przez serwisy analityczne.
• 9 652 najnowsze wpisy serwerów i 28 959 rekordów serwer/wersja w oficjalnym rejestrze MCP, policzone 24 maja 2026 roku.
• 15 926 repozytoriów z tematem „mcp-server” na GitHubie, ta sama data pomiaru. Repozytorium z serwerami Anthropic miało wtedy 86 148 gwiazdek i 10 799 forków.
• 2 500 do 4 000 serwerów produkcyjnej klasy - to szacunek, nie pomiar; strona, która go publikuje, sama odradza traktowania jakichkolwiek nagłówków powyżej 20 000 serwerów jako twardej danej, jeśli źródło nie podaje metody weryfikacji.

Te liczby nie są ze sobą sprzeczne, opisują po prostu różne rzeczy: wpisy w rejestrze, repozytoria na GitHubie, publiczne wdrożenia i wdrożenia naprawdę używane przez firmy. Ale kiedy ktoś pisze „MCP ma 90 000 serwerów”, to zwykle zlicza wszystko, co kiedykolwiek zostało zarejestrowane.

Podobnie jest z pobraniami SDK. Jedna liczba, która ma potwierdzenie, to ponad 97 milionów pobrań miesięcznie dla Pythona i TypeScriptu wraz, pochodząca z aktualizacji Anthropic z grudnia 2025 roku. W sieci pojawiła się też wersja „ponad 400 milionów miesięcznie”, ale pochodzi ze strony sprzedażowej, która w jednym akapicie pisze o 97 milionach, a w tabeli na końcu artykułu o 400 milionach. Nie podaję tej drugiej jako faktu, bo sama strona się sobie zaprzecza.

Jest jeszcze badanie Stacklok o stanie MCP w branży oprogramowania, które mówi o 41% firm w produkcji (45% w samej branży oprogramowania). Podawaj je z zastrzeżeniem: jedno źródło mówi o 100 odpowiedziach od liderów technicznych, drugie o 300, a tabela z procentami jest w obu identyczna. Warto wiedzieć, że krążące po branży „78% firm enterprise używa MCP w produkcji” wycofało się kilka publikacji, bo nie dało się znaleźć za tym żadnej próby.

Bezpieczeństwo: gdzie MCP się sypie

MCP daje agentowi dostęp do działania, więc każda podatność działa dwa razy ostrzej. Red Hat wymienia obszary ryzyka wprost: uwierzytelnianie i autoryzacja, ryzyko łańcucha dostaw, nieautoryzowane wykonanie poleceń, prompt injection, tool injection, sampling, logowanie i zarządzanie podatnościami.

Najczęściej cytowany problem to „confused deputy”. Serwer MCP dostaje polecenie i wykonuje je w imieniu użytkownika, ale uprawnienia, których używa, należą do serwera, nie do człowieka. Red Hat zaznacza wprost, że to nie jest zagwarantowane i zależy od implementacji serwera. W praktyce: agent, który miał odczytać fakturę, może wywołać narzędzie, które ma też prawo zaznaczyć ją jako opłaconą.

Drugi to tool poisoning, czyli zatrucie opisu narzędzia. Serwer może wyglądać bezpiecznie przy instalacji - kod i opisy narzędzi są normalne - a zmienić się przy późniejszej aktualizacji. Zatruty opis uruchamia się przy każdym wywołaniu, po cichu, u każdego użytkownika. Klasyczny prompt injection wymaga ciągłego dostarczania, ten dostarcza się raz i działa dalej.

Trzeci to sampling: skoro serwer może poprosić klienta o wywołanie modelu, złośliwy serwer może w ten sposób generować treść albo generować koszt po Twojej stronie. Red Hat zaleca, żeby klienci pokazywali użytkownikowi takie żądanie, pozwalamy je odrzucić lub zmodyfikować, oraz żeby mieli limity tempa, limity kosztu i limity czasu.

Skala problemu jest mierzalna. Audyt ponad 5200 serwerów wykazał, że 88% wymaga jakichś poświadczeń, ale wśród nich 53% opiera się na statycznych kluczach API albo tokenach dostępu, tylko 8,5% używa OAuth, a około 79% przekazuje klucze przez zmienne środowiskowe. Badanie akademickie na 1899 serwerach podaje 7,2% serwerów z ogólnymi podatnościami i 5,5% niosących ryzyko zatrucia narzędzi. Osobne źródło podaje, że ścieżka przez MCP daje od 23% do 41% wyższą podatność na atak niż integracja bezpośrednia, na podstawie 847 scenariuszy ataku na 5 serwerach. Nie jest to zaskoczenie, jeśli wcześniej traktowało się AI jako dodatek do narzędzi biurowych; cyberbezpieczeństwo napędzane przez AI to osobna kategoria, która właśnie dojrzewa razem z protokołem.

Ankieta Stacklok pokazuje, że firmy to widzą: dla 64% respondentów główną barierą przy wdrożeniu było właśnie bezpieczeństwo, 69% organizacji planuje budować własną platformę MCP z komponentów open source, a hosting dzieli się niemal po równo między chmurę prywatną (29%) a SaaS (29%).

Lista kontroli, którą warto wdrożyć u siebie, jest krótka i pochodzi z Red Hat: podpisywanie komponentów przez autora, statyczna analiza bezpieczeństwa aplikacji w potoku, analiza kompozycji zależności, kryptograficzna weryfikacja serwera, uruchamianie lokalnych serwerów w piaskownicy, ograniczanie roots do ścieżek, których agent naprawdę potrzebuje, i wymaganie potwierdzenia użytkownika przed każdą operacją zmieniającą stan. Cloudflare dochodzi do tego własną obserwacją z wdrożenia: bardzo szybko okazało się, że lokalnie hostowane serwery MCP są zobowiązaniem bezpieczeństwa, i firma przeniosła je na zdalne serwery na własnych domenach z logowaniem operacji zapisu.

MCP a API: co protokół zmienia, a czego nie

Warto powiedzieć wprost, bo to najczęstsze nieporozumienie przy rozmowach z klientami. MCP nie zastępuje API i nie wycofuje REST-a. Ujednolica sposób, w jaki agenci z nich korzystają, w skali. Jeśli masz dziś działające API, MCP nie jest powodem, żeby je przepisywać.

Co MCP realnie zmienia, to sposób, w jaki agent podejmuje decyzję o użyciu narzędzia. Zamiast logiki zapisanej w kodzie, model dostaje listę możliwości i sam dobiera. To wygodniejsze, ale ma dwie konsekwencje, o których mówi sam Cloudflare i Red Hat.

Po pierwsze, wyczerpywanie okna kontekstu. Klasyczne podejście zakłada osobne narzędzie dla każdej operacji API, a to przy platformie z tysiącami punktów końcowych szybko zjada kontekst. Cloudflare zmierzył to na własnym API: 52 narzędzia zużywały około 9400 tokenów samego opisu. Po włączeniu trybu Code Mode te 52 narzędzia zwęziły się do 2 narzędzi portalowych przy około 600 tokenach, czyli redukcja o 94%, a na skalę pojedynczych punktów końcowych mówią o 99,9%. To pomiar wewnętrzny jednej firmy, nie niezależny benchmark, ale kierunek jest jasny: mniej, lepiej zaprojektowanych narzędzi bije ich tłum.

Po drugie, skalowanie. Sesje ze stanem kłócą się z balanserami, skalowanie poziome wymaga obejść, a rejestr ani crawler nie ma standardowego sposobu, żeby dowiedzieć się, co serwer potrafi, bez połączenia się z nim. To między innymi powody, dla których w 2026 roku priorytetem są ewolucja transportu i skalowalność, a nie kolejne funkcje.

Jak zacząć, jeśli chcesz to mieć u siebie

Kolejność, która działa, zaczyna się od jednego procesu, a nie od listy narzędzi. Wybierz to, co dziś zjada najwięcej godzin tygodniowo, i sprawdź, czy da się to podpiąć przez MCP. Jeśli nie masz pojęcia, od czego zacząć, połączenie modelu z n8n pokazuje ten sam mechanizm na narzędziu, które pewnie masz już na koncie. W praktyce często wystarcza kilka serwerów: dostęp do dokumentów, do systemu zgłoszeń, do bazy klientów i do wewnętrznych statystyk. Reszta firmowych aplikacji, które mają już API, może zostać tam, gdzie jest.

Druga rzecz: nie ufaj serwerowi, którego nie sprawdziłeś. Jeśli agent ma dostęp do czegoś, co zmienia stan w systemie, to zabezpieczenia z listy Red Hat nie są teorią, tylko warunkiem uruchomienia. Prompt potwierdzający przed operacją, wąskie roots, osobne środowisko testowe i dziennik tego, co agent zrobił.

Trzecia: pilnuj, żeby ktoś w firmie rozumiał, co agent może, a czego nie. Najtańsze zabezpieczenie to osoba, która zna proces i potrafi powiedzieć „to nie tak, to jest krok, którego nie wolno wykonać automatycznie”. Reszta mechanizmów to software, a to jest kwestia świadomości.

Jeśli chcesz przejść to krok po kroku na własnym procesie, a nie tylko przeczytać, o czym jest MCP, napisz do mnie - odpowiadam zwykle tego samego dnia. Od tego, co chcesz zautomatyzować, przez zakres i wycenę na piśmie, po wdrożenie. Możesz też zacząć od testu 10 zadań biznesowych dla agentów AI, żeby sprawdzić, które z Twoich zadań w ogóle da się automatyzować, a które lepiej zostawić człowiekowi.

Najczęstsze pytania

Czy MCP zastępuje moje API? Nie. Twoje API zostaje tam, gdzie jest. MCP ujednolica sposób, w jaki agent po nie sięga, i pozwala użyć jednego opisu narzędzia w kilku narzędziach zamiast osobnej integracji w każdym.

Czy mogę go używać bez własnego serwera? Tak, o ile korzystasz z klienta, który już coś wystawia: ChatGPT, Cursor, Gemini, Copilot czy VS Code mają wbudowaną obsługę MCP. Własny serwer jest potrzebny dopiero wtedy, gdy chcesz dać agentowi dostęp do swojego systemu.

Co to kosztuje? Protokół jest otwarty i darmowy, a SDK są open source. Koszt pojawia się tam, gdzie zawsze: w utrzymaniu własnego serwera, w zabezpieczeniach, w audycie uprawnień i w czasie wdrożenia. Nie ma tu opłat licencyjnych za sam protokół.

Czy to jest bezpieczne? Nie bez Twojego nadzoru. Protokół daje agentowi możliwość działania, a więc daje też powierzchnię ataku. Wdrożenie bez potwierdzeń użytkownika, z szerokimi uprawnieniami i z kluczami przekazanymi przez zmienne środowiskowe, to konfiguracja, którą audyt na ponad 5200 serwerów właśnie opisał jako najczęstszą.

Czy warto, jeśli mam jedną osobę w IT? Warto, jeśli masz kilka narzędzi, do których chcesz dać dostęp jednemu agentowi, zamiast budować osobne integracje. Nie warto, jeśli masz jedno narzędzie i jednego użytkownika - wtedy zwykłe API wystarczy i będzie prostsze.

Jeśli chcesz, mogę też przygotować dla Ciebie listę konkretnych serwerów MCP pod Twoje narzędzia, z oceną, co z nich realnie da się wykorzystać, a co jest tylko marketingiem. Wystarczy napisać, czym dziś operuje zespół.