MCP — Model Context Protocol: pełny przewodnik 2026

Ostatnia aktualizacja: maj 2026

Czym jest Model Context Protocol?

Model Context Protocol (MCP) to otwarty protokół komunikacyjny, który standaryzuje sposób, w jaki aplikacje AI dostarczają kontekst (pliki, bazy danych, API, narzędzia) modelom językowym. Anthropic opublikowało go 25 listopada 2024 roku jako specyfikację MIT na licencji open-source — analogicznie do tego, jak USB-C ujednolicił okablowanie w elektronice, MCP ujednolica „okablowanie” między LLM-em a światem zewnętrznym.

Przed MCP każda integracja modelu z narzędziem była punktowa: deweloper musiał napisać dedykowany kod dla każdej kombinacji „model × narzędzie”. Anthropic w swoim ogłoszeniu nazwał to problemem M×N — dla M modeli i N narzędzi potrzeba M·N integracji. MCP redukuje ten problem do M+N: wystarczy, że każdy model implementuje klienta MCP, a każde narzędzie — serwer MCP.

Jeśli chcesz zrozumieć szerszy kontekst, jak modele językowe rozumieją instrukcje, zacznij od artykułów LLM — czym są duże modele językowe oraz Retrieval-Augmented Generation (RAG). MCP rozwiązuje inny problem niż RAG — nie chodzi o wyszukiwanie w wektorowej bazie wiedzy, lecz o strukturalne wywoływanie narzędzi i kontrolowane udostępnianie danych modelowi.

Skąd wzięło się MCP i dlaczego powstało?

Pomysł narodził się wewnątrz Anthropic w 2024 roku jako odpowiedź na konkretną frustrację: zespoły inżynierskie pisały te same integracje dziesiątki razy. Kiedy Claude potrzebował dostępu do GitHuba, ktoś pisał wrapper. Kiedy ten sam GitHub miał trafić do innego asystenta — wrapper trzeba było pisać od nowa, w innym formacie. Każdy producent modelu miał swoje API function calling, a każdy zespół developerski rozwiązywał ten sam problem osobno.

Justin Spahr-Summers i David Soria Parra, główni inżynierowie projektu w Anthropic, zaprojektowali MCP wzorując się na Language Server Protocol (LSP) stworzonym przez Microsoft w 2016 roku. LSP rozwiązał identyczny problem dla edytorów kodu — zamiast pisać wsparcie dla każdego języka programowania w każdym IDE osobno, wystarczy raz napisać language server i raz language client. MCP przenosi tę logikę do świata AI.

Jak działa architektura MCP — host, klient, serwer?

MCP definiuje trzy role uczestników komunikacji. Każda ma jasno określoną odpowiedzialność i granice — to świadomy projekt bezpieczeństwa, nie przypadek.

Host — aplikacja AI

Host to aplikacja, w której pracuje użytkownik: Claude Desktop, Claude Code, Cursor, Windsurf, ChatGPT Desktop, Zed Editor, Microsoft Copilot Studio. Host odpowiada za orkiestrację: decyduje, którzy klienci są aktywni, zarządza autoryzacją użytkownika („czy zgadzasz się, by Claude odczytał te pliki?”) i prezentuje wyniki w UI. Host jest jedyną warstwą, która ma bezpośredni kontakt z modelem językowym.

Klient (Client) — łącznik 1:1 z serwerem

Klient to lekki komponent wewnątrz hosta. Każdy klient utrzymuje dokładnie jedno połączenie z jednym serwerem MCP. Jeśli host ma podpięte trzy serwery (np. filesystem, GitHub, PostgreSQL), działają w nim trzy niezależne instancje klienta. Klient zarządza protokołem JSON-RPC, negocjuje wersję, obsługuje retry, timeouts i przekazuje wiadomości w obie strony.

Serwer (Server) — udostępnia narzędzia i dane

Serwer MCP to samodzielny proces, który eksponuje funkcjonalności według specyfikacji. Może działać lokalnie (komunikacja przez stdio, czyli standardowe wejście/wyjście procesu) lub zdalnie (HTTP + Server-Sent Events). Serwer nie wie nic o modelu LLM — odpowiada tylko na zapytania protokołu. Tę separację zaprojektowano celowo: serwer GitHub można podpiąć pod Claude, GPT, Gemini lub własny model bez żadnych zmian.

Trzy prymitywy MCP — tools, resources, prompts

Specyfikacja definiuje trzy fundamentalne typy zawartości, które serwer może udostępnić. Zrozumienie różnicy między nimi to klucz do prawidłowego projektowania serwera.

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

