Model Context Protocol (MCP): czym jest, jak działa i jak go wdrożyć w 2026?

Czym jest Model Context Protocol i jaki problem rozwiązuje?

Problem: integracje „każdy z każdym”

Zanim pojawił się MCP, każde połączenie modelu AI z zewnętrznym systemem było osobnym kawałkiem kodu, więc przykładowo, gdy firma używa trzech aplikacji AI (asystent w IDE, chatbot obsługi klienta, wewnętrzny agent) i chce je podłączyć do dziesięciu systemów (GitHub, Jira, baza danych, CRM, ERP…), to w najgorszym wypadku potrzebuje trzydziestu integracji. W takiej sytuacji każda ma własny format wywołań, własną obsługę błędów i własną autoryzację.

MCP upraszcza i standaryzuje proces integracji – aplikacja AI wymaga jednorazowego wdrożenia klienta MCP, a system docelowy jednorazowego uruchomienia serwera MCP. W modelu złożonym z trzech aplikacji oraz dziesięciu systemów przekłada się to na trzynaście osobnych integracji zamiast dotychczasowych trzydziestu. W ten sposób stworzone połączenie można następnie wielokrotnie wykorzystywać w kolejnych aplikacjach.

Modelowe zgadywanki

Model językowy nie zna stanu Twojego magazynu, historii zgłoszeń klienta ani schematu bazy. Dzięki MCP możemy dać modelowi kontrolowany dostęp do prawdziwych danych w momencie, gdy ich potrzebuje, co znacząco zmniejsza szanse na halucynacje modelu. Model oczywiście cały czas może halucynować, a do tego może źle zinterpretować wynik, wybrać niewłaściwe narzędzie albo wyciągnąć błędny wniosek z poprawnych danych. Weryfikacja zostaje po Twojej stronie, a to, jak weryfikujesz pracę modelu i z jakich etapów składa się ta weryfikacja, to materiał na osobny artykuł.

Definicja MCP

Model Context Protocol to otwarty standard komunikacji między aplikacjami wykorzystującymi modele AI a źródłami danych i narzędziami. Za publikacją standardu stoi firma Anthropic, która zaprezentowała go w listopadzie 2024 roku. W grudniu 2025 roku projekt został przekazany pod opiekę Agentic AI Foundation – fundacji powołanej w ramach Linux Foundation przez Anthropic, Block oraz OpenAI, wspieranej m.in. przez Google, Microsoft, AWS i Cloudflare. W efekcie protokół przestał być inicjatywą jednego podmiotu: jego dalszy rozwój techniczny nadzorują wyznaczeni opiekunowie projektu (ang. maintainers) w ramach otwartego procesu zgłaszania propozycji zmian.

