MCP — Model Context Protocol: jak działa i do czego służy

Ostatnia aktualizacja: 2026-07-13

Model Context Protocol (MCP) to otwarty protokół, który porządkuje sposób łączenia aplikacji AI z zewnętrznymi narzędziami, plikami, bazami danych i innymi źródłami kontekstu. Zamiast pisać osobną integrację dla każdej kombinacji model–aplikacja–usługa, twórca może wystawić możliwości jako serwer MCP, a aplikacja AI może połączyć się z nimi przez klienta MCP.

Najkrótsza odpowiedź brzmi: MCP jest warstwą integracyjną, a nie modelem językowym, bazą wektorową ani samodzielnym agentem. Protokół opisuje komunikację i kontrakty. To host decyduje, z jakimi serwerami połączyć model, jakie dane udostępnić i czy wymagać zgody przed wykonaniem operacji.

W tym przewodniku zobaczysz architekturę host–klient MCP–serwer MCP, trzy główne prymitywy MCP, przebieg komunikacji JSON-RPC, różnicę między MCP a function calling, przykład prostego serwera w Pythonie oraz ograniczenia i zagrożenia, o których warto pamiętać przed wdrożeniem.

Czym jest Model Context Protocol?

MCP został przedstawiony przez Anthropic 25 listopada 2024 roku jako otwarty standard integracji aplikacji AI z systemami zewnętrznymi. Jego rolą jest ujednolicenie interfejsu: serwer opisuje dostępne narzędzia, zasoby i prompty, a klient może je odkrywać i obsługiwać w sposób przewidywalny dla hosta.

Jeśli dopiero poznajesz warstwę modeli, pomocne będzie wcześniejsze wyjaśnienie czym jest LLM. LLM generuje tekst lub ustrukturyzowane wywołania na podstawie kontekstu, ale sam z siebie nie ma dostępu do bieżącego kursu waluty, prywatnego repozytorium czy systemu CRM. MCP nie dodaje wiedzy do parametrów modelu. Dostarcza standardową drogę, przez którą aplikacja może przekazać kontekst lub wykonać operację.

To odróżnia MCP od RAG. Retrieval-Augmented Generation jest wzorcem pobierania informacji i dołączania ich do promptu przed generowaniem odpowiedzi. MCP może udostępnić narzędzie wyszukujące albo zasób z dokumentem, ale nie jest metodą embeddingów, wyszukiwarką wektorową ani kompletnym pipeline’em RAG.

Problem wielu punktowych integracji

Przed pojawieniem się wspólnych protokołów twórca aplikacji musiał osobno implementować obsługę GitHuba, Slacka, bazy SQL, dysku firmowego czy API pogodowego. Dodatkowo każda aplikacja miała własny format opisu narzędzi i własny sposób potwierdzania operacji. Gdy liczba modeli i usług rosła, rosła też liczba adapterów do utrzymania.

MCP rozdziela odpowiedzialność. Host jest aplikacją, która koordynuje model i użytkownika. Klient MCP jest połączeniem hosta z jednym serwerem. Serwer MCP opakowuje konkretną usługę lub zbiór funkcji. Nie oznacza to, że każda implementacja jest automatycznie przenośna: hosty mogą różnić się obsługiwanymi funkcjami, wersją protokołu, interfejsem zgód i polityką bezpieczeństwa. Standard zmniejsza jednak koszt integracji, bo wspólny kontrakt może być używany przez wielu klientów.

Architektura MCP: host, klient MCP i serwer MCP

Oficjalna specyfikacja MCP opisuje architekturę host–klient MCP–serwer MCP. Warto rozróżnić te pojęcia, bo w marketingowych opisach „klient MCP” i „aplikacja AI” bywają używane zamiennie.

Host — aplikacja, w której pracuje model

Hostem jest aplikacja AI, na przykład środowisko programistyczne, aplikacja desktopowa albo własny interfejs czatu. Host zazwyczaj:

