O autorze

Jakub Stankowski – programista .NET i Angular od 2018 roku. Pracował nad projektami frontendowymi, backendowymi i fullstackowymi, przestrzegając zasad czystego kodu, DRY i stosując CQRS. Ma również doświadczenie jako trener programowania.

Od 2023 roku intensywnie pracuje z Claude AI oraz metodą Spec-Driven Development (SDD) – produkcyjnym workflow do pracy z AI opartym na zasadzie: najpierw specyfikacja, potem implementacja. Na ProgramujZAI.pl dzieli się praktyczną wiedzą o tym, jak programować z AI bez chaosu w kodzie.

Poznaj Jakuba →

Model Context Protocol (MCP) to otwarty standard od Anthropic, który pozwala Claude Code i innym asystentom AI łączyć się z zewnętrznymi narzędziami — bazami danych, GitHubem, Jirą, Slackiem — przez jeden, wspólny protokół zamiast osobnej integracji dla każdego narzędzia. Zamiast wklejać dane z innych systemów do czatu, podłączasz serwer MCP raz i Claude sam odpytuje ten system, kiedy tego potrzebuje.

Czym jest Model Context Protocol i jaki problem rozwiązuje

Przed MCP każdy klient AI musiał mieć osobny kod integracyjny dla każdego narzędzia, z którym miał współpracować. Chciałeś, żeby Claude czytał Twoje zgłoszenia w Jirze? Pisałeś custom integrację. Chciałeś, żeby inny asystent odpytywał Postgresa? Kolejna, osobna integracja, od zera.

MCP odwraca ten model. Deweloper narzędzia pisze integrację raz, jako serwer MCP, a każdy klient zgodny z protokołem — Claude Code, Claude Desktop, Cowork czy inne aplikacje wspierające standard — może się z nim połączyć bez dodatkowego kodu po swojej stronie. To podejście „USB dla AI”: jeden port, wiele urządzeń, żadnych dedykowanych przejściówek.

Serwer MCP eksponuje trzy rodzaje możliwości: narzędzia, zasoby i prompty

Protokół definiuje konkretny zestaw tego, co serwer może zaoferować modelowi, nie jest to dowolna, niezdefiniowana wymiana danych.

• Tools (narzędzia) — akcje, które model może wywołać, np. „utwórz issue w GitHubie”, „wyślij zapytanie do bazy danych”, „dodaj wiersz do arkusza Google Sheets”.
• Resources (zasoby) — dane tylko do odczytu, które model może pobrać: zawartość pliku, wiersze z bazy, odpowiedź z API.
• Prompts — gotowe szablony poleceń, które serwer udostępnia jako komendy — w Claude Code widzisz je jako polecenia w stylu /mcp__nazwa-serwera__nazwa-promptu.

Ta trójdzielna struktura sprawia, że Claude Code wie dokładnie, czego może się spodziewać po każdym serwerze, zamiast zgadywać na podstawie luźnego opisu.

Serwer MCP komunikuje się z Claude Code przez jeden z trzech transportów, w zależności od tego, gdzie działa

Wybór transportu zależy od tego, czy narzędzie działa lokalnie na Twojej maszynie, czy jest usługą zdalną.

• stdio — lokalny proces uruchamiany przez Claude Code, komunikacja przez standardowe wejście/wyjście. Najlepszy wybór dla narzędzi wymagających bezpośredniego dostępu do systemu plików czy lokalnych baz danych.
• HTTP — zdalny serwer dostępny pod adresem URL; typowy wybór dla usług SaaS z oficjalnym serwerem MCP (np. GitHub).
• SSE (Server-Sent Events) — wariant strumieniowy przez HTTP, używany tam, gdzie serwer musi na bieżąco przesyłać zdarzenia.

Dodanie serwera to zwykle jedna komenda w terminalu, np. claude mcp add --transport http github https://api.githubcopilot.com/mcp/, po której autoryzujesz połączenie komendą /mcp. Część serwerów wymaga wcześniejszej rejestracji aplikacji OAuth po stronie dostawcy — Claude Code wspiera zarówno automatyczne odkrywanie danych logowania (Dynamic Client Registration), jak i ręczne skonfigurowanie danych uwierzytelniających, gdy serwer tego automatycznego trybu nie wspiera.

Kilka serwerów MCP daje realną wartość od razu po podłączeniu, bez dalszej konfiguracji

Nie każdy serwer wart jest miejsca w konfiguracji — poniższe są tam, gdzie zaczynam, bo pokrywają najczęstsze zadania programisty.

• GitHub — przegląd PR-ów, tworzenie issue, operacje na repozytorium bez wychodzenia z terminala.
• PostgreSQL / bazy danych — odpytywanie schematu i danych bezpośrednio z sesji, bez ręcznego eksportu.
• Playwright — automatyzacja przeglądarki, testy end-to-end, sprawdzanie działania frontendu.
• Sentry — analiza błędów produkcyjnych powiązanych z konkretną zmianą w kodzie.
• Notion / Google Workspace — czytanie zgłoszeń, dokumentacji i maili, jeśli tam trzyma się kontekst projektu.

