Model Context Protocol (MCP) - architektura

Model Context Protocol (MCP) to otwarty standard, przez który aplikacje AI łączą się z zewnętrznymi narzędziami i danymi w jeden, wspólny sposób: host uruchamia klientów, a każdy klient rozmawia z jednym serwerem przez komunikaty JSON-RPC 2.0. Aktualna wersja specyfikacji nosi numer 2026-07-28 i przebudowała protokół na bezstanowy. MCP obsługują dziś między innymi Claude, ChatGPT, Gemini CLI i Visual Studio Code.

Ten przewodnik jest dla zespołów, które wdrażają agentów AI w firmie: opisuje architekturę, prymitywy, transporty, zmiany w najnowszej wersji, wsparcie dostawców i mapę ataków, którą trzeba przejść przed podłączeniem pierwszego serwera do danych firmowych. Wszystkie wymagania techniczne pochodzą ze specyfikacji i oficjalnego dokumentu bezpieczeństwa projektu MCP.

Czym jest Model Context Protocol i jaki problem rozwiązuje

MCP standaryzuje połączenie między aplikacją AI a źródłem kontekstu, dzięki czemu jedno narzędzie wystawione jako serwer MCP działa w każdej aplikacji, która ma klienta MCP. Bez wspólnego standardu każda para „aplikacja AI – system firmowy” wymaga osobnego konektora, a liczba integracji rośnie jak iloczyn obu list zamiast ich sumy.

Anthropic opublikował protokół w listopadzie 2024 roku. Specyfikacja wprost wskazuje wzór: Language Server Protocol, który ujednolicił obsługę języków programowania w edytorach kodu. MCP robi to samo dla narzędzi i danych w aplikacjach AI.

9 grudnia 2025 roku Anthropic przekazał MCP do Agentic AI Foundation, funduszu celowego działającego w ramach Linux Foundation. Współzałożycielami fundacji są Anthropic, Block i OpenAI, a wsparcie zadeklarowały Google, Microsoft, Amazon Web Services, Cloudflare i Bloomberg. Dla firm oznacza to, że standard nie jest już własnością jednego dostawcy modeli.

Element	Wartość
Format komunikatów	JSON-RPC 2.0, kodowanie UTF-8
Aktualna wersja specyfikacji	2026-07-28
Opiekun	Agentic AI Foundation (Linux Foundation)
Oficjalne SDK pierwszej kategorii	TypeScript, Python, Go, C#, Rust, Ruby (Tier 1 według dokumentacji projektu)
Skala według Anthropic (grudzień 2025)	ponad 10 tys. aktywnych publicznych serwerów i ponad 97 mln miesięcznych pobrań SDK dla Pythona i TypeScriptu

MCP nie zastępuje mechanizmu wywoływania funkcji w modelu. Function calling decyduje, że model chce użyć narzędzia, a MCP określa, skąd aplikacja bierze listę narzędzi i jak przekazuje wywołanie do systemu, który je wykona.

Architektura MCP: host, klient i serwer

Architektura MCP ma trzy role: host to aplikacja AI, klient to konektor wewnątrz hosta, a serwer to usługa wystawiająca narzędzia i dane – przy czym każdy klient rozmawia z dokładnie jednym serwerem. Host tworzy tylu klientów, ile serwerów podłącza, i to on pilnuje granic bezpieczeństwa między nimi.

Rola	Czym jest	Za co odpowiada według specyfikacji
Host	aplikacja AI, np. Claude, ChatGPT, IDE z agentem	tworzy klientów, egzekwuje polityki bezpieczeństwa i zgody, podejmuje decyzje autoryzacyjne użytkownika, koordynuje model i agreguje kontekst
Klient	konektor tworzony przez hosta	łączy się z jednym serwerem, dołącza wersję protokołu i swoje możliwości do każdego żądania, obsługuje subskrypcje, utrzymuje granice między serwerami
Serwer	proces lokalny albo usługa zdalna	wystawia narzędzia, zasoby i prompty, działa niezależnie, prosi klienta o dodatkowe dane w odpowiedzi na żądanie

Najważniejsza zasada projektowa dla bezpieczeństwa brzmi w specyfikacji tak: serwer nie powinien móc odczytać całej rozmowy ani „zajrzeć” do innych serwerów. Pełna historia rozmowy zostaje u hosta, serwer dostaje tylko kontekst potrzebny do żądania, a interakcje między serwerami kontroluje host.