• tworzy i zamyka połączenia z serwerami MCP;
• utrzymuje osobną sesję klienta dla każdego serwera;
• wybiera, jakie narzędzia i zasoby pokazać modelowi;
• agreguje kontekst z wielu połączeń;
• obsługuje zgodę użytkownika i politykę uprawnień;
• wykonuje lub zleca wykonanie wywołań narzędzi;
• izoluje serwery od całej rozmowy i od siebie nawzajem.

Host jest zatem miejscem, w którym powinny znajdować się najważniejsze granice zaufania. Serwer nie powinien samowolnie uzyskać pełnej historii rozmowy tylko dlatego, że jest podłączony do hosta. Nie powinien też zakładać, że nazwa narzędzia albo jego opis stanowi gwarancję bezpieczeństwa.

Klient MCP — połączenie jeden do jednego

Klient MCP jest komponentem uruchamianym przez hosta. Utrzymuje połączenie z konkretnym serwerem, negocjuje wersję protokołu i możliwości, wysyła żądania oraz odbiera odpowiedzi. W typowej architekturze jeden host ma wiele instancji klienta, a każda instancja ma relację jeden do jednego z jednym serwerem.

Dzięki temu host może mieć osobne granice dla serwera plików, serwera GitHuba i serwera analitycznego. Nadal musi jednak poprawnie skonfigurować uprawnienia. Izolacja połączeń nie zastępuje kontroli dostępu w systemie, do którego serwer ma dostęp.

Serwer MCP — wyspecjalizowana brama do danych i funkcji

Serwer MCP udostępnia możliwości przez zdefiniowany interfejs. Może być lokalnym procesem uruchamianym przez hosta albo zdalną usługą dostępną przez HTTP. Przykładowy serwer może:

• zwracać odczyt tylko z określonego katalogu;
• wyszukiwać rekordy w bazie danych;
• pobierać bieżące dane z publicznego API;
• tworzyć szkic zgłoszenia w systemie obsługi;
• udostępniać strukturę repozytorium jako zasób;
• dostarczać gotowy prompt do analizy pull requestu.

Dobrze zaprojektowany serwer jest wąski. Zamiast wystawiać całe SDK chmurowe, udostępnia niewielki zestaw funkcji potrzebnych do celu aplikacji. Takie ograniczenie ułatwia audyt, testy, wersjonowanie i odebranie uprawnień.

Trzy prymitywy MCP: tools, resources i prompts

W podstawowym modelu MCP serwer oferuje trzy rodzaje możliwości. Różnią się nie tylko formatem, ale także tym, kto kontroluje ich użycie.

Tools — operacje, które model może wywołać

Tool jest funkcją opisaną nazwą, opisem i schematem argumentów. Może odczytywać dane, wywołać API albo zmienić stan systemu. Przykładowe nazwy to get_exchange_rate, search_issues, read_customer i create_draft.

W dokumentacji MCP tools są prymitywem sterowanym przez model: model może wybrać narzędzie na podstawie opisu, ale host powinien zachować kontrolę nad tym, czy i jak wywołanie zostanie wykonane. Bezpieczny interfejs użytkownika pokazuje co najmniej nazwę narzędzia, argumenty, zakres operacji i informację, czy operacja ma skutek uboczny.

Przykładowy opis toola może wyglądać tak:

{
  "name": "get_exchange_rate",
  "description": "Zwraca ostatni dostępny kurs średni waluty z API NBP. Narzędzie tylko odczytuje dane.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "currency": {
        "type": "string",
        "description": "Trzyliterowy kod waluty, na przykład USD lub EUR"
      }
    },
    "required": ["currency"]
  }
}

Opis pomaga modelowi, ale nie jest mechanizmem autoryzacji. Uprawnienie powinno być sprawdzane w kodzie serwera i w systemie docelowym. Jeśli użytkownik ma prawo tylko czytać dane, tool nie powinien mieć ukrytej możliwości zapisu.

Resources — dane do odczytu przez aplikację