Realny przykład użycia kilku serwerów naraz: jedno polecenie może poprosić Claude Code o przejrzenie pull requesta, sprawdzenie powiązanych błędów w Sentry i zaktualizowanie zgłoszenia w Jirze — trzy różne systemy, jedna sesja, bez przełączania kart w przeglądarce.

Podłączenie serwera MCP oznacza uruchamianie cudzego kodu, więc bezpieczeństwo wymaga tej samej ostrożności co przy każdej zależności

Serwer MCP to działający proces z dostępem do systemu plików i sieci, nie bezpieczny sandbox z definicji. Zanim go podłączysz, warto trzymać się kilku zasad.

• Sprawdź źródło — oficjalny serwer od twórcy narzędzia (GitHub, Sentry) jest bezpieczniejszym wyborem niż nieznana implementacja społecznościowa.
• Audytuj kod przed uruchomieniem serwera społecznościowego — masz dostęp do źródła, więc sprawdź, co faktycznie robi.
• Minimalne uprawnienia — token do GitHuba tylko do odczytu tam, gdzie zapis nie jest potrzebny; osobny użytkownik bazy danych z ograniczonymi prawami dla serwera Postgresa.
• Traktuj konfigurację MCP jak dotfiles — trzymaj ją w repozytorium, komentuj po co dany serwer tam jest, przeglądaj przy każdej zmianie.

Claude Code pokazuje każde wywołanie MCP w trakcie sesji — warto obserwować te wywołania szczególnie uważnie przy pierwszych sesjach z nowym serwerem, zanim nabierzesz do niego zaufania.

MCP domyka pętlę Spec-Driven Development, podając Claude realny kontekst zamiast założeń

W podejściu Spec-Driven Development, o którym pisałem w artykule o zaletach Spec-Driven Development, specyfikacja jest tak dobra, jak dobry jest kontekst, na którym powstaje. MCP właśnie ten kontekst dostarcza — zamiast opisywać Claude’owi ręcznie, jak wygląda struktura bazy danych czy jakie dokładnie zgłoszenie trzeba zaimplementować, podłączony serwer MCP pozwala mu to sprawdzić samodzielnie, z pierwszej ręki.

W praktyce oznacza to mniej rundy „doprecyzuj mi, o co chodzi” i specyfikacje, które od razu odzwierciedlają realny stan systemu, a nie to, co programista zapamiętał z ostatniego stand-upu. Jeśli łączysz to z komendami opisanymi w artykule o nowych funkcjach Claude Code — /plan przed implementacją, /loop do pilnowania długich zadań — MCP jest brakującym elementem, który zasila cały workflow aktualnymi danymi.

FAQ — najczęstsze pytania o Model Context Protocol

Czy MCP działa tylko z Claude Code?
Nie — to otwarty standard, więc każdy klient zgodny z protokołem (Claude Desktop, Cowork, a także niektóre narzędzia trzecie) może połączyć się z tym samym serwerem MCP bez dodatkowej integracji.

Czym różni się MCP od zwykłego API?
API definiuje endpointy dla konkretnej usługi, a MCP definiuje wspólny format, w jakim dowolna usługa opisuje swoje narzędzia i dane modelowi AI — dzięki temu model „rozumie”, jak z niej korzystać, bez osobnego kodu integracyjnego pisanego pod ten konkretny model.

Czy mogę napisać własny serwer MCP dla wewnętrznego narzędzia firmy?
Tak — protokół jest udokumentowany, a implementacje istnieją m.in. w Node.js, Pythonie, Go i Ruście, więc możesz wystawić własne API deploymentu, dashboard metryk czy wewnętrzny indeks wyszukiwania jako serwer MCP.

Czy podłączenie wielu serwerów MCP spowalnia sesję Claude Code?
Może zwiększyć zużycie kontekstu, bo każdy serwer dokłada opisy swoich narzędzi do rozmowy — warto podłączać tylko te serwery, których realnie używasz w danym projekcie, i odłączać resztę.

Czy serwery MCP mogą same inicjować kontakt z Claude Code, a nie tylko czekać na zapytanie?
Tak, przez mechanizm kanałów serwer MCP może wypychać wiadomości do sesji — dzięki temu Claude może reagować np. na wiadomość na Telegramie czy webhook, zamiast tylko odpowiadać na pytania.

Podsumowanie: MCP to most między Claude Code a resztą Twojego stacku narzędzi

Model Context Protocol nie jest kolejną integracją do zapamiętania — to warstwa, która sprawia, że wszystkie kolejne integracje przestają być osobnym projektem. Podłączasz serwer raz, a Claude Code zyskuje trwały dostęp do GitHuba, bazy danych czy trackera zgłoszeń, zamiast pracować wyłącznie na tym, co mu wkleisz. Dla programisty pracującego w podejściu Spec-Driven Development to praktycznie warunek konieczny, żeby specyfikacje odzwierciedlały rzeczywisty stan projektu, a nie tylko to, co pamiętasz z głowy.

Jeśli chcesz zobaczyć konfigurację MCP krok po kroku na żywo, zapraszam na mój kanał YouTube, a po darmowy bonus do newslettera o pracy z AI — na standev.it/ai-workflow-bonus.