Skala adopcji jest dziś znacząca. Zgodnie z oficjalną informacją o wydaniu z 28 lipca 2026 r. oficjalne zestawy SDK najwyższego poziomu (TypeScript, Python, Go, C#) generują łącznie niemal pół miliarda pobrań miesięcznie, natomiast pakiety dla TypeScriptu i Pythona przekroczyły próg miliarda skumulowanych pobrań. Należy pamiętać, że są to wskaźniki pobrań pakietów, które obejmują m.in. automatyczne instalacje w potokach CI/CD, i nie są bezpośrednią liczbą użytkowników czy produkcyjnych wdrożeń.

Analogia: nie HTTP, raczej LSP

W materiałach o MCP często pada porównanie do HTTP, ale to nie tak, bo MCP działa na HTTP (albo na standardowym wejściu/wyjściu procesu), więc nie jest jego odpowiednikiem. Sama dokumentacja MCP używa analogii do złącza USB-C, czyli mamy jeden standardowy port do wszystkiego.

Dla programistów trafniejsze jest porównanie do LSP, czyli Language Server Protocol, na którym MCP się wzorował. LSP sprawił, że obsługę języka programowania piszesz tylko raz, a działa ona w VS Code, Neovimie czy JetBrains. Standard MCP robi to samo, ale dla integracji z modelami AI, czyli serwer piszesz raz, a korzysta z niego Claude, Cursor, Copilot czy własny agent. Technicznie komunikaty to JSON-RPC 2.0.

MCP a API, function calling i RAG

Serwer MCP zwykle korzysta z istniejącego API, bazy lub systemu plików. Udostępnia nad nimi wspólny sposób odkrywania i wywoływania narzędzi, ale logika biznesowa i ograniczenia systemu źródłowego nadal obowiązują. Wywoływanie funkcji (ang. function calling) to mechanizm, przez który model proponuje nazwę funkcji i argumenty; host może przetłumaczyć tę propozycję na wywołanie MCP. Sam model nie musi znać protokołu.

RAG polega na wyszukaniu materiałów i dodaniu ich do kontekstu przed wygenerowaniem odpowiedzi. MCP może udostępnić narzędzie wyszukiwania dla takiego procesu, ale nie zapewnia automatycznie indeksowania, embeddingów ani oceny trafności wyników.

W przypadku pojedynczej aplikacji i stałego zestawu operacji w zupełności wystarczy bezpośrednie API lub prosta automatyzacja. MCP zyskuje przewagę dopiero wtedy, gdy te same możliwości trzeba udostępnić wielu różnym hostom. Warto pamiętać, że jego wdrożenie nie wymaga ani trenowania modelu, ani budowania autonomicznego agenta.

Architektura MCP: jak to działa pod maską?

Host, klient i serwer

W wielu opisach MCP role hosta i klienta są zamienione, więc warto je uporządkować zgodnie ze specyfikacją:

• Host – aplikacja, z której korzysta użytkownik: Claude Desktop, Claude Code, Cursor, VS Code albo Twoja własna aplikacja agentowa. Host zarządza rozmową i modelem, decyduje, które serwery podłączyć, pilnuje zgód użytkownika i uprawnień.
• Klient – komponent wewnątrz hosta odpowiedzialny za komunikację z jednym serwerem. Nie oznacza to konieczności utrzymywania stałego połączenia sieciowego ani sesji protokołu. Relacja jest 1:1: host podłączony do pięciu serwerów ma pięć instancji klienta.
• Serwer – program, który wystawia dane lub funkcje konkretnego systemu (repozytorium, bazy, CRM-u) w ustandaryzowanej formie. Może działać lokalnie jako proces na Twoim komputerze albo zdalnie jako usługa HTTP.

┌──────────────── Host (np. Cursor) ─────────────────┐
│  Model LLM  ◄──►  logika hosta, zgody, uprawnienia  │
│                     │          │          │         │
│                 Klient A   Klient B   Klient C      │
└─────────────────────┼──────────┼──────────┼─────────┘
                      ▼          ▼          ▼
               Serwer GitHub  Serwer   Serwer bazy
                (zdalny)     Sentry    (lokalny, stdio)

Model nie łączy się z serwerem bezpośrednio, ale proponuje wywołanie narzędzia, a wykonuje je host przez klienta. To host jest miejscem, w którym można wymusić potwierdzenie, ograniczyć uprawnienia czy zapisać log.

Co udostępnia serwer MCP: narzędzia, zasoby, szablony

Serwer może wystawiać trzy rodzaje elementów (w specyfikacji nazywanych prymitywami), różniących się przede wszystkim tym, kto decyduje o ich użyciu:

Narzędzia mogą mieć adnotacje, np. readOnlyHint albo destructiveHint, które podpowiadają hostowi, czy operacja coś zmienia. To tylko podpowiedzi deklarowane przez serwer, więc host nie powinien im ślepo ufać w sytuacji, gdy serwer nie pochodzi z zaufanego źródła.

W drugą stronę serwer może poprosić użytkownika o dane w trakcie działania narzędzia – to elicitation, np. prośba o potwierdzenie „Usunąć 3 pliki?”. Dwa inne mechanizmy po stronie klienta, sampling (serwer prosi hosta o wywołanie modelu) i roots (host wskazuje serwerowi katalogi robocze), zostały w wersji 2026-07-28 oznaczone jako przestarzałe. Pozostają w specyfikacji w okresie wycofywania trwającym co najmniej 12 miesięcy; ich dostępność zależy od klienta i SDK. Nowe wdrożenie nie powinno zakładać ich obsługi.

Warstwa transportowa: stdio i Streamable HTTP

MCP definiuje dwa standardowe transporty:

1. stdio – host uruchamia serwer jako proces potomny i komunikuje się z nim przez standardowe wejście i wyjście. Dobre dla narzędzi lokalnych: dostęp do plików, lokalnego Gita, bazy deweloperskiej.
2. Streamable HTTP – serwer działa jako usługa pod jednym endpointem HTTP. To transport dla serwerów zdalnych, współdzielonych przez zespół lub udostępnianych klientom.

Jeśli trafisz na opisy transportu „SSE” (Server-Sent Events) jako drugiej opcji obok stdio – to stan z 2024 r. Pierwotny transport HTTP+SSE został zastąpiony przez Streamable HTTP już w marcu 2025 r., a specyfikacja 2026-07-28 formalnie oznaczyła go jako przestarzały z rocznym okresem wygaszania. Nowych serwerów nie buduj na starym transporcie HTTP+SSE. Samo SSE pozostaje poprawnym sposobem przesyłania strumieniowej odpowiedzi w Streamable HTTP.

Co zmieniła specyfikacja 2026-07-28

Ta rewizja zmienia sposób komunikacji klienta z serwerem, a najważniejsze jest, że MCP stał się bezstanowy na poziomie protokołu. W związku z tym zniknęło otwierające połączenie powitanie (initialize/initialized) oraz nagłówek Mcp-Session-Id. Każde żądanie niesie wersję protokołu i możliwości klienta w _meta; dane clientInfo są opcjonalne. Żądanie może trafić do dowolnej instancji serwera. Dostępne funkcje można wcześniej sprawdzić opcjonalnym server/discover, bez inicjalizacji sesji.

Tak wygląda wywołanie narzędzia w nowej wersji:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_open_invoices
Content-Type: application/json
Accept: application/json, text/event-stream
 
{"jsonrpc":"2.0","id":7,"method":"tools/call",
 "params":{"name":"get_open_invoices","arguments":{"customerId":"C-1042"},
   "_meta":{
     "io.modelcontextprotocol/protocolVersion":"2026-07-28",
     "io.modelcontextprotocol/clientInfo":{"name":"crm-agent","version":"2.1"},
     "io.modelcontextprotocol/clientCapabilities":{}
   }}}

Oto przykład komunikatu przedstawionego z pominięciem nagłówków uwierzytelniania. Warto pamiętać, że bezpieczne wdrożenie produkcyjne wymaga dodatkowo użycia tokenu dostępu, a nazwa i wersja przekazywane w obiekcie clientInfo służą wyłącznie celom informacyjnym i nie potwierdzają tożsamości użytkownika.

Praktyczne skutki dla wdrożeń:

• Serwer zdalny może stać za zwykłym load balancerem round-robin, bez „przyklejania” klienta do instancji i bez współdzielonego magazynu sesji.

• Mcp-Method jest wymagany dla żądań, a Mcp-Name dla tools/call, resources/read i prompts/get; pomagają routować i mierzyć ruch, lecz serwer musi sprawdzić ich zgodność z treścią żądania.

• Odpowiedzi list (np. tools/list) mają pola ttlMs i cacheScope, więc klient wie, jak długo może je cache'ować.

• Zapytania serwera do użytkownika (np. potwierdzenia) działają przez Multi Round-Trip Requests: serwer zwraca wynik „potrzebne dane od użytkownika”, a klient ponawia wywołanie z odpowiedzią – bez trzymania otwartego strumienia.

• Długotrwałe operacje obsługuje rozszerzenie Tasks, a interaktywne interfejsy dostarczane przez serwer i renderowane w hoście obsługuje MCP Apps; oba wymagają jawnego wsparcia po stronie klienta i serwera.

• Wprowadzono formalną politykę wycofywania funkcji: minimum 12 miesięcy między oznaczeniem jako przestarzałe a usunięciem.

Wszystkie cztery SDK najwyższego poziomu (TypeScript, Python, Go, C#) obsługują nową wersję od dnia premiery. W ogłoszeniu wydania obsługę SDK dla Rusta wskazano jako beta.

Jak podejść do wdrażania serwerów MCP? Strategia krok po kroku

Faza 1: identyfikacja potrzeb i audyt danych

Zacznij od procesu i zadaj sobie pytanie: w którym miejscu ktoś regularnie przepisuje dane między systemami albo szuka informacji w trzech miejscach naraz? Typowe przykłady to obsługa klienta, raportowanie, diagnostyka błędów lub przygotowanie dokumentów.

Dla każdego procesu ustal:

• jakie dane są potrzebne i w jakim minimalnym zakresie,
• jakie operacje zapisu są naprawdę konieczne (często na początek wystarczy sam odczyt),
• które dane są osobowe lub wrażliwe w rozumieniu RODO.

Ten ostatni punkt jest o tyle ważny, że to host decyduje, które wyniki przekaże do modelu. Przy modelu chmurowym przekazane dane opuszczają Twoje środowisko, bo to, że mamy lokalny serwer MCP, nie oznacza lokalnego przetwarzania przez model. Ustal podstawę przetwarzania, okres retencji oraz odbiorców danych. Jeśli dostawca przetwarza dane osobowe w Twoim imieniu, wymagana jest umowa powierzenia (DPA), przy czym ewentualny transfer poza EOG należy ocenić odrębnie. Agreguj i ograniczaj zakres danych po stronie serwera, zanim opuszczą system źródłowy, a także zweryfikuj, jakie informacje host zapisuje w historii oraz logach.

Faza 2: gotowe serwery czy własne (build vs. buy)

Gotowe serwery to dziś przede wszystkim serwery utrzymywane przez samych dostawców usług, czyli mam tu na myśli na przykład GitHub, Sentry, Supabase, Linear, Figma, Cloudflare, Senuto i wielu innych. Kiedy dostawca systemu ma oficjalny serwer MCP, najlepiej od niego zacząć.

Jedno ostrzeżenie, bo wiele poradników wciąż go nie uwzględnia: referencyjne serwery z repozytorium modelcontextprotocol/servers dla PostgreSQL, GitHuba, Slacka, Google Drive, Sentry i kilku innych systemów zostały zarchiwizowane w maju 2025 r. i nie mają żadnych gwarancji bezpieczeństwa. Zespół Datadog Security Labs opisał w archiwalnym serwerze PostgreSQL lukę SQL injection, która pozwalała obejść tryb tylko do odczytu. Przed podłączeniem dowolnego serwera sprawdź, kto go utrzymuje i kiedy był ostatnio aktualizowany.

Własny serwer warto zbudować wtedy, gdy docelowy system nie posiada oficjalnej integracji MCP lub istniejące rozwiązanie nie odpowiada Twojej polityce uprawnień. Możesz to rozważyć także w sytuacji, gdy zależy Ci na wystawieniu modelowi gotowych operacji biznesowych zamiast surowych punktów końcowych API, a także podczas pracy z oprogramowaniem dedykowanym dla danej firmy lub rynku – na przykład systemem ERP enova365.

Przy polskich systemach trzeba sprawdzić, czy w ogóle jest do czego się podłączyć. W przypadku programu Płatnik punktem integracji z systemem kadrowym może być udokumentowany przez ZUS format KEDU. Przygotowanie pliku, import, walidacja i podpisanie wysyłki to osobne etapy, zupełnie niezwiązane z MCP. Agent może przygotować dane lub plik do sprawdzenia, a zatwierdzenie dokumentów powinno pozostać po stronie uprawnionej osoby.

Najważniejsza zasada projektowa dla własnego serwera: projektuj narzędzia wokół zadań, nie wokół endpointów API. Zamiast wystawiać 40 metod REST 1:1, lepiej dać modelowi kilka dobrze opisanych narzędzi, np. find_customer, get_open_invoices, create_invoice_draft. Model lepiej wybiera spośród kilku narzędzi o jasnych opisach niż spośród kilkudziesięciu podobnych.

Dla zespołów frontendowych naturalnym wyborem jest oficjalne SDK dla TypeScriptu – serwer zdalny w Streamable HTTP można uruchomić jako zwykłą usługę Node.js albo na platformie serverless. Sprawdź zgodność użytego adaptera i SDK z 2026-07-28, limity czasu wykonania oraz obsługę strumieniowania odpowiedzi; sama dostępność hostingu HTTP nie gwarantuje zgodności protokołu.

Faza 3: architektura bezpieczeństwa

W przypadku transportu HTTP specyfikacja opiera autoryzację na projekcie OAuth 2.1. Ponieważ mechanizm ten pozostaje opcjonalny, serwer udostępniający dane firmowe wymaga bezwzględnej ochrony dostępu na poziomie aplikacji. W przypadku interfejsu stdio poświadczenia przekazuje najczęściej środowisko uruchomieniowe. Wydanie 2026-07-28 zaostrzyło reguły bezpieczeństwa i teraz klienci muszą walidować parametr iss w odpowiedzi autoryzacyjnej (zgodnie z RFC 9207), dane uwierzytelniające klienta są ściśle wiązane z wydającym je serwerem, a dynamiczną rejestrację klientów (DCR) zastąpiono dokumentami metadanych klienta (CIMD).

Przy projektowaniu dostępu stosuj trzy zasady:

1. Najmniejsze uprawnienia. Serwer bazy danych dostaje rolę tylko do odczytu na dedykowanej replice lub widokach, a nie konto administratora. Uprawnienia egzekwuje serwer i system źródłowy – nigdy prompt.
2. Brak przekazywania tokenów dalej. Specyfikacja wprost tego zabrania (ang. token passthrough). Serwer MCP waliduje token przeznaczony dla siebie, w tym odbiorcę, a do zewnętrznego API używa osobnych poświadczeń. Mogą to być tokeny delegowane konkretnego użytkownika albo konto usługi z ograniczonym zakresem. Wspólne konto usługi nie zastępuje kontroli dostępu użytkowników.
3. Człowiek w pętli dla operacji nieodwracalnych. Usunięcie danych, wysłanie wiadomości na zewnątrz, płatność – wymagają potwierdzenia. Host może wymusić zgodę na wywołanie narzędzia, a serwer może sam poprosić o potwierdzenie przez elicitation.

Lokalny serwer wykonuje kod z uprawnieniami procesu, który go uruchomił; stdio nie izoluje go w piaskownicy. Ogranicz dostęp do plików, sieci i sekretów. Dla HTTP stosuj HTTPS, walidację Origin i ochronę przed SSRF przy pobieraniu zewnętrznych adresów. Lokalny endpoint HTTP wiąż z interfejsem loopback, zamiast domyślnie udostępniać go całej sieci.

Tak wygląda prośba serwera o potwierdzenie w wersji 2026-07-28. Przykład pokazuje pole result odpowiedzi JSON-RPC; klient musi wcześniej zadeklarować obsługę elicitation.form w swoich możliwościach:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Wysłać 12 prywatnych przypomnień do wskazanych pracowników?",
        "requestedSchema": {
          "type": "object",
          "properties": { "approved": { "type": "boolean" } },
          "required": ["approved"]
        }
      }
    }
  },
  "requestState": "OPAQUE_SERVER_PROTECTED_STATE"
}