Druga zasada mówi, że serwery mają być bardzo proste w budowie, a złożoną orkiestrację bierze na siebie host. Dlatego firmowy serwer MCP do systemu zgłoszeń albo bazy produktów buduje się na oficjalnym SDK jako małą usługę, a nie jako osobny projekt integracyjny. W systemach wieloagentowych ten sam serwer obsługuje wielu agentów, bo każdy z nich łączy się z nim przez własnego klienta.

Prymitywy MCP: narzędzia, zasoby, prompty i elicytacja

Serwer MCP udostępnia trzy prymitywy: narzędzia (Tools) wywołuje model, zasoby (Resources) dołącza aplikacja, a prompty (Prompts) wybiera użytkownik. Ten podział mówi, kto kontroluje dany element, i to jest najprostszy klucz do projektowania uprawnień.

Prymityw	Kto kontroluje	Co to jest	Przykład
Tools	model	funkcje, którymi model wykonuje akcje albo pobiera informacje	żądanie POST do API, zapis pliku, utworzenie zgłoszenia
Resources	aplikacja	dane kontekstowe dołączane i zarządzane przez klienta, identyfikowane przez URI	zawartość pliku, historia gita, schemat bazy
Prompts	użytkownik	szablony wywoływane wyborem użytkownika	polecenia z ukośnikiem, pozycje menu

Narzędzia opisują parametry schematem JSON Schema. Wersja 2026-07-28 poluzowała inputSchema i outputSchema tak, że dopuszczają dowolne słowa kluczowe JSON Schema 2020-12, a wynik strukturalny (structuredContent) może być dowolną wartością JSON.

Po stronie klienta zostaje jeden aktywny prymityw: elicytacja (Elicitation), czyli prośba serwera o dodatkowe informacje od użytkownika, na przykład brakujący identyfikator projektu albo potwierdzenie. Dwa starsze mechanizmy klienta, Sampling (serwer prosi hosta o wygenerowanie tekstu przez model) i Roots (host wskazuje serwerowi dozwolone katalogi), a także Logging, mają w wersji 2026-07-28 status wycofywanych (zamiast Logging specyfikacja wskazuje stderr w stdio albo OpenTelemetry). Działają co najmniej przez 12 miesięcy, ale nowe wdrożenia nie powinny z nich korzystać. Specyfikacja zaleca zamiast Roots przekazywać katalogi w parametrach narzędzi albo w konfiguracji serwera, a zamiast Sampling łączyć się bezpośrednio z API dostawcy modelu.

Transporty MCP: stdio i Streamable HTTP

MCP definiuje dwa standardowe transporty: stdio dla serwerów uruchamianych lokalnie jako podproces i Streamable HTTP dla serwerów zdalnych, a znaczenie komunikatów jest identyczne w obu. Transport określa tylko, jak wiadomości są ramkowane i dostarczane, więc ten sam serwer może obsługiwać oba.

Transport	Jak działa	Typowe użycie	Status
stdio	klient uruchamia serwer jako podproces, komunikaty JSON-RPC rozdzielone znakiem nowej linii idą przez standardowe strumienie	narzędzia deweloperskie, dostęp do lokalnych plików i repozytoriów	standardowy
Streamable HTTP	każdy komunikat to żądanie POST do jednego endpointu MCP, odpowiedź wraca jako obiekt JSON albo strumień SSE przypisany do żądania	serwery w chmurze, usługi SaaS, serwery firmowe za autoryzacją OAuth	standardowy
HTTP+SSE	starszy transport z osobnym kanałem SSE	starsze wdrożenia	wycofywany od wersji 2025-03-26, w 2026-07-28 formalnie oznaczony jako przeznaczony do usunięcia

Specyfikacja dopuszcza własne transporty, np. gniazda uniksowe, pod warunkiem zachowania formatu JSON-RPC i modelu metadanych przy każdym żądaniu. Dla serwerów lokalnych dokument bezpieczeństwa MCP zaleca stdio, bo ogranicza dostęp do samego klienta. Jeśli serwer lokalny używa HTTP, powinien wymagać tokenu autoryzacyjnego.

Autoryzacja w MCP jest opcjonalna i dotyczy transportów HTTP. Serwer chroniony pełni rolę serwera zasobów OAuth 2.1 i musi publikować metadane zasobu chronionego (RFC 9728), z których klient dowiaduje się, jaki serwer autoryzacji wydaje tokeny. Klient w żądaniach autoryzacji i tokenu podaje parametr resource (RFC 8707), a serwer musi sprawdzać, że token wydano właśnie dla niego. Implementacje stdio nie powinny stosować tego schematu, tylko pobierać poświadczenia ze środowiska.

