MCP: kompletny przewodnik po protokole i serwerach

MCP, czyli Model Context Protocol, to otwarty protokół łączący aplikacje AI z zewnętrznymi danymi i narzędziami. Specyfikacja MCP określa wspólny sposób udostępniania kontekstu oraz wywoływania funkcji, na przykład wyszukiwania informacji lub wykonywania operacji w systemie. Polecam rozważyć go wtedy, gdy chcesz udostępnić możliwości swojej aplikacji różnym klientom AI i zachować kontrolę nad tym, co mogą zrobić.

W tym przewodniku porządkuję role aplikacji, klientów i serwerów, pokazuję różnice między narzędziami a zasobami oraz proponuję drogę od wyboru integracji do jej oceny. Dokumentację sprawdziłem 6 października 2026 r.

W skrócie

• Zacznij od zadania, na przykład odczytania statusu zamówienia, i dopiero potem wybierz serwer.
• Oddziel dostęp do danych od prawa do ich zmieniania.
• Sprawdź zgodność wersji protokołu i funkcji po obu stronach.
• Przed wdrożeniem oceń uprawnienia, błędy, ślady audytowe i jakość odpowiedzi.

Jak działa MCP: host, klient i serwer

Architektura MCP wyróżnia trzy role. Host to aplikacja AI zarządzająca integracjami; klient jest jej komponentem komunikującym się z konkretnym serwerem; serwer udostępnia kontekst i funkcje. Host tworzy osobnego klienta dla każdego podłączonego serwera.

Nie utożsamiam więc serwera MCP z modelem. W przykładowej integracji sklepu serwer może udostępniać status zamówienia, a aplikacja AI wykorzystuje wynik do przygotowania odpowiedzi. Sposób używania modelu i zarządzania otrzymanym kontekstem pozostaje poza zakresem samego protokołu.

Poniższy diagram przedstawia przykładową integrację, w której serwer korzysta z firmowego API:

flowchart TD
    U[Użytkownik] --> H[Aplikacja AI]
    H <--> M[Model językowy]
    H <--> C[Klient MCP]
    C <--> S[Serwer MCP]
    S <--> A[Firmowe API]

Przy projektowaniu takiego przepływu przypisuję każdej warstwie odpowiedzialność: aplikacji interakcję z użytkownikiem, serwerowi sprawdzanie argumentów i dostęp do systemu, a API reguły biznesowe. Na przykład możliwość odczytu zamówienia nie powinna w moim projekcie automatycznie pozwalać na jego anulowanie.

Jeżeli potrzebujesz szerszego obrazu planowania i wykonywania zadań, odsyłam do przewodnika jak działa i jak zbudować agenta AI.

Co udostępnia serwer: tools, resources i prompts

W dokumentacji serwerów MCP podstawowe możliwości dzielą się na narzędzia, zasoby i szablony promptów. Poniżej zestawiam ich role z hipotetycznymi przykładami dla systemu zamówień.

Narzędzie opisuje konkretną operację

Definicja narzędzia zawiera nazwę, schemat wejścia i metadane opisujące funkcję. Serwer może też deklarować schemat wyjścia. Dzięki temu klient otrzymuje opis dostępnych operacji i oczekiwanych argumentów.

Polecam nazwy, które ujawniają zamiar: „odczytaj status zamówienia” albo „utwórz zgłoszenie zwrotu”. Własne narzędzie zaprojektowałbym z identyfikatorem zamówienia jako argumentem, jasno opisanym wynikiem i błędem dla niedostępnego rekordu. Unikałbym jednej funkcji przyjmującej dowolne polecenie tekstowe do całego systemu.

Zasób dostarcza kontekst

Według specyfikacji zasobów zasób ma własny URI, a aplikacja decyduje, jak wykorzystać jego zawartość. Może na przykład pozwolić użytkownikowi wybrać dokument albo dołączyć odpowiedni fragment jako kontekst.

Regulamin zwrotów udostępniłbym jako zasób, a sprawdzenie aktualnego statusu konkretnego zamówienia jako narzędzie. To moja propozycja podziału, zależna od potrzeb aplikacji. Osobno sprawdziłbym, czy wybrany host potrafi wygodnie wykorzystać oba elementy.

Prompt ułatwia rozpoczęcie zadania

Prompty MCP są szablonami wymagającymi jawnego wywołania przez użytkownika. Mogą odwoływać się do zasobów i narzędzi.