Klient prezentuje pytanie użytkownikowi, po czym ponawia wywołanie z nowym identyfikatorem JSON-RPC, parametrem inputResponses oraz niezmienionym requestState. W tym przykładzie zatwierdzenie wymaga przekazania wartości action: "accept" i content.approved: true – odmowa lub anulowanie natychmiast wstrzymuje wysyłkę. Wartość requestState ma charakter poglądowy; rzeczywisty stan musi być zabezpieczony przed modyfikacją oraz ściśle powiązany z użytkownikiem i autoryzowaną operacją, przy czym samo zakodowanie w Base64 nie zapewnia wystarczającej ochrony. Ekran potwierdzenia powinien jednoznacznie wskazywać odbiorców oraz treść wiadomości, a jakakolwiek zmiana tych danych wymaga ponownego uzyskania zgody.

Faza 4: wdrożenie, testy i utrzymanie

• Dla narzędzi jednego programisty. Szybki start, ale każdy członek zespołu konfiguruje serwer sam, a dostęp do sekretów trzeba zabezpieczyć w jego środowisku.

• Dla zespołów i produkcji. Kontener (Docker, Kubernetes) albo serverless. W połączeniach 2026-07-28 protokół nie wymaga sticky sessions, choć aplikacja nadal może potrzebować trwałego magazynu danych.