To najbliższy odpowiednik klasycznego function calling. Tool to akcja: „wyślij wiadomość”, „uruchom zapytanie SQL”, „utwórz plik”, „pobierz cenę akcji”. Każdy tool ma JSON Schema opisujący argumenty i zwraca wynik strukturalny. Model decyduje, kiedy użyć tooli, ale wykonanie zawsze wymaga zgody (host pyta użytkownika lub stosuje politykę „auto-approve” dla zaufanych operacji).

{
  "name": "search_repositories",
  "description": "Szuka repozytoriów na GitHubie po słowach kluczowych.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Fraza wyszukiwania" },
      "limit": { "type": "integer", "default": 10, "maximum": 100 }
    },
    "required": ["query"]
  }
}

Resources — kontekst tylko-do-odczytu

Resource to dane, które serwer udostępnia modelowi do przeczytania: zawartość pliku, wiersz z bazy danych, strona z wiki, log z monitoringu. Resource ma URI (np. file:///home/user/notes.md albo github://repo/issue/123) i jest pasywny — model nie zmienia stanu, tylko czyta. To różni go od toola: tool wykonuje, resource dostarcza.

Prompts — szablony interakcji

Prompts to gotowe szablony wiadomości, które serwer udostępnia użytkownikowi przez UI. W Claude Desktop pojawiają się jako slash-commands (np. /git-commit, /explain-error). Serwer GitHub może dostarczyć prompt „przeanalizuj ten PR” z pre-fillowanymi placeholderami. To sposób na dystrybucję sprawdzonych wzorców promptowania razem z serwerem.

Protokół warstwowy — jak wygląda komunikacja na drucie?

Wszystkie wiadomości MCP są zakodowane w JSON-RPC 2.0 — sprawdzonym, prostym standardzie z 2010 roku. Każda wiadomość ma jeden z trzech typów:

• Request — pyta o coś i oczekuje odpowiedzi (np. tools/list, tools/call)
• Response — zawiera wynik lub błąd dla konkretnego requestu (matchowane po id)
• Notification — wiadomość bez ID, bez odpowiedzi (np. notifications/progress, gdy serwer raportuje postęp długiej operacji)

Sesja MCP zaczyna się od fazy initialize, w której klient i serwer wymieniają informacje o swoich możliwościach (capabilities). Klient ogłasza, jakie typy treści potrafi przyjąć (np. tylko tekst, tekst + obrazy, sampling itd.); serwer zwraca, jakie ma tools, resources i prompts. Dopiero po wymianie capabilities sesja jest „aktywna” i można wołać tools.

// → klient do serwera
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "clientInfo": { "name": "claude-desktop", "version": "0.9.0" },
    "capabilities": { "sampling": {}, "roots": { "listChanged": true } }
  }
}

// ← serwer do klienta
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "serverInfo": { "name": "mcp-server-github", "version": "1.4.0" },
    "capabilities": { "tools": {}, "resources": { "subscribe": true } }
  }
}

Transport — stdio kontra HTTP+SSE

MCP definiuje dwa standardowe transporty. stdio (standard input/output) jest dla serwerów lokalnych — host uruchamia serwer jako podproces i komunikuje się przez jego strumienie stdin/stdout. Plus: zerowa konfiguracja sieciowa, izolacja procesowa, naturalne uprawnienia systemu plików. Minus: jeden serwer obsługuje jednego klienta, działa tylko lokalnie.

HTTP+SSE (od marca 2025 zastąpione przez Streamable HTTP) jest dla serwerów zdalnych — wieloklientowych, działających w chmurze, autoryzowanych przez OAuth 2.1. Serwer HTTP MCP może obsługiwać dziesiątki klientów jednocześnie i wystawiać tools korporacyjne (np. wewnętrzny CRM firmy).

MCP a function calling — jaka jest różnica?

To pytanie pada najczęściej. Krótka odpowiedź: function calling jest mechanizmem modelu, MCP jest protokołem aplikacji. Nie konkurują — uzupełniają się.

Kiedy Claude lub GPT „wywołuje funkcję”, chodzi o to, że model w odpowiedzi generuje strukturalny JSON typu „chcę wywołać funkcję X z argumentami Y”. To capability modelu. MCP odpowiada na pytanie: „skąd model w ogóle wie, że istnieje funkcja X i jak ją zarejestrować w aplikacji?”. MCP standaryzuje sposób, w jaki aplikacja dostarcza modelowi listę dostępnych funkcji oraz wykonuje je po stronie zewnętrznych systemów.