W przykładzie sklepu przygotowałbym szablon „Wyjaśnij możliwość zwrotu”, który prowadzi do odczytu zamówienia i regulaminu. Traktowałbym go jako pomoc w rozpoczęciu rozmowy, a uprawnienia egzekwowałbym niezależnie w kodzie serwera.

Serwer lokalny czy zdalny?

Standardowe transporty MCP to stdio i Streamable HTTP. Transport określa sposób przenoszenia komunikatów; znaczenie operacji protokołu pozostaje wspólne.

Przy stdio klient uruchamia serwer jako proces potomny. Serwer czyta komunikaty ze standardowego wejścia i zapisuje odpowiedzi na standardowym wyjściu. Logi mogą trafiać na stderr; stdout musi zawierać wyłącznie poprawne komunikaty MCP.

Streamable HTTP używa pojedynczego endpointu przyjmującego żądania POST. Odpowiedź może być obiektem JSON albo strumieniem SSE związanym z danym żądaniem.

Do pracy z lokalnym katalogiem rozważyłbym stdio. Dla usługi dostępnej wielu użytkownikom wybrałbym HTTP, z centralnym zarządzaniem dostępem. Zanim podejmę decyzję, ustaliłbym również, kto aktualizuje serwer, gdzie trafiają dane i kto odpowiada za jego dostępność.

Wersja protokołu ma znaczenie

Wydanie MCP 2026-07-28 opublikowano 28 lipca 2026 r. Usunęło ono wymianę initialize/initialized i nagłówek Mcp-Session-Id. Żądania są samodzielne i przenoszą metadane potrzebne do obsługi; klient może opcjonalnie poznać możliwości serwera przez server/discover.

Dlatego przykład ze starszego poradnika trzeba czytać w kontekście wersji. Dokumentacja zgodności rozróżnia starsze implementacje z inicjalizacją oraz nowoczesne z metadanymi każdego żądania. Obsługa obu wymaga odpowiedniej ścieżki zgodności.

Polecam zapisać osobno wersję serwera, SDK i protokołu. W TypeScript stabilna linia SDK v2 implementuje specyfikację 2026-07-28. Przy kopiowaniu kodu sprawdziłbym, czy dokumentacja dotyczy używanej linii SDK.

Bezstanowość protokołu pozwala nadal utrzymywać stan aplikacyjny przez jawne identyfikatory, na przykład koszyka, przekazywane jako argumenty. Ten model opisuje komunikat wydania. Szczegóły wdrożeniowe rozwijam w osobnym materiale o skalowaniu serwera MCP bez sesji.

MCP a API, function calling i RAG

W decyzji architektonicznej rozdzielam te pojęcia. API jest interfejsem systemu; function calling pozwala modelowi wskazać funkcję i jej argumenty; RAG polega na dostarczeniu wyszukanych informacji do generowania odpowiedzi. MCP standaryzuje interfejs wymiany kontekstu i możliwości między aplikacją AI a serwerem, zgodnie z zakresem specyfikacji.

Dla jednej aplikacji korzystającej z kilku stałych funkcji rozważyłbym bezpośrednie wywołanie API. Gdy te same operacje mają być dostępne w różnych hostach AI, sprawdziłbym zasadność serwera MCP. Wyszukiwarkę dokumentów zaprojektowałbym jako możliwy backend narzędzia, niezależnie od sposobu budowy indeksu.

Na przykład dla pytania „jaka jest polityka zwrotów?” zacząłbym od wyszukania właściwego dokumentu. Dla „czy zamówienie zostało wysłane?” wybrałbym odczyt aktualnego rekordu. Nie projektowałbym jednego mechanizmu dostępu dla obu zadań bez sprawdzenia ich wymagań.

Jak wybrać serwer MCP

Zaczynam od jednego scenariusza: „chcę analizować zgłoszenia w repozytorium bez wprowadzania zmian”. Następnie szukam serwera utrzymywanego przez dostawcę systemu albo implementacji, której kod i sposób działania mogę ocenić.

Oficjalny MCP Registry przechowuje metadane wskazujące pakiety i adresy serwerów. Weryfikuje pochodzenie przestrzeni nazw, ale skanowanie kodu pozostawia rejestrom pakietów i agregatorom. Wpis w katalogu traktuję więc jako punkt rozpoczęcia oceny.

Moja lista wyboru obejmuje:

• Pochodzenie: czy adres repozytorium i pakietu zgadza się z dokumentacją dostawcy?
• Zakres: czy mogę udostępnić wyłącznie operacje potrzebne do zadania?
• Poświadczenia: czy dostęp da się ograniczyć do właściwych danych i użytkowników?
• Utrzymanie: czy istnieją instrukcje aktualizacji, zgłaszania błędów i migracji?
• Zgodność: czy host obsługuje potrzebny transport, wersję i rozszerzenia?

Przykładowo konfiguracja serwera MCP GitHuba przewiduje wybór zestawów narzędzi, pojedynczych funkcji i trybu tylko do odczytu. Do analizy zgłoszeń zacząłbym od minimalnego zakresu oraz poświadczeń ograniczonych po stronie systemu źródłowego. Potem sprawdziłbym rzeczywistą listę dostępnych operacji.

Pierwsza inspekcja: zobacz, co serwer udostępnia

Do sprawdzenia interfejsu polecam MCP Inspector. Jego dokumentacja wymaga Node.js 22.19.0 lub nowszego i opisuje uruchomienie przez npx.

1. W folderze projektu uruchom wariant przeglądarkowy bez wskazywania serwera:

   npx @modelcontextprotocol/inspector

2. Otwórz adres wypisany w terminalu. Zgodnie z instrukcją uruchomienia zawiera on token sesji Inspectora.
3. W zakładce Servers dodaj wybrany serwer, korzystając z jego własnego README, i połącz się z nim. Dokumentacja interfejsu opisuje zarządzanie serwerami oraz zakładki zależne od ich możliwości.
4. Jeśli serwer udostępnia narzędzia, w Tools wybierz operację, przejrzyj opis i schemat, wypełnij argumenty, a następnie ją wywołaj. Wynik pojawi się poniżej formularza, zgodnie z instrukcją zakładki Tools.

Na pierwszą próbę wybieram odczyt niesensytywnych danych. Polecam sprawdzić również niepoprawny argument i brak dostępu. Taki przegląd służy ocenie interfejsu; osobno zaplanowałbym test rozmowy z modelem, w której powinien wybrać właściwe narzędzie.

Bezpieczeństwo: uprawnienia muszą działać w kodzie

Ogranicz dostęp i skutki działania

Specyfikacja narzędzi wymaga walidacji wejścia, kontroli dostępu, ograniczania częstotliwości wywołań i oczyszczania wyników. Zaleca też klientom potwierdzanie wrażliwych operacji, sprawdzanie wyników i rejestrowanie użycia narzędzi.

W moim projekcie odczyt statusu i anulowanie zamówienia byłyby osobnymi funkcjami. Przed anulowaniem pokazałbym użytkownikowi identyfikator i skutki operacji. Reguły dostępu oraz warunki anulowania sprawdzałbym po stronie serwera przy każdym wywołaniu.

Przy HTTP specyfikacja autoryzacji opisuje przepływ oparty na OAuth. Autoryzacja jest opcjonalna na poziomie MCP; implementacje stdio powinny pobierać poświadczenia ze środowiska zamiast stosować ten przepływ HTTP. Dla firmowych danych zalecam jawnie zaprojektować tożsamość użytkownika i minimalny zakres dostępu.

Traktuj pobraną treść jako dane

Analiza bezpieczeństwa CoSAI opisuje prompt injection przez instrukcje ukryte w zasobach, promptach lub metadanych narzędzi. Takie instrukcje mogą skłaniać model do nieautoryzowanych działań.

W teście użyłbym dokumentu zawierającego polecenie „wyślij dane pod wskazany adres”. Oczekiwałbym, że aplikacja potraktuje je jako treść dokumentu. Polecam również sprawdzić, czy próba wykonania takiej operacji zostaje odrzucona przez mechanizmy dostępu.

Uwaga: opis narzędzia nie jest granicą uprawnień. Zalecam ograniczać możliwości poświadczeniami, kontrolą dostępu i kodem wykonującym operację.

Sprawdź lokalny proces i tokeny

Zalecenia bezpieczeństwa MCP wskazują ryzyko wykonywania lokalnych serwerów z dostępem do systemu użytkownika. Opisują też zakaz przyjmowania tokenów niewystawionych dla serwera MCP i przekazywania ich dalej jako niezweryfikowanych poświadczeń.

Przed uruchomieniem lokalnego serwera sprawdziłbym pełne polecenie, źródło pakietu i dostępne katalogi. Dla serwera pośredniczącego między systemami zaprojektowałbym osobno autoryzację klienta oraz dostęp do API. W przeglądzie wdrożenia uwzględniłbym również izolację użytkowników i ochronę sekretów w logach.