• Instrumentuj host, serwer MCP i wywołania usług, np. przez OpenTelemetry. Przekazywanie kontekstu śledzenia W3C (traceparent) wymaga wsparcia i konfiguracji użytych komponentów; sam protokół nie tworzy kompletnego śladu ani nie wysyła go do systemu monitoringu.

• Loguj tożsamość użytkownika, narzędzie, czas, status i identyfikator operacji. Parametry i wyniki zapisuj po maskowaniu sekretów i ograniczeniu danych osobowych, z ustaloną retencją. Powiąż te zdarzenia z audytem systemu źródłowego.

• Limity liczby żądań (rate limiting) i kosztów ustawiaj na bramce – nagłówki Mcp-Method i Mcp-Name pozwalają limitować konkretne narzędzia, np. osobno drogie zapytania analityczne.

• Oficjalny zestaw testów zgodności (conformance suite) sprawdza implementację protokołu. Osobno testuj zachowanie modelu: czy przy typowych poleceniach wybiera właściwe narzędzia z właściwymi argumentami. Sprawdź odmowę dostępu do cudzych danych, wygaśnięcie tokenu, anulowanie zgody, przekroczenie limitu czasu i ponowienie żądania. Operacje zapisu potrzebują ochrony przed duplikatami, np. klucza idempotencji; identyfikator JSON-RPC sam tego nie zapewnia.