W Streamable HTTP wersja 2026-07-28 wymaga nagłówków Mcp-Method i Mcp-Name przy każdym żądaniu POST. Dzięki nim bramki i load balancery mogą kierować ruch bez parsowania treści, co upraszcza wdrożenie serwera MCP za firmowym API gateway. Ta sama wersja usunęła wznawianie strumieni SSE (Last-Event-ID): przerwana odpowiedź oznacza utratę żądania, które klient musi wysłać ponownie jako nowe.

Aktualna wersja specyfikacji MCP: 2026-07-28

Wersja 2026-07-28, wydana 28 lipca 2026 roku, zmieniła MCP z protokołu sesyjnego w bezstanowy: każde żądanie samo niesie wersję protokołu i możliwości klienta, a serwery nie utrzymują sesji. Poprzednia wersja nosiła numer 2025-11-25. Dla firm to najważniejsza zmiana od premiery protokołu, bo serwery MCP można teraz skalować poziomo jak zwykłe usługi HTTP.

Obszar	Do wersji 2025-11-25	Od wersji 2026-07-28
Sesja	handshake `initialize`, nagłówek `Mcp-Session-Id`	brak sesji protokołu; wersja i możliwości w polu `_meta` każdego żądania
Odkrywanie serwera	podczas inicjalizacji	obowiązkowe RPC `server/discover` z wersjami, możliwościami i tożsamością serwera
Prośby serwera do klienta	żądania inicjowane przez serwer (`sampling/createMessage`, `elicitation/create`, `roots/list`)	wzorzec Multi Round-Trip Requests: serwer odpowiada `InputRequiredResult`, klient ponawia żądanie z odpowiedziami
Powiadomienia o zmianach	`resources/subscribe` i osobny endpoint GET	jeden strumień `subscriptions/listen`, na który klient zapisuje się do wybranych typów zmian
Cache list	brak	pola `ttlMs` i `cacheScope` w wynikach `tools/list`, `resources/list`, `prompts/list`
Zadania długotrwałe	eksperymentalne w rdzeniu	oficjalne rozszerzenie Tasks z odpytywaniem `tasks/get`
Stan między wywołaniami	w sesji	jawne uchwyty wydane przez serwer, przekazywane jako argumenty narzędzi

Specyfikacja zaleca też, by serwer zwracał narzędzia z tools/list w stałej kolejności. Uzasadnienie jest praktyczne: stała lista poprawia trafienia w cache kontekstu po stronie dostawcy modelu, a to bezpośrednio obniża koszt każdego wywołania.

Wersja 2026-07-28 wprowadziła formalne ramy rozszerzeń. Rozszerzenie działa tylko wtedy, gdy obsługują je obie strony. Najważniejsze to Tasks (asynchroniczne operacje długotrwałe), MCP Apps (interaktywne elementy interfejsu, np. formularze i wykresy, wyświetlane w rozmowie) i Skills over MCP (ustrukturyzowane instrukcje dla agentów, rozwijane przez grupę roboczą projektu). Ta sama wersja przyjęła politykę cyklu życia funkcji: element oznaczony jako wycofywany działa co najmniej 12 miesięcy.

W autoryzacji zmiany są trzy: serwery autoryzacji powinny zwracać parametr iss (RFC 9207), a klient musi porównać obecny iss z zapisanym wystawcą, zanim wymieni kod na token; poświadczenia klienta są przypisane do serwera autoryzacji, który je wydał, a dynamiczna rejestracja klientów (RFC 7591) jest wycofywana na rzecz dokumentów Client ID Metadata Documents (CIMD), w których identyfikatorem klienta jest adres HTTPS z dokumentem metadanych, pobieranym przez serwer autoryzacji; DCR zostaje dla zgodności ze starszymi serwerami autoryzacji.

Historia wersji

Wersja	Co wniosła
2024-11-05	pierwsza publiczna specyfikacja
2025-03-26	transport Streamable HTTP, wycofanie HTTP+SSE
2025-06-18	elicytacja, czyli prośby serwera o dane od użytkownika
2025-11-25	eksperymentalne zadania, elicytacja w trybie URL
2026-07-28	bezstanowy rdzeń, `server/discover`, Multi Round-Trip Requests, rozszerzenia, wycofanie Roots, Sampling i Logging