Resource jest identyfikowalnym źródłem kontekstu, na przykład plikiem, dokumentem, schematem bazy, historią zmian lub logiem. Ma URI i może być pobierany przez klienta. W klasyfikacji MCP resources są kontrolowane przez aplikację: host decyduje, kiedy i w jakiej postaci dołączyć je do kontekstu.

Praktyczna różnica między resource a tool jest następująca:

• resource odpowiada na pytanie „jaki kontekst można przeczytać?”;
• tool odpowiada na pytanie „jaką funkcję można wykonać?”.

Granica nie zawsze jest absolutna. Tool może pobrać dane z systemu, a resource może reprezentować dynamiczną zawartość. Najważniejsze jest jawne opisanie semantyki i kontrola dostępu. Samo oznaczenie czegoś jako „read-only” nie zabezpiecza przed serwerem, który w środku wykonuje dodatkowe operacje.

Prompts — szablony wybierane przez użytkownika

Prompts są gotowymi szablonami interakcji. Mogą przyspieszyć powtarzalną pracę, na przykład analizę błędu, przegląd zmian w repozytorium albo przygotowanie streszczenia dokumentu. W modelu MCP prompts są kontrolowane przez użytkownika: host może pokazać je jako pozycje menu, polecenia lub inne elementy interfejsu.

Prompt nie jest polityką bezpieczeństwa. Jeśli serwer dostarcza instrukcję „wyślij wynik do zewnętrznego adresu”, host nie powinien traktować jej jako automatycznej zgody. Wrażliwa operacja nadal wymaga osobnej decyzji, kontroli uprawnień i ewentualnego potwierdzenia.

Dodatkowe możliwości klienta

Nowsze wersje specyfikacji opisują też możliwości po stronie klienta, między innymi roots, sampling i elicitation. Roots pozwalają hostowi przedstawić granice URI lub katalogów, które są objęte zakresem pracy. Sampling pozwala serwerowi poprosić klienta o użycie modelu, ale host powinien kontrolować taką prośbę i jej widoczność. Elicitation służy do poproszenia użytkownika o dodatkowe dane za pośrednictwem hosta.

Są to możliwości opcjonalne i nie każdy host je obsługuje. Nie należy budować założenia, że każdy serwer ma dostęp do modelu, plików lub interakcji z użytkownikiem.

Jak wygląda komunikacja MCP przez JSON-RPC?

MCP używa komunikatów JSON-RPC 2.0. W uproszczeniu klient wysyła żądanie z metodą i parametrami, a serwer odpowiada wynikiem albo błędem. Komunikat z id oczekuje odpowiedzi; powiadomienie nie ma id i nie wymaga odpowiedzi.

Inicjalizacja i negocjacja możliwości

Sesja zaczyna się od initialize. Klient informuje o obsługiwanej wersji, swoich capability i danych implementacji. Serwer odpowiada własną wersją, capability i informacjami o sobie. Następnie klient wysyła powiadomienie notifications/initialized.

Przykład uproszczonego żądania inicjalizacyjnego:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "PrzykladowyHost",
      "version": "1.0.0"
    }
  }
}

Wersja 2025-11-25 jest aktualną wersją specyfikacji wskazywaną przez oficjalną dokumentację na dzień 2026-07-13. Klienci i serwery mogą obsługiwać także wcześniejsze wersje, ale muszą poprawnie negocjować zgodność. W praktyce warto przypinać wersję SDK i testować połączenie po aktualizacji.

Odkrywanie i wywołanie toola

Po inicjalizacji klient może wykonać tools/list, aby pobrać dostępne narzędzia. Następnie host przekazuje ich opisy modelowi w formie właściwej dla danego API modelu. Jeżeli model zwróci żądanie wywołania, klient może wykonać tools/call.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_exchange_rate",
    "arguments": {
      "currency": "USD"
    }
  }
}

Odpowiedź powinna być traktowana jako dane do dalszego przetworzenia, a nie jako nowe instrukcje najwyższego poziomu. Jeżeli wynik zawiera tekst pobrany z internetu, wiadomości lub pliku, może on zawierać prompt injection. Host i aplikacja powinny rozdzielać dane od poleceń.