Pierwsze uruchomienie i kryterium sukcesu

Rozwijanie integracji najlepiej zacząć od pojedynczego narzędzia w trybie odczytu – na przykład get_open_invoices na danych testowych. Należy precyzyjnie zdefiniować inputSchema, narzucić limit zwracanych wyników oraz zadbać o weryfikację uprawnień do konkretnego klienta, pamiętając, że parametr customerId przekazany przez model nie stanowi dowodu tożsamości ani uprawnień użytkownika.

1. Uruchom serwer i podłącz go do MCP Inspectora. Dla stdio podajesz komendę startową i argumenty, dla HTTP adres endpointu oraz wymagane uwierzytelnianie.
2. Wywołaj tools/list, sprawdź opis i schemat narzędzia, a potem wykonaj tools/call z poprawnymi i błędnymi argumentami. Inspector sprawdza komunikację bez udziału modelu.
3. Dodaj serwer w docelowym hoście. Format konfiguracji i zakres obsługiwanych funkcji zależą od aplikacji; poprawne działanie w Inspectorze nie zastępuje tego testu.
4. Zadaj kilka reprezentatywnych pytań i porównaj wyniki z systemem źródłowym. Zmierz poprawność odpowiedzi, czas wykonania i koszt całego zadania, uwzględniając model, hosting oraz API usług.