Implementacje zgodne z wcześniejszymi wersjami dalej działają. Specyfikacja opisuje mechanizm, którym klient i serwer rozpoznają wersję drugiej strony i przechodzą na starszy tryb z handshake.

Kto wspiera Model Context Protocol

MCP obsługują wszyscy najwięksi dostawcy narzędzi AI: Anthropic, OpenAI, Google i Microsoft, a także popularne edytory kodu, takie jak Cursor. W grudniu 2025 roku Anthropic podawał ponad 10 tys. aktywnych publicznych serwerów MCP i ponad 97 mln miesięcznych pobrań SDK dla Pythona i TypeScriptu łącznie.

Dostawca	Gdzie działa MCP	Co warto wiedzieć
Anthropic	Claude (aplikacje i API), Claude Code	twórca protokołu; katalog konektorów w Claude
OpenAI	Responses API, ChatGPT, Codex	narzędzie `mcp` w Responses API obsługuje Streamable HTTP i HTTP/SSE; domyślnie prosi o zgodę przed przekazaniem danych do serwera; Secure MCP Tunnel łączy prywatne serwery bez otwierania portów w zaporze
Google	Gemini CLI, zdalne serwery Google Cloud	serwery deklarowane w `settings.json`; Google udostępnia zdalne serwery MCP m.in. dla BigQuery i Cloud SQL
Microsoft / GitHub	Visual Studio Code z GitHub Copilot	konfiguracja w `.vscode/mcp.json`, galeria serwerów pod hasłem `@mcp`, rejestr serwerów GitHub MCP Registry
Cursor	edytor kodu z agentem	agent edytora korzysta z lokalnych i zdalnych serwerów MCP

Do odkrywania serwerów służy oficjalny rejestr MCP Registry, rozwijany przez społeczność projektu. Do testowania własnego serwera projekt udostępnia narzędzie MCP Inspector, które pozwala wywoływać narzędzia i podglądać komunikaty bez podłączania modelu.

OpenAI w dokumentacji zaznacza, że zdalne serwery MCP stron trzecich nie są przez nią weryfikowane, a parametr allowed_tools pozwala ograniczyć listę narzędzi widocznych dla modelu. Uzasadnienie jest kosztowe: serwer z dziesiątkami narzędzi zwiększa koszt i opóźnienie każdego zapytania.

MCP a API, RAG, function calling i A2A

MCP nie jest konkurencją dla API ani RAG, tylko warstwą, która je udostępnia modelowi: API wykonuje operację, RAG dostarcza wiedzę, a MCP ustala, jak agent odkrywa i wywołuje jedno i drugie. Z A2A MCP się uzupełnia, bo A2A łączy agentów ze sobą, a MCP agenta z narzędziami.

Porównanie	Czym jest drugi element	Relacja z MCP
MCP a API	interfejs konkretnego systemu, np. REST API CRM	serwer MCP zwykle owija istniejące API i opisuje je modelowi w jednolitym formacie, z odkrywaniem narzędzi i zgodami
MCP a RAG	technika dołączania wyszukanych dokumentów do kontekstu	wyszukiwarka wektorowa może działać jako narzędzie albo zasób serwera MCP; tak budowany jest agentic RAG
MCP a HTTP	protokół transportowy sieci	Streamable HTTP to jeden z transportów MCP; MCP definiuje znaczenie komunikatów, HTTP tylko je przenosi
MCP a function calling	mechanizm modelu do zgłaszania wywołania funkcji	function calling generuje wywołanie, MCP dostarcza definicje narzędzi i realizuje wywołanie po stronie serwera
MCP a A2A	protokół komunikacji między agentami	protokół A2A służy do delegowania zadań między agentami, MCP do korzystania z narzędzi i danych

Bezpieczeństwo MCP: prompt injection, tool poisoning i uprawnienia

Specyfikacja MCP sama nie egzekwuje bezpieczeństwa: wymaga, by host uzyskał wyraźną zgodę użytkownika przed każdym wywołaniem narzędzia, i każe traktować opisy narzędzi jako niezaufane, jeśli nie pochodzą z zaufanego serwera. Całą resztę zabezpieczeń muszą zbudować twórcy hostów i serwerów, a oficjalny dokument „Security Best Practices” projektu MCP opisuje, przed czym konkretnie.