Błędy, powiadomienia i anulowanie

JSON-RPC nie zakłada, że każde wywołanie zakończy się sukcesem. Serwer może zwrócić błąd walidacji argumentów, błąd autoryzacji, błąd usługi zewnętrznej albo błąd wewnętrzny. Klient powinien pokazać sensowną informację, nie próbować bez końca tego samego wywołania i nie ujawniać sekretów w komunikacie.

MCP przewiduje również powiadomienia o postępie, logowanie, anulowanie i obsługę dłuższych zadań. Nie zwalnia to implementacji z ustawienia limitu czasu. Operacja, która przez błąd sieci trwa bez końca, może zablokować zasoby albo generować koszt.

Transporty: stdio i Streamable HTTP

Transport określa, jak komunikaty trafiają od klienta MCP do serwera MCP. Nie zmienia semantyki tools, resources i prompts, ale zmienia profil operacyjny i bezpieczeństwa. Specyfikacja opisuje transporty, lecz nie gwarantuje bezpiecznej konfiguracji konkretnego wdrożenia.

stdio i Streamable HTTP są transportami MCP. Dla zdalnego HTTP autoryzacja może być używana jako opcjonalny profil MCP/OAuth; lokalne stdio nie wymaga OAuth, ale nadal wymaga kontroli procesu, dostępu do plików, sieci i danych. O tym, czy potrzebne są TLS, limity, monitoring lub dodatkowe zgody, decyduje topologia i threat model konkretnej implementacji.

stdio dla lokalnego procesu

W transporcie stdio host uruchamia serwer jako proces potomny. Serwer czyta komunikaty z stdin i zapisuje odpowiedzi do stdout. To wygodne w lokalnych narzędziach deweloperskich i aplikacjach desktopowych, bo nie wymaga publicznego endpointu HTTP.

Ważna pułapka: lokalny serwer stdio nie może zapisywać zwykłych logów do stdout, bo pomieszałby je z komunikatami JSON-RPC. Logi powinny trafiać do stderr albo do pliku. Lokalność transportu nie jest równoznaczna z pełną prywatnością: proces może mieć dostęp do sieci, może czytać pliki, a host może wysyłać wynik do zewnętrznego modelu.

Streamable HTTP dla usługi zdalnej

Aktualna specyfikacja opisuje Streamable HTTP jako transport używający jednego endpointu HTTP, żądań POST i opcjonalnie Server-Sent Events. Starszy transport HTTP+SSE z wersji 2024-11-05 jest oznaczony jako historyczny/deprecjonowany w dokumentacji transportów. Zdalny serwer może obsługiwać wiele połączeń i lepiej pasuje do usługi wdrażanej na serwerze, ale wymaga pełnej administracji HTTP.

Przy lokalnym HTTP praktyka wdrożeniowa powinna obejmować wiązanie serwera z 127.0.0.1, a nie z każdym interfejsem, walidację nagłówka Origin i ochronę endpointu przed DNS rebinding. W środowisku zdalnym zwykle potrzebne są między innymi TLS, kontrola sesji, limity żądań, monitorowanie i polityka wygasania tokenów.

MCP a function calling, RAG i API

MCP często jest mylone z innymi elementami stosu AI. Najprościej rozdzielić warstwy.

MCP a function calling

Function calling jest mechanizmem konkretnego API modelu: model zwraca ustrukturyzowaną prośbę o wywołanie funkcji, a aplikacja ją wykonuje. MCP jest protokołem między aplikacją a serwerem możliwości. Host może używać function calling, aby model wybrał tool MCP, a następnie klient MCP wyśle tools/call do serwera.