Przed udostępnieniem zespołowi zapisz, kto utrzymuje serwer, jak cofnąć mu dostęp i jakie wyniki pilotażu uznajesz za wystarczające. Samo poprawne połączenie potwierdza tylko transport, a nie użyteczność procesu.

Przykłady zastosowań MCP w praktyce

Poniższe scenariusze pokazują możliwe – czysto hipotetyczne – architektury, w zależności od branży.

1. Procesy HR i kadrowe

Problem: dział HR i menedżerowie sprawdzają te same informacje, czyli np. saldo urlopów, nieobecności, terminy badań okresowych, w kilku systemach, a potem ręcznie piszą przypomnienia.

Rozwiązanie MCP: własny serwer MCP nad API systemu kadrowego (np. enova365) z narzędziami tylko do odczytu, plus serwer dla komunikatora firmowego wraz z narzędziem tworzącym wiadomości.

Scenariusz: menedżer prosi o sprawdzenie zaległych urlopów w swoim zespole i przygotowanie przypomnień na Slacku. Model pobiera salda przez narzędzie serwera kadrowego, następnie przygotowuje szkice wiadomości, a wysyłka czeka na potwierdzenie menedżera.

Na co uważać:

• Serwer musi zwracać dane tylko zespołu danego menedżera i jest to uprawnienie egzekwowane w serwerze na podstawie tożsamości użytkownika.
• Dane kadrowe to dane osobowe, a część z nich (np. zwolnienia lekarskie) to dane szczególnej kategorii. Narzędzia powinny zwracać minimum informacji, czyli saldo dni.
• Przypomnienie o urlopie to prosta automatyzacja. Jeżeli jednak ten sam system ma wspierać decyzje dotyczące ocen pracowników, awansów czy zwolnień, może zostać sklasyfikowany jako system wysokiego ryzyka w rozumieniu AI Act. O kwalifikacji decyduje przeznaczenie narzędzia oraz jego wpływ na proces decyzyjny, a nie sama technologia MCP. Zgodnie z harmonogramem zaktualizowanym w lipcu 2026 r. przepisy dotyczące systemów wysokiego ryzyka z załącznika III będą stosowane od 2 grudnia 2027 r., natomiast wymogi wynikające z RODO podlegają niezależnej ocenie.

2. Środowisko deweloperskie i DevOps

Problem: informacje o błędzie są rozproszone między narzędziem do monitoringu, repozytorium, systemem zgłoszeń oraz bazą danych. Diagnoza wymaga przeskakiwania między kilkoma kartami.

Rozwiązanie MCP: asystent kodu (Cursor, Claude Code, VS Code) połączony z oficjalnym serwerem Sentry, oficjalnym serwerem GitHuba i serwerem bazy z dostępem do schematu.

Scenariusz: programista pyta, dlaczego użytkownicy dostają błąd 500 przy usuwaniu konta. Model pobiera z Sentry stack trace i częstotliwość błędu, sprawdza schemat tabeli i wykrywa, że usunięcie blokuje klucz obcy w tabeli zamówień. Następnie proponuje poprawkę obsługi błędów lub procesu usuwania konta w formie pull requesta do przeglądu. Warto pamiętać, że brak klauzuli ON DELETE CASCADE bywa celowym zabiegiem chroniącym historię zamówień, a wprowadzenie kaskadowego usuwania danych zawsze wymaga odrębnej decyzji biznesowej.

