MCP (Model Context Protocol): co to jest i co daje zespołom

Model Context Protocol to otwarty standard, przez który agent AI rozmawia z bazą danych, przeglądarką czy systemem zgłoszeń. Co daje zespołom i od czego zacząć.

Autor: · Ostatnia aktualizacja:

Opublikowano · jak powstają nasze teksty

Czym jest MCP

Model Context Protocol to otwarty protokół, który łączy aplikację z modelem językowym (Claude Code, Cursor, VS Code) z zewnętrznym źródłem danych albo narzędziem. Anthropic ogłosił go 25 listopada 2024. Pod spodem jest JSON-RPC 2.0 i trzy role: host (aplikacja z modelem), klient (łącze) i serwer (to, co wystawia dane). Wzorem był Language Server Protocol: tak jak LSP sprawił, że jeden serwer językowy działa w każdym edytorze, tak jeden serwer MCP działa w każdym agencie, który protokół obsługuje.

Serwer udostępnia trzy rzeczy: narzędzia (funkcje, które model może wywołać, na przykład zapytanie SQL), zasoby (dane do odczytu, na przykład zawartość pliku) i prompty (gotowe szablony, które użytkownik uruchamia sam). Od wersji z czerwca 2025 serwer może też dopytać użytkownika o brakujące dane przez tzw. elicitation. Pełną definicję znajdziesz w specyfikacji.

Dlaczego jeden standard ma znaczenie

Przed MCP każda integracja była pisana pod jedno narzędzie. Wtyczka do Copilota nie działała w Cursorze, a skrypt dla Claude’a trzeba było przepisywać pod Gemini. Dziś ten sam serwer podłączysz do Claude Code, Claude Desktop, Cursora, VS Code z Copilotem (pełne wsparcie od wersji 1.102 z lipca 2025), Codex CLI, Gemini CLI, Windsurfa i JetBrains AI Assistant.

Standard przestał też należeć do jednej firmy. 9 grudnia 2025 Anthropic przekazał MCP do Agentic AI Foundation przy Linux Foundation. Wśród członków platynowych są AWS, Google, Microsoft, OpenAI, Block, Bloomberg i Cloudflare. Fundacja podawała wtedy ponad 10 000 opublikowanych serwerów; w oficjalnym rejestrze naliczyliśmy 6 października 2026 około 10,9 tys. wpisów, a w lipcu 2026 zespół protokołu pisał o blisko pół miliarda pobrań SDK miesięcznie. Dla firmy, która wybiera narzędzia na lata, to ważniejsze niż kolejna funkcja: integracja, którą dziś zbudujesz, nie umrze razem z jednym produktem.

Co to zmienia w codziennej pracy programisty

Bez MCP agent widzi kod w repozytorium i tyle. Z MCP widzi to, co widzi programista: schemat bazy, logi, stronę w przeglądarce, zgłoszenia, projekt w Figmie.

Trzy przykłady z naszych wdrożeń:

  • Baza danych. Zamiast przepisywać agentowi strukturę tabel, podpinamy serwer MCP do bazy deweloperskiej. Agent sam sprawdza schemat, szuka duplikatów, generuje typy TypeScript i proponuje migrację. Jak to zrobić krok po kroku z Supabase, opisaliśmy w szkoleniu MCP Supabase. Dla klientów z IBM DB2 napisaliśmy własny serwer, DB2 MCP Server (kod na GitHubie), bo gotowego nie było.
  • Przeglądarka. Chrome DevTools MCP od Google (wrzesień 2025) daje agentowi dostęp do konsoli, sieci, DOM-u i profilera wydajności. Agent nie zgaduje, czemu strona jest wolna, tylko robi trace i czyta wynik. Tak przyspieszyliśmy mechanizm JavaScriptu pięciokrotnie w trzy minuty, o czym piszemy na stronie o pętlach agentowych.
  • Łańcuch narzędzi. Agent czyta projekt z Figmy, pisze komponent React, testuje go w przeglądarce i zapisuje wynik w bazie. Programista formułuje cel i odbiera efekt. Opis z komendami jest w szkoleniu o serwerach MCP.