Zatem MCP nie usuwa function calling. Łączy je z odkrywaniem narzędzi, negocjacją capability, transportem, zasobami i innymi elementami sesji. Jeśli aplikacja ma jedną funkcję i jednego dostawcę modelu, bezpośrednie function calling może być prostsze. MCP ma większy sens, gdy potrzebujesz współdzielenia integracji między hostami lub oddzielenia procesu dostarczającego narzędzia.

MCP a RAG

RAG odpowiada na problem dostarczenia modelowi relewantnych fragmentów wiedzy. MCP odpowiada na problem standardowego dostępu do narzędzi i kontekstu. Serwer MCP może wystawić search_documents, ale sposób wyszukiwania, ranking, embeddingi i polityka retencji nadal należą do implementacji.

Jeśli chcesz uporządkować proces wyszukiwania kontekstu, przydatny będzie tekst jak działa RAG w pięciu krokach. MCP może być w nim interfejsem do retrievera, lecz nie gwarantuje jakości trafień ani poprawności odpowiedzi modelu.

MCP a zwykłe API

REST, GraphQL czy gRPC są interfejsami dla programów i programistów. MCP może opakować istniejące API w opis narzędzi, zasobów i sesji zrozumiały dla hosta AI. Nie oznacza to, że każde API warto wystawiać bezpośrednio modelowi. Zwykle potrzebna jest wąska warstwa pośrednia, która waliduje argumenty, ukrywa sekrety, ogranicza zakres danych i normalizuje błędy.

Przykład: prosty serwer MCP w Pythonie

Poniższy przykład jest demonstracyjny. Wystawia tylko narzędzie odczytujące ostatni dostępny kurs średni z publicznego API Narodowego Banku Polskiego. Nie zapisuje danych i nie wykonuje operacji finansowej. Używa wzorca FastMCP opisywanego w oficjalnym tutorialu Python SDK.

from __future__ import annotations

import re

import httpx
from mcp.server.fastmcp import FastMCP


mcp = FastMCP("nbp-rates")
NBP_URL = "https://api.nbp.pl/api/exchangerates/rates/a/{code}/?format=json"


@mcp.tool()
def get_exchange_rate(currency: str = "USD") -> str:
    """Zwróć ostatni dostępny kurs średni waluty z tabeli A NBP."""
    code = currency.strip().upper()
    if not re.fullmatch(r"[A-Z]{3}", code):
        raise ValueError("Kod waluty musi mieć trzy litery, np. USD albo EUR.")

    url = NBP_URL.format(code=code)
    with httpx.Client(timeout=10.0) as http_client:
        response = http_client.get(url)
        response.raise_for_status()
        payload = response.json()

    rate = payload["rates"][0]
    return (
        f"{payload['currency']} ({payload['code']}): "
        f"{rate['mid']} PLN, data tabeli: {rate['effectiveDate']}"
    )


if __name__ == "__main__":
    # W stdio stdout jest zarezerwowane dla komunikatów protokołu.
    mcp.run(transport="stdio")

Możliwe uruchomienie w środowisku z uv wygląda tak:

uv run --with mcp --with httpx nbp_server.py

Konfiguracja hosta jest zależna od aplikacji. W uproszczonym pliku konfiguracyjnym hosta może znaleźć się wpis podobny do tego:

{
  "mcpServers": {
    "nbp-rates": {
      "command": "uv",
      "args": [
        "run",
        "--with", "mcp",
        "--with", "httpx",
        "C:/sciezka/nbp_server.py"
      ]
    }
  }
}

To nie jest uniwersalny format konfiguracyjny każdego hosta. Przed użyciem trzeba sprawdzić dokumentację konkretnej aplikacji, ścieżkę do interpretera i sposób instalacji zależności. Dla produkcji należy dodać walidację odpowiedzi NBP, kontrolę błędów, retry z limitem, cache, metryki oraz testy kontraktowe. W przykładzie prostota jest ważniejsza niż kompletność wdrożeniowa.

Co dzieje się po wysłaniu pytania?

Przebieg może wyglądać tak:

1. Host uruchamia nbp_server.py i tworzy klienta MCP.
2. Klient i serwer wykonują initialize oraz negocjują capability.
3. Host pobiera listę tooli przez tools/list.
4. Model otrzymuje opis get_exchange_rate i pytanie użytkownika.
5. Model proponuje wywołanie z argumentem USD.
6. Host może pokazać operację użytkownikowi i przekazać ją do klienta MCP.
7. Serwer odpytuje NBP i zwraca tekstowy wynik.
8. Host dołącza wynik do kontekstu modelu, który formułuje odpowiedź.

Na żadnym etapie MCP nie „wie”, czy model poprawnie zinterpretował pytanie. To odpowiedzialność hosta, modelu, walidacji i testów aplikacji.

Bezpieczeństwo MCP: co trzeba kontrolować?

MCP pozwala łączyć model z działającym kodem i danymi. Z tego powodu należy traktować serwer podobnie jak nową integrację programistyczną, a nie jak niewinny plik konfiguracyjny. Oficjalna specyfikacja podkreśla zgodę użytkownika, kontrolę danych i ostrożność wobec tooli, ale sam protokół nie wymusza całego modelu bezpieczeństwa. Poniższa lista jest praktyką inżynieryjną i checklistą ryzyka, a nie kompletnym audytem ani certyfikacją.

Zasada najmniejszych uprawnień

Serwer powinien mieć tylko te uprawnienia, które są potrzebne do zadania. Dla asystenta czytającego dokumenty preferuj zakres tylko do odczytu i konkretny katalog. Dla integracji z pocztą nie dawaj prawa wysyłania wiadomości, jeśli potrzebne jest tylko streszczenie. Dla API używaj osobnych tokenów, wąskich scope’ów i krótkiego czasu życia.

Nie polegaj na tym, że model sam „zrozumie”, iż nie wolno mu usunąć pliku. Zakaz powinien być wymuszony w serwerze i systemie docelowym. Polityka może blokować operację przed jej wykonaniem, a użytkownik może zatwierdzać czynności nieodwracalne.

Prompt injection i nieufne dane

Treść pobrana z dokumentu, strony internetowej, issue albo wiadomości e-mail może zawierać instrukcję skierowaną do modelu. To przykład indirect prompt injection. Wynik narzędzia powinien być traktowany jako dane, nie jako polecenie zmieniające zasady aplikacji.

Praktyczne zabezpieczenia to ograniczenie źródeł, filtrowanie danych, rozdzielenie instrukcji systemowych od wyników, walidacja wyników, blokowanie wyjścia do nieautoryzowanych miejsc oraz potwierdzenie przed operacją skutkującą zmianą stanu. Żadne pojedyncze filtrowanie tekstu nie daje pełnej gwarancji.

Tokeny, OAuth i zdalne serwery

Dla zdalnego HTTP autoryzacja MCP jest opcjonalnym profilem transportowym; jeśli jest używana, implementacja powinna stosować wymagania profilu MCP/OAuth, w tym HTTPS, PKCE po stronie klienta, walidację audience, bezpieczne przechowywanie tokenów i minimalne scope’y. Sam protokół nie zastępuje autoryzacji systemu downstream. Serwer MCP nie powinien przekazywać bez sprawdzenia tokenu otrzymanego od klienta do innego API; jeśli łączy się z usługą downstream, powinien używać właściwych, odrębnych poświadczeń.

W praktyce szczególnie niebezpieczne są tokeny zapisane w logach, tokeny o zbyt szerokim zakresie oraz brak rozróżnienia użytkowników. Sam fakt, że endpoint działa za loginem, nie dowodzi, że każda operacja jest autoryzowana dla konkretnego użytkownika.

Lokalne serwery i DNS rebinding

Lokalny proces może mieć szeroki dostęp do plików i środowiska uruchomieniowego. Instaluj serwery z zaufanych źródeł, przypinaj wersje zależności, przeglądaj kod i uruchamiaj je w ograniczonym środowisku. Przy lokalnym HTTP wiąż usługę wyłącznie z localhostem i waliduj Origin. Przy wdrożeniu sieciowym dodaj firewall, TLS, uwierzytelnianie i monitoring.