Na co uważać:

• „Bezpośrednie połączenie z bazą produkcyjną” brzmi dobrze w konspekcie, ale w praktyce oznacza: rola tylko do odczytu, najlepiej na replice lub na samym schemacie bez danych. Nie archiwalny serwer referencyjny.
• Treść zgłoszeń i komunikatów błędów może pochodzić od użytkowników – czyli jest niezaufana (więcej w sekcji o prompt injection).
• Zmiany w kodzie przechodzą przez normalny przegląd kodu, w którym agent proponuje rozwiązania, a człowiek scala.

3. Analityka biznesowa (BI)

Problem: żeby odpowiedzieć na pytanie biznesowe, analityk pisze SQL, eksportuje wyniki do arkusza i łączy je ręcznie z danymi z CRM.

Rozwiązanie MCP: połączenie z hurtownią danych (Snowflake i BigQuery mają serwery MCP rozwijane przez dostawców) oraz z CRM (HubSpot udostępnia własny serwer MCP). Sprawdź wersję protokołu każdej usługi: dokumentacja zarządzanego serwera Snowflake wskazuje 2025-11-25, więc nowych mechanizmów z 2026-07-28 nie można zakładać dla każdego połączenia.

Scenariusz: dyrektor sprzedaży pyta, które produkty najbardziej straciły na sprzedaży w tym kwartale i którzy klienci przestali je kupować. Model układa zapytanie SQL, pobiera wyniki z hurtowni, dopasowuje klientów w CRM i zwraca zestawienie.

Na co uważać:

• Zapytanie, które działa, ale odpowiada na inne pytanie. Rozbieżności w wynikach często wynikają z nieujednoliconych pojęć – na przykład z odmiennej definicji „spadku sprzedaży”, pominięcia zwrotów czy podwójnie zaksięgowanych faktur. Skutecznym rozwiązaniem jest wprowadzenie warstwy semantycznej: dedykowanych widoków z uzgodnioną logiką metryk lub konkretnych narzędzi biznesowych (jak get_sales_by_product(period)) w miejsce dowolnych zapytań SQL.
• Raport powinien zawierać użyte zapytanie, żeby analityk mógł je zweryfikować.
• Połączenie danych z hurtowni i CRM działa tylko wtedy, gdy identyfikatory klientów są spójne w obu systemach. MCP tego nie naprawi.
• W hurtowniach rozliczanych za przetworzone dane ustaw limit kosztu na zapytanie. Model potrafi wygenerować bardzo drogi SELECT *.

Wyzwania i ograniczenia technologii MCP

Prompt injection i zatrute narzędzia

Stwierdzenie, że złośliwy tekst w bazie zmusi serwer MCP do usunięcia danych, jest nieprecyzyjne. Serwer jedynie wykonuje polecenia, a treść interpretuje model. Atak następuje wtedy, gdy model przetwarza niezaufany tekst (np. e-mail czy rekord z bazy) zawierający ukrytą instrukcję i na jej podstawie wywołuje narzędzie powodujące szkody. Protokół MCP sam w sobie nie eliminuje tego ryzyka.

Kluczowym zagrożeniem jest tzw. „śmiertelna triada” (zdefiniowana przez Simona Willisona), która jest połączeniem dostępu do danych prywatnych, kontaktu z niezaufaną treścią oraz możliwości wysyłania danych na zewnątrz. Połączenie kilku serwerów MCP w jednym hoście może łatwo utworzyć taką kombinację, nawet jeśli każdy z nich z osobna wydawał się bezpieczny.

Osobna kategoria to zatrute narzędzia (ang. tool poisoning), czyli złośliwe instrukcje ukryte w opisie narzędzia serwera, który zainstalowałeś, albo opis zmieniony po tym, jak narzędzie zostało zaakceptowane.

Co realnie pomaga:

• rozdzielanie serwerów do odczytu i do zapisu oraz niełączenie w jednej sesji niezaufanych treści z narzędziami wysyłającymi dane na zewnątrz,
• potwierdzenia człowieka dla operacji nieodwracalnych,
• uprawnienia egzekwowane w systemach źródłowych,
• instalowanie serwerów tylko z zaufanych źródeł i przypinanie ich wersji.