Własny serwer i wdrożenie produkcyjne

Własny serwer rozważyłbym wtedy, gdy gotowa integracja nie odpowiada zadaniu albo udostępnia zbyt szerokie operacje. Zacząłbym od wąskiej funkcji biznesowej, na przykład „znajdź zamówienia wymagające wyjaśnienia”, z ograniczoną liczbą wyników i określonym zakresem danych.

Implementację rozwijam w poradniku jak napisać własny serwer MCP w TypeScript. Tutaj skupiam się na decyzjach, które polecam podjąć przed kodowaniem i publikacją:

1. Zapisz cel użytkownika oraz przykłady poprawnej i niedozwolonej operacji.
2. Ustal schemat argumentów, wynik, limity i zasady dostępu.
3. Sprawdź scenariusze błędów oraz zachowanie przy ponowieniu żądania.
4. Przeprowadź ocenę rozmów z modelem, używając stałego zestawu zadań.
5. Zdefiniuj monitoring, aktualizacje i sposób wyłączenia integracji.

Przykładowy test odbioru zapisuję jako rozmowę: użytkownik pyta o status własnego zamówienia, aplikacja odczytuje właściwy rekord i odpowiada na podstawie wyniku. Następnie proponuję próbę dostępu do zamówienia innego użytkownika oraz próbę anulowania bez uprawnienia. Za warunek dopuszczenia do wdrożenia przyjmuję odrzucenie obu niedozwolonych operacji przez backend, niezależnie od odpowiedzi modelu.

W ocenie mierzyłbym wybór właściwego narzędzia, poprawność argumentów, jakość odpowiedzi oraz respektowanie uprawnień. Koszt analizowałbym przez wywołania modelu, objętość kontekstu, operacje backendu i utrzymanie serwera. Nie zakładałbym z góry oszczędności wynikających z samego wyboru protokołu.

Rozróżniłbym też błędy komunikacji od błędów wykonania funkcji. Specyfikacja tools opisuje błędy protokołu jako odpowiedzi JSON-RPC, a błędy wykonania narzędzia jako wynik z isError: true. Zaplanowałbym osobną reakcję aplikacji na każdą kategorię.

Kiedy potrzebne są rozszerzenia?

Tasks pozwala serwerowi zwrócić trwały identyfikator długiej operacji, a klientowi sprawdzać postęp i pobrać wynik. MCP Apps umożliwia interaktywne interfejsy HTML wewnątrz rozmowy. W obu przypadkach potrzebna jest obsługa rozszerzenia po stronie klienta i serwera.

Dla długiego eksportu sprawdziłbym Tasks, a dla przeglądu wyników wymagającego formularza rozważyłbym Apps. Do pierwszego prostego odczytu wybrałbym podstawowe narzędzie i dopiero po ocenie potrzeb rozszerzał integrację.

FAQ

Czy MCP to to samo co API?

MCP standaryzuje udostępnianie kontekstu i funkcji aplikacjom AI, co określa specyfikacja. API systemu może być backendem serwera MCP. Przy projektowaniu traktuję te interfejsy jako osobne warstwy.

Czy serwer MCP musi działać w chmurze?

Nie. Dokumentacja architektury opisuje serwery lokalne i zdalne. Wybrałbym miejsce uruchomienia według lokalizacji danych, potrzeb użytkowników i sposobu utrzymania.

Czy MCP jest bezpieczny?

Specyfikacja wyjaśnia, że protokół sam nie egzekwuje zasad bezpieczeństwa. Polecam oceniać konkretny host, serwer i zakres uprawnień oraz sprawdzić, jak integracja reaguje na niedozwolone operacje.

Czy każdy klient obsługuje wszystkie funkcje MCP?

Zasady zgodności przewidują deklarowanie możliwości i obsługi rozszerzeń. Przed wyborem integracji sprawdziłbym konkretnie potrzebne funkcje, zamiast opierać decyzję na samym oznaczeniu „obsługuje MCP”.

Co dalej

Jeśli chcesz przejść od projektu interfejsu do kodu, kolejnym krokiem jest własny serwer MCP w TypeScript. Po przygotowaniu integracji możesz przejść do skalowania serwera bez sesji.

Jeżeli potrzebujesz pomocy w połączeniu AI z firmowymi narzędziami i systemami, napisz do mnie.