Stwierdzenie „to działa lokalnie, więc jest bezpieczne” jest zbyt mocne. Lokalny serwer może odczytywać poufne pliki, a model zdalny może otrzymać wynik tej operacji. Zanim połączysz MCP z prywatnymi danymi, sprawdź, gdzie są przetwarzane prompty, wyniki narzędzi, logi i kopie zapasowe oraz jakie są zasady retencji dostawcy hosta i modelu.

Audyt i zgoda użytkownika

Dla każdej operacji warto rejestrować: identyfikator użytkownika, host, serwer, nazwę toola, wersję, zakres uprawnień, czas, wynik walidacji i status wykonania. Nie zapisuj bez potrzeby pełnych sekretów ani wrażliwych treści. Log powinien pomagać odtworzyć zdarzenie, ale sam nie może stać się nowym miejscem wycieku.

Zgoda powinna być konkretna. „Zezwól serwerowi na wszystko” jest trudne do zrozumienia i audytu. Lepszy jest komunikat „Pozwól odczytać pliki z katalogu X” albo „Pozwól utworzyć szkic, ale nie wysyłać wiadomości”.

Zastosowania MCP

MCP jest przydatne tam, gdzie aplikacja AI ma korzystać z kilku zewnętrznych możliwości, a zespół chce rozdzielić model od integracji.

Praca z dokumentami i wiedzą wewnętrzną

Serwer może udostępniać listę dokumentów, metadane, wybrane zasoby i narzędzie wyszukiwania. Host może pokazać modelowi tylko dokumenty, do których użytkownik ma uprawnienia. To dobre miejsce na połączenie z systemem RAG, ale kontrola dostępu musi być sprawdzona przed pobraniem treści, a nie dopiero po wygenerowaniu odpowiedzi.

Programowanie

Serwer repozytorium może udostępnić strukturę projektu, historię zmian, issue i testy. Operacja zapisu powinna być oddzielona od odczytu, ograniczona do wybranego workspace’u i poprzedzona podglądem diffu. Narzędzie uruchamiające polecenia systemowe wymaga dodatkowej izolacji, limitów czasu i listy dozwolonych komend.

Dane publiczne i analityka

W polskim kontekście przykładowym źródłem może być API NBP, GUS lub inna usługa publiczna. Serwer MCP może normalizować odpowiedź i podać ją modelowi w stabilnym formacie. Nie powinien jednak tworzyć wrażenia, że wynik z publicznego API jest poradą inwestycyjną, prawną albo podatkową. W obszarach takich jak ocena zdolności kredytowej z użyciem AI trzeba dodatkowo kontrolować jakość danych, podstawę decyzji, prywatność i udział człowieka.

Obsługa klienta i operacje

MCP może połączyć asystenta z bazą wiedzy, systemem ticketowym i statusem zamówienia. Najbezpieczniejszy początek to odczyt i przygotowywanie szkiców. Zmiana adresu, zwrot pieniędzy, zamknięcie konta lub wysłanie wiadomości powinny przechodzić przez wyraźne zatwierdzenie i reguły systemu biznesowego.

Ograniczenia MCP

MCP nie rozwiązuje wszystkich problemów aplikacji AI.

Standard nie daje gwarancji przenośności

Host może obsługiwać inne capability niż serwer. Wersje specyfikacji i SDK mogą się różnić. Nie każdy host wspiera roots, sampling, elicitation, zadania długotrwałe czy ten sam mechanizm zgód. Przed deklaracją „działa z każdym klientem MCP” potrzebne są testy na konkretnych hostach.

Więcej narzędzi nie zawsze znaczy lepiej

Jeśli model dostanie dziesiątki podobnych tooli, rośnie ryzyko złego wyboru, większego promptu i trudniejszego debugowania. Grupuj funkcje według domen, stosuj nazwy jednoznaczne, zwracaj krótkie i przydatne wyniki oraz usuwaj nieużywane integracje. W małej aplikacji bez potrzeby współdzielenia integracji bezpośrednie API może być prostsze.

