Masz model AI, który świetnie rozumuje, ale nie może sprawdzić stanu twojego repozytorium, zapytać firmowej bazy danych ani odczytać pliku z dysku — chyba że ktoś napisze dla niego dedykowaną integrację. I właśnie tu pojawia się pytanie, które zadaje sobie coraz więcej deweloperów: czy musi tak być?
Model Context Protocol (MCP) to otwarty protokół opracowany przez Anthropic i opublikowany jako open source w listopadzie 2024 roku, który pozwala modelom językowym łączyć się z zewnętrznymi źródłami danych i narzędziami przez jednolity, standaryzowany interfejs. Zamiast pisać osobną integrację dla każdej kombinacji modelu i systemu zewnętrznego, wystarczy jeden serwer MCP po stronie źródła danych i jeden klient MCP po stronie aplikacji AI. Protokół działa na licencji MIT i nie wymaga żadnych opłat.
Przed MCP każdy deweloper stał przed problemem skali: dziesięć modeli AI i dziesięć źródeł danych oznaczało potencjalnie sto różnych integracji do napisania i utrzymania. MCP eliminuje tę zależność przez ujednolicenie warstwy komunikacji. Poniższe sekcje opisują, jak to działa od środka, jak uruchomić pierwszy serwer i jak uniknąć typowych błędów przy wdrożeniu.
Architektura MCP: hosty, klienty i serwery
Protokół opiera się na trzech warstwach. Hosty to aplikacje inicjujące połączenia — przykładem jest Claude Desktop lub środowisko IDE z obsługą MCP. Klient MCP działa wewnątrz hosta i utrzymuje połączenie jeden do jednego z konkretnym serwerem. Serwer to lekki program, który udostępnia dane lub funkcje przez standardowy protokół — może działać lokalnie, bez dostępu do internetu, albo jako usługa zdalna.
Ważne jest rozróżnienie ról: host zarządza cyklem życia połączeń i decyduje, które serwery są dostępne. Klient obsługuje protokół na poziomie komunikacji. Serwer nie wie nic o tym, jaki model go odpytuje — widzi tylko żądania zgodne ze specyfikacją MCP. Ta separacja sprawia, że ten sam serwer działa z Claude, z ChatGPT i z każdym innym klientem, który zaimplementował protokół.
Claude Desktop jest dostępny dla macOS i Windows. Większość gotowych serwerów wymaga Node.js w wersji 18 lub nowszej, więc przed pierwszą konfiguracją warto sprawdzić zainstalowaną wersję środowiska uruchomieniowego.
Dlaczego M×N staje się M+N
Klasyczny problem integracji w ekosystemie AI można zapisać jako M×N: każdy z M modeli musi mieć osobną integrację z każdym z N systemów zewnętrznych. Przy pięciu modelach i dziesięciu źródłach danych to pięćdziesiąt oddzielnych mostów do zbudowania i utrzymania. Każda zmiana API w jednym systemie oznacza aktualizacje w wielu miejscach jednocześnie.
MCP zmienia ten rachunek na M+N. Jeden serwer MCP po stronie systemu zewnętrznego i jeden klient MCP po stronie aplikacji AI wystarczą, żeby dowolna para mogła się porozumieć. Nowy model AI nie wymaga pisania integracji z każdym istniejącym systemem — wystarczy, że implementuje klienta MCP. Nowe źródło danych nie musi wiedzieć nic o konkretnych modelach — wystarczy serwer MCP.
W praktyce jednak oznacza to, że ktoś musi napisać serwer MCP dla każdego systemu zewnętrznego. Dla popularnych usług — GitHub, PostgreSQL, Google Drive, pliki lokalne — gotowe serwery już istnieją. Dla firmowych API wewnętrznych trzeba zbudować własny. To nadal praca, ale jednorazowa i wielokrotnie użyteczna.
Trzy prymitywy: Tools, Resources i Prompts
MCP definiuje trzy główne typy obiektów, którymi operują serwery. Ich zrozumienie jest istotne, bo różnią się nie tylko funkcją, lecz takze tym, kto nimi steruje:
- Tools (narzędzia) to wykonywalne funkcje wywoływane przez model za pośrednictwem serwera MCP; model sam decyduje, kiedy i jak z nich skorzystać, a narzędzie może zmienić stan systemu;
- Resources (zasoby) to strukturalne dane dostarczane do kontekstu modelu: fragmenty dokumentów, kod źródłowy, dane z API; kontroluje je aplikacja, a nie model, i służą wyłącznie wzbogaceniu kontekstu przed generowaniem odpowiedzi;
- Prompts to szablony instrukcji przechowywane po stronie serwera i udostępniane klientowi, które pozwalają standaryzować komunikację z modelem dla powtarzalnych zadań.
Kluczowa różnica między Tools a Resources leży w kierunku kontroli: narzędzia to aktywna strona protokołu, zasoby to pasywna. Jeden serwer może udostępniać wszystkie trzy typy obiektów jednocześnie.
JSON-RPC jako format komunikacji
Komunikacja między klientem a serwerem MCP odbywa się przez JSON-RPC — lekki protokół zdalnego wywołania procedur oparty na formacie JSON. Każde żądanie zawiera identyfikator metody, parametry i unikalny numer pozwalający dopasować odpowiedź do żądania. To podejście jest niezależne od języka programowania i środowiska uruchomieniowego.
Wybór JSON-RPC oznacza, że serwer MCP można napisać w dowolnym języku, który obsługuje JSON i standardowe wejście-wyjście. Transport domyślny to stdio — serwer czyta żądania ze standardowego wejścia i zapisuje odpowiedzi na standardowe wyjście. Możliwy jest też transport SSE (Server-Sent Events) dla połączeń zdalnych. Oba tryby działają bez stałego połączenia z internetem, co ma znaczenie przy wdrożeniach lokalnych lub w środowiskach z ograniczonym dostępem sieciowym.
Dla dewelopera piszącego własny serwer JSON-RPC oznacza konkretne wymagania: serwer musi odpowiadać na metody zdefiniowane w specyfikacji MCP, obsługiwać błędy zgodnie ze standardem i nie blokować pętli zdarzeń przy długich operacjach. Oficjalna specyfikacja i dokumentacja są dostępne pod adresem modelcontextprotocol.io.
Jak działa sesja MCP krok po kroku
Teoria prymitywów i JSON-RPC nabiera sensu dopiero wtedy, gdy prześledzi się pełny cykl życia sesji. Od momentu uruchomienia hosta do zakończenia zadania protokół przechodzi przez kilka dobrze zdefiniowanych faz.
Pierwsza to inicjalizacja (initialization handshake). Klient wysyła do serwera żądanie `initialize` z informacją o swojej wersji protokołu i obsługiwanych możliwościach. Serwer odpowiada własną listą możliwości — np. które prymitywy obsługuje. Jeśli wersje są zgodne, klient potwierdza gotowość komunikatem `initialized`. Dopiero po tej wymianie sesja jest aktywna.
Druga faza to odkrywanie zasobów. Klient wysyła `tools/list`, `resources/list` lub `prompts/list`, żeby dowiedzieć się, co serwer udostępnia. Odpowiedź zawiera pełne schematy narzędzi w formacie JSON Schema — model językowy może je odczytać i wiedzieć, jakie parametry są wymagane przed wywołaniem. To ważne: model nie zgaduje interfejsu narzędzia, lecz otrzymuje jego formalny opis.
Trzecia faza to wywołanie narzędzia. Model decyduje, że potrzebuje danych z zewnętrznego systemu, i generuje żądanie `tools/call` z nazwą narzędzia i argumentami. Klient przekazuje je do serwera, serwer wykonuje operację i zwraca wynik. Cały cykl może zająć od kilkudziesięciu milisekund do kilku sekund, zależnie od operacji. Wynik wraca do modelu jako kolejna część kontekstu, a model kontynuuje generowanie odpowiedzi.
Sesja kończy się albo jawnym zamknięciem połączenia, albo przerwaniem procesu serwera. Nie ma stanu trwałego między sesjami, chyba że serwer sam go przechowuje po swojej stronie.
Transporty: stdio i SSE
Protokół MCP nie narzuca jednego medium transmisji. Specyfikacja definiuje dwa oficjalne transporty, które różnią się scenariuszem użycia.
| Transport | Scenariusz użycia | Wymagania sieciowe | Obsługa wielu klientów |
|---|---|---|---|
| stdio | Serwer lokalny, jeden host | Brak | Nie |
| SSE | Serwer zdalny, usługa sieciowa | HTTP, opcjonalnie TLS | Tak |
Stdio to domyślny wybór dla serwerów uruchamianych lokalnie. Host startuje serwer jako podproces i komunikuje się z nim przez standardowe wejście-wyjście. Zaletą jest prostota: żadnych portów sieciowych, żadnych certyfikatów TLS, żadnej konfiguracji zapory. Serwer żyje tak długo jak host. Większość gotowych serwerów MCP dostępnych publicznie działa właśnie w tym trybie.
SSE (Server-Sent Events) służy do połączeń zdalnych, gdzie serwer działa jako osobna usługa sieciowa. Klient łączy się przez HTTP i odbiera zdarzenia strumieniowo. Ten tryb przydaje się w środowiskach, gdzie serwer MCP ma obsługiwać wielu klientów jednocześnie albo działa na innej maszynie niż host. Wymaga jednak zadbania o bezpieczeństwo warstwy sieciowej.
Wybór między nimi to głównie kwestia topologii wdrożenia. Pojedynczy deweloper testujący integrację lokalnie sięgnie po stdio. Firma wdrażająca serwer MCP dla całego zespołu prawdopodobnie wybierze SSE z odpowiednią warstwą uwierzytelniania.
Bezpieczeństwo i kontrola dostępu w MCP
Otwartość protokołu rodzi pytania o bezpieczeństwo. Serwer MCP może mieć dostęp do baz danych, systemów plików, zewnętrznych API. Jeśli model językowy może wywołać dowolne narzędzie bez ograniczeń, ryzyko jest realne.
Specyfikacja MCP przenosi odpowiedzialność za kontrolę dostępu na trzy poziomy. Pierwszy to serwer — decyduje, które narzędzia w ogóle udostępnia i może wymagać tokenów autoryzacyjnych przekazywanych w parametrach żądania. Drugi to host — może ograniczać, z którymi serwerami klient w ogóle nawiązuje połączenie. Trzeci to użytkownik — wiele implementacji hostów, takich jak Claude Desktop czy Cursor, wymaga jawnej zgody użytkownika przed pierwszym wywołaniem narzędzia w danej sesji.
Osobny problem to prompt injection — sytuacja, gdy złośliwa treść pobrana przez serwer MCP (np. z zewnętrznej strony internetowej) zawiera instrukcje dla modelu, które zmieniają jego zachowanie. To ryzyko nie jest specyficzne dla MCP, ale protokół je wzmacnia, bo dane z zewnętrznych źródeł trafiają bezpośrednio do kontekstu. Dojrzałe implementacje serwerów oczyszczają dane wejściowe i nie przekazują surowych treści z niezaufanych źródeł.
Przy wdrożeniu produkcyjnym warto traktować serwer MCP jak każdy inny mikroserwis: zasada minimalnych uprawnień, logowanie wywołań, monitorowanie anomalii.
Porównanie MCP z innymi podejściami do integracji modeli
| Podejście | Kto definiuje interfejs | Wielokrotne użycie serwera | Standaryzacja |
|---|---|---|---|
| MCP | Specyfikacja Anthropic (otwarta) | Tak — jeden serwer, wielu klientów | Pełna |
| Function Calling (OpenAI) | Deweloper per aplikacja | Nie — definicje wbudowane w prompt | Brak |
| LangChain Tools | Deweloper, framework Python | Częściowe — w ekosystemie LangChain | Częściowa |
| Własne API proxy | Deweloper od zera | Zależy od implementacji | Brak |
Function calling w OpenAI i analogiczne mechanizmy w innych modelach rozwiązują podobny problem, ale inaczej. Definicje narzędzi są osadzone bezpośrednio w żądaniu do API — przy każdym wywołaniu, w każdej aplikacji osobno. MCP przenosi te definicje na serwer, który żyje niezależnie od konkretnej aplikacji. Jeśli masz dziesięć aplikacji korzystających z tego samego systemu CRM, piszesz jeden serwer MCP zamiast powielać definicje w każdym projekcie.
LangChain oferuje własną warstwę abstrakcji dla narzędzi, ale jest ściśle powiązana z ekosystemem Pythona i konkretną wersją frameworka. MCP jest agnostyczny językowo — serwer może działać w Pythonie, TypeScript, Go lub Rust, a klient tego nie odczuje.
Ekosystem serwerów MCP: co już istnieje?
Jedną z największych zalet otwartej specyfikacji jest to, że nie musisz pisać serwerów od zera dla popularnych narzędzi. Anthropic opublikował zestaw referencyjnych implementacji, a społeczność szybko go rozbudowała. Dziś dostępne są gotowe serwery MCP dla GitHub (odczyt repozytoriów, tworzenie pull requestów, zarządzanie issues), dla systemu plików lokalnych, dla baz danych PostgreSQL i SQLite, dla Slacka, Google Drive, Jiry czy Puppeteera do automatyzacji przeglądarki.
To oznacza konkretną oszczędność czasu. Zamiast budować integrację z GitHubem od podstaw, instalujesz gotowy serwer, konfigurujesz token dostępu i w ciągu kilku minut model językowy może przeglądać kod, komentować PR-y lub sprawdzać otwarte zgłoszenia. Czas wdrożenia spada z dni do godzin.
Rejestr serwerów społecznościowych rośnie szybko. Portale takie jak `mcp.so` agregują setki implementacji — od serwerów do obsługi Notion i Linear, przez integracje z narzędziami do analizy danych, po serwery łączące modele z lokalnymi skryptami. Jakość bywa zróżnicowana, więc przed użyciem w środowisku produkcyjnym warto sprawdzić datę ostatniej aktualizacji i liczbę aktywnych kontrybutorów.
Ważny sygnał rynkowy: Microsoft, Google i inne firmy technologiczne zaczęły dodawać wsparcie dla MCP do własnych narzędzi deweloperskich. To nie jest już wyłącznie ekosystem Anthropica.
Jak samodzielnie zbudować serwer MCP?
Punkt wejścia jest niższy, niż mogłoby się wydawać. Anthropic udostępnia oficjalne SDK dla TypeScript i Pythona, które obsługują całą warstwę protokołu — negocjację capabilities, routing żądań JSON-RPC, zarządzanie sesją. Twój kod skupia się wyłącznie na logice narzędzi.
W Pythonie minimalny serwer z jednym narzędziem to około 30 linii kodu. Importujesz `FastMCP`, dekorujesz funkcję adnotacją `@mcp.tool`, opisujesz parametry przez type hints i docstring, a SDK samo generuje schemat JSON Schema przekazywany klientowi podczas inicjalizacji. Uruchamiasz serwer jedną komendą i możesz go natychmiast podłączyć do Claude Desktop, edytując plik konfiguracyjny `claude_desktop_config.json`.
Kilka decyzji projektowych warto podjąć przed napisaniem pierwszej linii. Granularność narzędzi — jedno narzędzie `query_database` z parametrem `sql` daje modelowi dużą elastyczność, ale też duże uprawnienia. Dwa osobne narzędzia `get_user_by_id` i `list_recent_orders` są bezpieczniejsze i łatwiejsze do audytu. Obsługa błędów — serwer powinien zwracać czytelne komunikaty o błędach, bo model językowy interpretuje je i może próbować skorygować wywołanie. Niejasny stack trace nie pomaga. Idempotentność — narzędzia modyfikujące stan (zapis do bazy, wysyłka maila) powinny być wyraźnie oznaczone w opisie, żeby model wiedział, że ich wywołanie ma skutki uboczne.
Testowanie serwera przed podłączeniem do modelu jest proste dzięki narzędziu MCP Inspector — to przeglądarkowy interfejs, który pozwala ręcznie wywoływać narzędzia i przeglądać zasoby bez udziału żadnego LLM.
Praktyczne zastosowania MCP w codziennej pracy
Teoria nabiera sensu przy konkretnych przypadkach. Rozważmy kilka scenariuszy, które pokazują, gdzie MCP faktycznie zmienia sposób pracy.
Asystent deweloperski z dostępem do kodu
Programista pracujący w Cursorze lub VS Code z rozszerzeniem Copilot może podłączyć serwer MCP do lokalnego repozytorium i bazy danych projektu. Model nie tylko widzi aktualnie otwarty plik — może przeszukać całe repozytorium pod kątem użyć konkretnej funkcji, sprawdzić historię commitów dla danego pliku, a nawet wykonać zapytanie do bazy deweloperskiej, żeby zrozumieć strukturę danych. Odpowiedzi stają się znacznie trafniejsze, bo kontekst jest pełny, a nie urwany na granicy okna edytora.
Automatyzacja procesów biznesowych
Wyobraź sobie agenta obsługi klienta, który przez serwer MCP ma dostęp do systemu CRM, bazy zamówień i narzędzia do wysyłki emaili. Użytkownik pisze: „Sprawdź status zamówienia 4821 i wyślij klientowi potwierdzenie z szacowaną datą dostawy”. Agent wywołuje kolejno trzy narzędzia, zbiera dane i generuje spersonalizowaną wiadomość — bez jednej linii kodu orkiestrującego ten przepływ w warstwie aplikacji. Logika jest w narzędziach, decyzja o kolejności wywołań należy do modelu.
Lokalny asystent wiedzy
Retrieval-Augmented Generation realizowany przez MCP wygląda inaczej niż klasyczne pipeline’y RAG. Serwer MCP może wystawiać zasoby z wewnętrznej bazy wiedzy firmy — dokumenty, procedury, FAQ — jako Resources dostępne przez URI. Model sam decyduje, które dokumenty pobrać na podstawie kontekstu rozmowy, zamiast polegać na z góry ustalonym mechanizmie wyszukiwania wektorowego. To nie eliminuje wyszukiwania wektorowego, ale daje modelowi więcej kontroli nad tym, co trafia do jego kontekstu.
Ograniczenia i otwarte pytania
MCP rozwiązuje problem integracji elegancko, ale nie jest pozbawiony ograniczeń. Kilka z nich warto znać przed podjęciem decyzji o wdrożeniu.
Pierwsze ograniczenie to latencja. Każde wywołanie narzędzia to osobna wymiana komunikatów przez transport (stdio lub SSE), deserializacja JSON, wykonanie logiki serwera i odpowiedź. Przy prostych narzędziach to milisekundy, ale przy złożonych zadaniach wymagających dziesiątek wywołań czas odpowiedzi może rosnąć zauważalnie. Projektując serwer, warto myśleć o tym, które operacje można zgrupować w jedno wywołanie, zamiast wymuszać wiele małych żądań.
Drugie ograniczenie to brak natywnego wsparcia dla strumieniowania wyników. Narzędzie zwraca kompletną odpowiedź po zakończeniu wykonania. Jeśli operacja trwa 30 sekund (np. generowanie raportu), klient czeka bez żadnej informacji zwrotnej. Specyfikacja przewiduje mechanizm powiadomień, ale jego implementacja zależy od konkretnego serwera i hosta.
Trzecie to dojrzałość ekosystemu. MCP pojawił się publicznie pod koniec 2024 roku. Wiele implementacji jest wciąż w fazie eksperymentalnej, specyfikacja ewoluuje, a najlepsze praktyki dopiero się krystalizują. Dla projektów produkcyjnych wymagających stabilności warto śledzić oficjalny changelog specyfikacji i nie zakładać pełnej kompatybilności wstecznej.
Otwarte pytanie dotyczy też interoperability między hostami. Serwer napisany zgodnie ze specyfikacją powinien działać z każdym zgodnym klientem — i w większości przypadków tak jest. Jednak różne hosty mogą implementować capability negotiation nieco inaczej, co przy mniej popularnych funkcjach protokołu może prowadzić do nieoczekiwanych różnic w zachowaniu.
FAQ
Czym różni się MCP od zwykłego function calling?
Function calling to mechanizm wbudowany w API konkretnego modelu — definicje narzędzi są przekazywane przy każdym żądaniu i żyją w kodzie aplikacji. MCP przenosi te definicje na niezależny serwer, który może obsługiwać wielu klientów i wiele modeli jednocześnie. Przy jednym projekcie różnica jest niewielka. Przy dziesięciu aplikacjach korzystających z tego samego systemu zewnętrznego MCP eliminuje powielanie kodu.
Czy MCP działa z modelami innymi niż Claude?
Tak. Protokół jest otwarty i agnostyczny modelowo. Obsługę MCP dodały już m.in. narzędzia takie jak Cursor, Zed czy Sourcegraph Cody. Każda aplikacja, która zaimplementuje klienta MCP zgodnego ze specyfikacją, może korzystać z dowolnego serwera MCP niezależnie od tego, jaki model językowy działa pod spodem.
Jak bezpieczny jest MCP w środowisku produkcyjnym?
Bezpieczeństwo zależy od implementacji, a nie od samego protokołu. MCP nie narzuca mechanizmu uwierzytelniania — to zadanie serwera i hosta. Przy wdrożeniu produkcyjnym należy zadbać o tokeny dostępu, ograniczenie uprawnień serwera do minimum i sanityzację danych pobieranych z zewnętrznych źródeł. Ryzyko prompt injection rośnie wraz z liczbą niezaufanych źródeł danych podłączonych do serwera.
Czy muszę znać TypeScript lub Python, żeby napisać serwer MCP?
Oficjalne SDK istnieją dla TypeScript i Pythona, co znacznie obniża próg wejścia. Serwer można jednak napisać w dowolnym języku obsługującym JSON i stdio — specyfikacja protokołu jest publiczna i wystarczająco szczegółowa, żeby zaimplementować go od podstaw. Nieoficjalne SDK dla Go, Rust i innych języków są już dostępne w repozytoriach społecznościowych.
Gdzie znaleźć gotowe serwery MCP?
Anthropic prowadzi oficjalne repozytorium na GitHubie z referencyjnymi implementacjami dla najpopularniejszych usług. Agregatory społecznościowe, takie jak `mcp.so`, zbierają setki dodatkowych serwerów. Przed użyciem w środowisku produkcyjnym warto sprawdzić datę ostatniego commitu i aktywność maintainerów — ekosystem jest młody i jakość implementacji bywa zróżnicowana.