W praktyce: tool MCP wywołany przez Claude’a używa pod maską mechanizmu function calling Claude’a. Tool ten sam wywołany przez ChatGPT (od marca 2025 OpenAI dodało wsparcie MCP w Agents SDK) używa function calling OpenAI. Serwer MCP nie zmienia się — protokół tłumaczy.

Praktyczny przykład — minimalistyczny serwer MCP w Pythonie

Anthropic udostępnia oficjalne SDK w Pythonie (mcp) i TypeScript (@modelcontextprotocol/sdk). Poniżej działający serwer w 25 liniach — eksponuje jeden tool, który zwraca aktualny kurs USD/PLN z otwartego API NBP.

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("nbp-rates")

@mcp.tool()
async def get_usd_pln() -> dict:
    """Zwraca aktualny kurs USD/PLN z NBP (tabela A)."""
    url = "https://api.nbp.pl/api/exchangerates/rates/A/USD/?format=json"
    async with httpx.AsyncClient() as client:
        r = await client.get(url, timeout=5)
        r.raise_for_status()
        data = r.json()
    return {
        "currency": "USD/PLN",
        "rate": data["rates"][0]["mid"],
        "date": data["rates"][0]["effectiveDate"],
        "source": "NBP tabela A"
    }

if __name__ == "__main__":
    mcp.run(transport="stdio")

Po zarejestrowaniu w Claude Desktop (plik claude_desktop_config.json) Claude może odpowiadać na pytanie „jaki jest kurs dolara?” wywołując ten tool i cytując realne dane NBP zamiast halucynować kurs sprzed roku z danych treningowych.

Bezpieczeństwo i kontrola — co dokładnie widzi model?

MCP zostało zaprojektowane z założeniem, że użytkownik kontroluje, co model robi. To nie jest deklaratywna obietnica — to wbudowane w architekturę.

• Host pośredniczy — model nie ma bezpośredniego dostępu do żadnego serwera. Każde wywołanie tool przechodzi przez warstwę autoryzacyjną hosta.
• Approval per call — domyślnie Claude Desktop pyta przed każdym wywołaniem narzędzia destrukcyjnego (write, delete, run). Użytkownik widzi argumenty.
• Roots — host deklaruje serwerowi, jakie ścieżki/zasoby są w ogóle dostępne (np. „masz dostęp do ~/Documents/projekt, nic poza tym”).
• Sandbox per serwer — w stdio każdy serwer to osobny proces z własnymi uprawnieniami systemu.
• OAuth 2.1 dla zdalnych — od specyfikacji 2025-03-26 serwery HTTP wymagają standardowej autoryzacji.

Ekosystem MCP w 2026 — kto wdrożył, co istnieje?

Adopcja MCP w pierwszym roku przekroczyła oczekiwania nawet samego Anthropica. Stan na maj 2026:

• Anthropic — Claude Desktop (od grudnia 2024), Claude Code (od lutego 2025), Claude.ai (od kwietnia 2025 dla Pro/Team)
• OpenAI — Agents SDK (marzec 2025), ChatGPT Desktop wspiera serwery MCP od czerwca 2025
• Microsoft — Copilot Studio (kwiecień 2025), VS Code GitHub Copilot Agent Mode (lipiec 2025)
• Google — Gemini Code Assist (sierpień 2025), Vertex AI Agents (listopad 2025)
• IDE / dev tools — Cursor, Windsurf, Zed, JetBrains AI Assistant, Replit Agent
• Liczba publicznych serwerów — > 8 000 (rejestr mcp.so, kwiecień 2026), w tym oficjalne od GitHub, Cloudflare, Stripe, Notion, Linear, Slack, Sentry, Atlassian

Dla porównania, w listopadzie 2024 (premiera) istniało 9 referencyjnych serwerów napisanych przez Anthropic. Krzywa wzrostu jest charakterystyczna dla protokołu open-source z silnym pierwszym implementatorem — analogicznie do tego, jak Kubernetes rozprzestrzenił się po opublikowaniu przez Google w 2014.

MCP w polskim kontekście — gdzie to ma sens?

W Polsce dyskusja o MCP jest jeszcze niszowa — protokół pojawia się głównie w środowisku deweloperskim (kanały Discord polskich AI engineerów, Pyrkon AI 2026). Realne zastosowania, które już widzę u zespołów, z którymi pracuję:

• Integracja z polskim API publicznym — serwery MCP wokół API NBP (kursy, stopy), KNF (rejestr pośredników), GUS (BDL — Bank Danych Lokalnych), CEIDG, KRS. Szczególnie sensowne dla asystentów dla biur rachunkowych i kancelarii.
• Dziedzinowi asystenci medyczni i prawniczy — serwer MCP eksponujący wewnętrzną bazę dokumentacji firmy razem z modelem (Claude / GPT) zachowując dane on-prem. To różnica względem klasycznego RAG: kontrola dostępu jest deklaratywna, audytowalna, a nie wbudowana w pipeline embeddingowy.
• Rynki finansowe — w środowisku tradingowym (CFD, akcje) MCP pozwala podpiąć model do TradingView, broker API, kalendarza makro Bankier.pl. Ze swojego doświadczenia handlu CFD na Plus500 metodologią Smart Money Concepts wiem, że automatyzacja czytania kontekstu makro (decyzje RPP, dane GUS) przed sesją jest realnie wartościowa — i MCP zdejmuje pracę z budowy custom integracji.

Ten serwis (DTF Brain) sam korzysta z dedykowanego serwera MCP do publikacji artykułów na WordPress — model widzi narzędzia post_create, post_update, seo_update i resolve_tags, zamiast wymagać ode mnie ręcznego klikania w edytorze. To pokazuje praktyczny use case poza biznesem korporacyjnym.

MCP a regulacje — EU AI Act i wymogi audytowalności

EU AI Act (rozporządzenie 2024/1689, w pełni wymagające od sierpnia 2026) nakłada na systemy wysokiego ryzyka obowiązek logowania i traceability decyzji AI. MCP — przez to, że każde wywołanie toola jest jawnym, ustrukturyzowanym requestem JSON-RPC — naturalnie wspiera te wymagania. Host może zapisywać każde wywołanie z timestampem, argumentami i wynikiem, tworząc audit trail wymagany w sektorach regulowanych (banki, ubezpieczenia, ochrona zdrowia).

Dla porównania — w klasycznym wywołaniu RAG, gdzie LLM dostaje surowy kontekst tekstowy z bazy wektorowej, audytowanie „co model widział i co z tego wynikło” jest znacznie trudniejsze. Powiązany temat to ocena zdolności kredytowej z AI, gdzie wymóg explainability łączy się z wymogiem audytowalności.

Ograniczenia i krytyka MCP

Protokół nie jest panaceum. Najczęstsze zarzuty z 2026 roku:

• Brak agnostyczności modelu w praktyce — choć protokół jest otwarty, najlepiej dopracowane SDK i hosty pochodzą z Anthropic. Pierwsza implementacja zawsze działa najlepiej z Claudem.
• Bezpieczeństwo serwerów społecznościowych — niski próg wejścia oznacza ryzyko złośliwych pakietów (już zaobserwowane w npm i PyPI w 2025).
• Latencja — handshake i discovery dodają kilkadziesiąt do kilkuset milisekund per sesja. Dla aplikacji real-time (głos) to często za dużo.
• Brak natywnego streamingu wyników — odpowiedzi tools są jednorazowe; długie operacje (np. budowanie projektu) wymagają obejścia przez notifications/progress.
• Skomplikowanie dla prostych use case — jeśli aplikacja ma jedno narzędzie i jednego użytkownika, MCP to overkill względem zwykłego function calling.

Podsumowanie

Model Context Protocol nie wynalazł niczego radykalnie nowego — wziął sprawdzony wzorzec z Language Server Protocol i przeniósł go na grunt aplikacji AI. To, co go wyróżnia, to timing: pojawił się dokładnie wtedy, gdy ekosystem narzędzi AI eksplodował i każdy zespół niezależnie pisał te same integracje. W ciągu 18 miesięcy MCP stało się de facto standardem łączenia LLM-ów ze światem zewnętrznym, wdrożonym przez wszystkich dużych dostawców i tysiące zespołów open-source.

Dla deweloperów polskich praktyczna konkluzja jest prosta: jeśli budujesz aplikację AI w 2026 i potrzebujesz, by model coś robił (a nie tylko gadał), zaczynaj od MCP zamiast pisać własną abstrakcję. Krzywa nauki jest płaska, SDK są dojrzałe, a inwestycja w serwer MCP wartość zachowuje przez wszystkich klientów (Claude, GPT, Gemini), nie tylko jednego.

Pełna wersja angielska tego artykułu, bardziej skoncentrowana na ekosystemie deweloperskim, znajduje się w sekcji What is MCP — Model Context Protocol.