Specyfikacja formułuje trzy zasady: zgoda i kontrola użytkownika nad każdym dostępem do danych i każdą operacją, ochrona prywatności (host nie przekazuje danych użytkownika serwerom bez zgody) oraz bezpieczeństwo narzędzi, które według specyfikacji oznaczają wykonanie dowolnego kodu.

Prompt injection i tool poisoning

Prompt injection w MCP polega na tym, że instrukcje dla modelu przychodzą w danych z serwera, a tool poisoning to jego odmiana, w której złośliwe polecenie siedzi w opisie narzędzia. Model czyta opisy narzędzi jako zwykły tekst w kontekście, więc nie odróżnia opisu funkcji od wstrzykniętego rozkazu.

Termin „tool poisoning” wprowadziła firma Invariant Labs w kwietniu 2025 roku, pokazując serwer z niewinnym narzędziem do dodawania liczb, którego opis kazał modelowi odczytać klucz SSH i plik konfiguracyjny MCP. Skalę problemu zmierzył benchmark MCPTox (Wang i in., arXiv, 2025): 45 rzeczywistych serwerów MCP, 353 narzędzia, 1 348 złośliwych przypadków i 20 agentów. Najwyższy odsetek udanych ataków wyniósł 72,8% (o1-mini), a najwyższy odsetek odmów nie przekroczył 3% (Claude 3.7 Sonnet). Autorzy zauważyli, że modele lepiej wykonujące polecenia są bardziej podatne, bo atak wykorzystuje właśnie tę zdolność.

OpenAI w dokumentacji narzędzia MCP ujmuje ryzyko wprost: złośliwy serwer może wyprowadzić wrażliwe dane ze wszystkiego, co trafi do kontekstu modelu. Najlepszy model oceny ryzyka to „lethal trifecta” Simona Willisona z 2025 roku: atak jest groźny, gdy agent ma jednocześnie dostęp do prywatnych danych, styczność z niezaufaną treścią i kanał komunikacji na zewnątrz. Odcięcie jednego z trzech elementów zamyka najprostszą ścieżkę wycieku. Szerzej o tej klasie zagrożeń w agentach firmowych piszę w tekście o bezpieczeństwie agentów AI i RAG.

Ataki na autoryzację i infrastrukturę

Oficjalny dokument bezpieczeństwa MCP opisuje ponad dziesięć scenariuszy ataków, a większość z nich dotyczy błędów w OAuth i w uruchamianiu lokalnych serwerów, nie samego modelu. Każdy ma przypisane wymagania typu MUST albo SHOULD; tabela zbiera najważniejsze.

Atak	Na czym polega	Wymaganie z dokumentu MCP
Confused deputy	serwer-proxy ze statycznym client ID do API trzeciej strony pozwala atakującemu przejąć kod autoryzacji, wykorzystując zapamiętaną zgodę	proxy MUST prowadzić zgodę osobno dla każdego klienta i dokładnie porównywać `redirect_uri`
Token passthrough	serwer przyjmuje token wydany dla innej usługi i przekazuje go dalej	serwer MUST NOT przyjmować tokenów, które nie zostały wydane dla niego (walidacja odbiorcy tokenu wg RFC 8707); wzorzec jest zakazany w specyfikacji autoryzacji
SSRF	złośliwy serwer podaje w metadanych OAuth adresy wewnętrzne, np. `169.254.169.254` z poświadczeniami chmury	klient SHOULD wymagać HTTPS i blokować prywatne zakresy IP
Przejęcie uchwytu stanu	atakujący zgaduje identyfikator stanu (np. koszyka) i działa na cudzych danych	posiadanie uchwytu MUST NOT być uwierzytelnieniem; uchwyty losowe i powiązane z użytkownikiem
Kompromitacja lokalnego serwera	złośliwe polecenie startowe w konfiguracji albo złośliwy kod w pakiecie serwera	klient z instalacją jednym kliknięciem MUST pokazać pełne polecenie i uzyskać zgodę; zalecany sandbox
Złośliwy URL autoryzacji	adres `javascript:` albo z wstrzyknięciem polecenia powłoki	klient MUST dopuszczać tylko `https://` (i `http://` dla localhost) i MUST NOT otwierać adresów przez powłokę
Mix-up	podstawiony serwer autoryzacji przechwytuje kod wydany przez inny	walidacja parametru `iss` zgodnie z RFC 9207
Zbyt szerokie scope	wykradziony token z uprawnieniami `admin:*` otwiera wszystkie narzędzia	minimalny zestaw startowy i stopniowe podnoszenie uprawnień