Wydajność i okno kontekstowe

Gdy host udostępnia modelowi pełny katalog narzędzi, ich nazwy, opisy oraz schematy parametrów zajmują miejsce w oknie kontekstowym przy każdym wywołaniu. Kilka serwerów oferujących dziesiątki narzędzi potrafi drastycznie ograniczyć dostępny kontekst jeszcze przed wpisaniem zapytania przez użytkownika, co dodatkowo obniża trafność doboru narzędzi przez model. Odrębnym wyzwaniem są same odpowiedzi – narzędzie zwracające tysiące rekordów błyskawicznie zapycha kontekst i generuje niepotrzebne koszty.

Rozwiązania:

• paginację w MCP warto wyraźnie rozdzielić: kursor w metodzie tools/list służy do stronicowania samych definicji narzędzi, natomiast paginację zwracanych danych – takich jak faktury czy rekordy w wywołaniu tools/call – należy zaprojektować samodzielnie w argumentach i wyniku narzędzia,
• narzędzia zwracające podsumowania i wybrane pola zamiast pełnych rekordów,
• wyniki w structuredContent, opcjonalnie walidowane przez outputSchema; host może wybrać dane dla modelu, ale sam schemat nie zmniejsza odpowiedzi ani nie ukrywa jej przed modelem,
• mechanizmy wyszukiwania narzędzi po stronie hosta, które ładują definicje dopiero wtedy, gdy są potrzebne,
• stabilny katalog i cache wyników MCP zgodny z ttlMs oraz cacheScope, z izolacją danych użytkowników. To odrębny mechanizm od cache promptów dostawcy modelu; stabilne definicje mogą mu pomagać, ale ttlMs nim nie steruje.

Stan i skalowanie

W starszym Streamable HTTP sesje były opcjonalne, więc bezstanowe wdrożenia istniały już wcześniej. Gdy implementacja używała stanu sesji, skalowanie wymagało odpowiedniego routingu lub współdzielenia tego stanu. Wersja 2026-07-28 usuwa sesje z protokołu, ułatwiając skalowanie jak w API HTTP. Przepustowość nadal ograniczają baza, zewnętrzne API, limity hostingu i koszt operacji.

Co zostaje:

• stan aplikacji nadal należy gdzieś przechowywać. Zalecanym wzorcem są jawne identyfikatory: narzędzie zwraca np. basket_id, a model przekazuje go w kolejnych wywołaniach jako zwykły argument, natomiast serwer za każdym razem weryfikuje, czy użytkownik ma dostęp do danego obiektu,
• koszt migracji dla serwerów, które polegały na identyfikatorze sesji, oraz dla implementacji eksperymentalnego Tasks z wersji 2025-11-25,
• okres przejściowy – część klientów zostanie na starszym SDK i poprzedniej wersji protokołu, więc serwer publiczny przez jakiś czas powinien obsługiwać obie.

Jakość ekosystemu

Katalogi serwerów MCP liczą tysiące pozycji, ale ich jakość jest bardzo nierówna: porzucone projekty, brak autoryzacji, narzędzia będące cienką nakładką na API bez sensownych opisów. Popularność paczki w npm nie świadczy o jej bezpieczeństwie – najlepszym przykładem jest wspomniany archiwalny serwer PostgreSQL.

Dokąd zmierza ekosystem MCP?

Integracja narzędzi staje się coraz szersza i kolejne kroki z pewnością będą zmierzały do coraz większych połączeń między narzędziami. Standaryzacja przyśpiesza ten proces. W ciągu kilku lat jeden model LLM będzie obsługiwał dane z wielu narzędzi, a człowiek będzie się z nim komunikował głosowo i, jak sądzę, mniej szczegółowo niż obecnie – dzisiaj musimy znacznie więcej pracy poświęcić zarówno na prompty, jak i kontrolę modeli LLM. Nie chcę tutaj iść w kierunku odejścia od terminali czy okien dialogowych, ale z pewnością już niedługo więcej czasu będziemy poświęcać na komunikację głosową z agentami AI.

Sama budowa serwera MCP technicznie nie jest trudna, trudnością jest co innego: odpowiednie zaprojektowanie procesu pracy, by użytkownik – człowiek – mógł skutecznie nadzorować pracę oraz stanowił skuteczną warstwę jakościową. Właśnie to połączenie projektowania API, bezpieczeństwa i znajomości procesów biznesowych jest w tym wszystkim najważniejsze.