W Claude Code dodanie serwera to jedno polecenie, na przykład claude mcp add --transport http supabase https://mcp.supabase.com/mcp. Konfiguracja ma trzy zakresy: prywatny dla jednego projektu, współdzielony przez repozytorium (plik .mcp.json, trafia do gita i działa u całego zespołu) oraz globalny dla użytkownika. Szczegóły są w dokumentacji Claude Code. Plik .mcp.json w repozytorium traktujemy jak część kontraktu zespołu, obok CLAUDE.md: nowa osoba klonuje repo i ma te same narzędzia co reszta.

Czego nie wolno robić

Serwer MCP działa z uprawnieniami, które mu dasz. Narzędzie w specyfikacji jest opisane wprost jako wykonanie dowolnego kodu, a opisy narzędzi są uznawane za dane niezaufane. Rok 2025 pokazał, co to znaczy w praktyce:

  • W kwietniu Invariant Labs opisało tool poisoning: złośliwe instrukcje ukryte w opisie narzędzia, których użytkownik nie widzi, a model wykonuje. W demonstracji agent w Cursorze wysyłał klucze SSH na zewnątrz.
  • W lipcu General Analysis pokazało atak na Supabase MCP: klient wpisał w zgłoszeniu do supportu polecenie dla modelu, a asystent programisty, czytając zgłoszenie z uprawnieniami service_role, wyniósł tokeny z bazy do tego samego zgłoszenia. Supabase odpowiedziało wpisem o obronie w głąb i zdaniem, które powtarzamy na każdym szkoleniu: „Never connect AI agents directly to production data”.
  • W tym samym miesiącu JFrog zgłosił CVE-2025-6514 w popularnym pakiecie mcp-remote (zdalne wykonanie kodu, CVSS 9.6). OWASP zebrał te klasy błędów w MCP Top 10.

Nasze zasady, zapisane w CLAUDE.md każdego projektu, w którym agent dostaje MCP:

  1. Agent dostaje bazę deweloperską albo gałąź, nigdy produkcję. Jeśli musi czytać produkcyjne dane, dostaje użytkownika tylko do odczytu (w Supabase: read_only=true i project_ref jednego projektu).
  2. Ręczne zatwierdzanie wywołań narzędzi zostaje włączone. Programista czyta SQL, zanim agent go wykona. Od wersji 0.13.0 serwer Supabase sam prosi o potwierdzenie przy destrukcyjnym zapytaniu, ale traktujemy to jako dodatkową siatkę, nie zamiennik.
  3. Mniej narzędzi. Serwer Supabase pozwala ograniczyć zestaw parametrem features; zostawiamy tylko to, czego zadanie wymaga. Nowsze wersje Claude Code ładują definicje narzędzi na żądanie, więc liczba serwerów nie zjada kontekstu tak jak wcześniej, ale uprawnień to nie zmniejsza.
  4. Serwery z rejestru traktujemy jak zależności npm: wersja przypięta, źródło sprawdzone, klucze w zmiennych środowiskowych, nie w pliku w repozytorium.

Od czego zacząć w zespole

Nie od listy dziesięciu serwerów. Zaczynamy od jednego źródła danych, które najczęściej wymusza przełączanie okien: u większości zespołów to baza albo system zgłoszeń. Podpinamy je w trybie tylko do odczytu, dajemy programistom tydzień i patrzymy, które pytania zadają agentowi. Dopiero wtedy dochodzą kolejne serwery i uprawnienia do zapisu, na środowisku, które da się odtworzyć.

Specyfikacja zmienia się szybko. Wersja z 28 lipca 2026 uprościła protokół do bezstanowego i wycofała część funkcji po stronie klienta (sampling, roots). Dla zespołu, który tylko korzysta z serwerów, to niewidoczne: klienci aktualizują się same. Dla zespołu, który pisze własny serwer, jak my z DB2, to sygnał, żeby trzymać się oficjalnych SDK (TypeScript, Python, Go, C#) zamiast własnej implementacji protokołu.

Chcecie wdrożyć to u siebie? Porozmawiajmy.

Akademia to materiały. Wdrożenie to dwa kwartały na Waszym kodzie, z pomiarem efektu w DEVLens. Krótka rozmowa wystarczy, żeby sprawdzić, czy ma to u Was sens. Odpowiadamy w 24 h.