Lista kontrolna wdrożenia w firmie

Bezpieczne wdrożenie MCP w firmie sprowadza się do trzech decyzji: które serwery są zaufane, jakie uprawnienia dostaje każdy z nich i które wywołania wymagają zgody człowieka. Poniższa lista łączy wymagania specyfikacji z zaleceniami dokumentu bezpieczeństwa.

Rejestr dozwolonych serwerów. Tylko serwery z zaufanego źródła, z przypiętą wersją. Zmiana opisu narzędzia po aktualizacji to sygnał do ponownej oceny, bo opis trafia do kontekstu modelu.
Najmniejsze uprawnienia. Osobne konto techniczne i wąskie scope dla każdego serwera, bez tokenów z uprawnieniami całej organizacji.
Zgoda przed akcją. Wywołania zapisujące, usuwające i wysyłające dane na zewnątrz przechodzą przez potwierdzenie użytkownika, czyli wzorzec human in the loop. W Responses API odpowiada za to parametr require_approval.
Ograniczona lista narzędzi. Model widzi tylko narzędzia potrzebne do zadania, co zmniejsza powierzchnię ataku i koszt.
Izolacja serwerów lokalnych. stdio zamiast otwartego portu HTTP, uruchamianie w kontenerze, bez dostępu do kluczy SSH i katalogu domowego.
Logi i telemetria. Rejestrowanie wywołań narzędzi; wersja 2026-07-28 opisuje przekazywanie kontekstu OpenTelemetry w polu _meta.
Kontrola samowolnych instalacji. Pracownicy podłączający własne serwery MCP do firmowych danych to nowa odmiana shadow AI, którą trzeba objąć polityką.

FAQ

Co to jest Model Context Protocol?

Model Context Protocol to otwarty standard łączenia aplikacji AI z narzędziami i danymi. Aplikacja (host) uruchamia klientów, z których każdy komunikuje się z jednym serwerem przez JSON-RPC 2.0. Serwer wystawia narzędzia, zasoby i prompty. Protokół stworzył Anthropic w 2024 roku, a dziś rozwija go Agentic AI Foundation w ramach Linux Foundation.

Czym różni się MCP od API?

API to interfejs konkretnego systemu, na przykład CRM albo bazy danych. MCP to wspólny format, w którym aplikacja AI odkrywa dostępne narzędzia, poznaje ich parametry i wywołuje je za zgodą użytkownika. Serwer MCP zwykle owija istniejące API, więc nie zastępuje go, tylko udostępnia modelowi w ustandaryzowany sposób.

Czym różni się MCP od RAG?

RAG to technika dołączania wyszukanych dokumentów do kontekstu modelu, a MCP to protokół łączenia modelu z narzędziami i danymi. Te pojęcia działają na różnych poziomach: wyszukiwarka dokumentów może być narzędziem albo zasobem serwera MCP. Agent korzystający z takiego serwera sam decyduje, kiedy i czego szukać.

Czy MCP to to samo co HTTP?

Nie. HTTP to protokół transportowy, a MCP definiuje znaczenie komunikatów: odkrywanie narzędzi, wywołania, zasoby i prośby o dane od użytkownika. Streamable HTTP jest jednym z dwóch standardowych transportów MCP, obok stdio dla serwerów lokalnych. Te same komunikaty MCP znaczą to samo niezależnie od tego, którym transportem są przesyłane.

Czy MCP działa bez internetu?

Tak, jeśli serwer działa lokalnie. W transporcie stdio host uruchamia serwer jako podproces na tym samym komputerze i wymienia z nim komunikaty przez standardowe strumienie, bez połączenia sieciowego. Internet jest potrzebny do serwerów zdalnych przez Streamable HTTP oraz do samego modelu, jeśli działa w chmurze dostawcy.

Czy Model Context Protocol jest bezpieczny?

MCP jest tak bezpieczny, jak jego wdrożenie. Specyfikacja wymaga zgody użytkownika przed wywołaniem narzędzia, ale nie może jej wymusić na poziomie protokołu. Główne ryzyka to prompt injection, tool poisoning, przekazywanie tokenów i zbyt szerokie uprawnienia. Ograniczają je zaufane serwery, minimalne uprawnienia, potwierdzanie akcji i izolacja serwerów lokalnych.