Koszt, opóźnienie i awarie

Discovery, negocjacja sesji, wywołania zewnętrznych API i kolejne kroki modelu zwiększają czas odpowiedzi. Zdalny serwer dodaje zależność sieciową. Potrzebujesz timeoutów, retry z backoffem, idempotencji, limitów i obsługi częściowej awarii. Narzędzie nie powinno być wywoływane ponownie tylko dlatego, że klient nie dostał odpowiedzi, jeśli pierwsza operacja mogła już zmienić stan.

MCP nie jest samodzielnym agentem

Serwer MCP nie planuje zadań tylko dlatego, że udostępnia tool. Pętla model–narzędzie–wynik należy do hosta lub frameworka agentowego. To host decyduje, czy model może wykonać jedno wywołanie, czy wiele kroków. Różnicę między asystentem odpowiadającym na pytanie a systemem wykonującym serię operacji omawia tekst agenci AI vs chatboty.

Jak zacząć wdrożenie MCP?

Rozsądny proces można zamknąć w kilku etapach:

1. Zdefiniuj zadanie. Opisz, co ma być odczytywane lub wykonywane i czego system nie potrzebuje.
2. Zacznij od odczytu. Pierwszy serwer najlepiej nie zmienia stanu i nie przechowuje sekretów.
3. Wąsko zaprojektuj tools. Jeden tool powinien mieć jasny cel, typowane argumenty i przewidywalny wynik.
4. Ustal granice danych. Określ katalogi, rekordy, użytkowników, regiony i zakres czasowy.
5. Wybierz transport. Dla lokalnego prototypu często wystarczy stdio; dla usługi zdalnej potrzebujesz HTTP i pełnego modelu autoryzacji.
6. Dodaj testy negatywne. Sprawdź brak uprawnień, zły argument, timeout, duży wynik, złośliwą treść i powtórzenie żądania.
7. Włącz obserwowalność. Loguj metadane operacji bez niepotrzebnego kopiowania danych wrażliwych.
8. Wprowadź zgodę. Przed zapisem, wysyłką, usunięciem lub zmianą uprawnień pokaż użytkownikowi konkretny zakres operacji.

Nie zaczynaj od podpinania wszystkich systemów firmy. Zbuduj jeden mały serwer, przetestuj go z jednym hostem, sprawdź przepływ danych i dopiero potem rozszerzaj zakres.

Podsumowanie

Model Context Protocol jest wspólnym językiem łączenia aplikacji AI z narzędziami i kontekstem. Host koordynuje model oraz zgodę użytkownika, klient utrzymuje połączenie jeden do jednego z serwerem, a serwer udostępnia tools, resources i prompts. Komunikaty są oparte na JSON-RPC 2.0, a transport może być lokalnym stdio albo Streamable HTTP.

Największa wartość MCP pojawia się wtedy, gdy wiele aplikacji ma korzystać z tych samych, wąsko zdefiniowanych integracji. Największe ryzyko pojawia się wtedy, gdy standard jest traktowany jak automatyczna gwarancja bezpieczeństwa. MCP nie zatwierdza uprawnień za system biznesowy, nie wykrywa wszystkich prompt injection i nie decyduje, czy wynik modelu jest poprawny. Te odpowiedzialności pozostają po stronie hosta, serwera, systemu docelowego i organizacji.

Nota źródłowa i zakres: Źródła priorytetyzują oficjalną specyfikację MCP, dokumentację dostawców, OWASP/NIST oraz akty i wytyczne urzędowe; linki sprawdzono 2026-07-13. Tekst ma charakter edukacyjny i nie jest audytem bezpieczeństwa, poradą prawną ani potwierdzeniem zgodności z RODO, AI Act lub regulacjami sektorowymi. Kontrole trzeba dopasować do danych, dostawców, threat modelu i konkretnego wdrożenia.