Skąd wziął się MCP i jaki problem rozwiązuje
Anthropic otworzył Model Context Protocol 25 listopada 2024. Założenie było proste: zastąpić wiele niestandardowych integracji jednym otwartym sposobem łączenia asystentów AI z repozytoriami treści, narzędziami biznesowymi i środowiskami deweloperskimi. [1]
W praktyce MCP nie zastępuje bazy danych ani REST API. Serwer MCP stoi nad istniejącym systemem i opisuje możliwości w formie zrozumiałej dla zgodnego hosta AI. [1][4]
Co MCP standaryzuje, a czego nie
MCP standaryzuje sposób odkrywania i wywoływania narzędzi, udostępniania zasobów oraz szablonów promptów. Dzięki temu host nie musi znać prywatnego API każdego systemu z osobna. [4][5][6][7]
Protokół nie definiuje logiki biznesowej serwera, modelu danych aplikacji ani polityki uprawnień konkretnej firmy. Te elementy nadal należą do implementacji. [5][8]
Architektura w praktyce: host, klient i serwer
| Element | Rola |
|---|---|
| Host | Aplikacja AI koordynująca model, użytkownika i połączenia MCP. |
| Klient MCP | Warstwa komunikacji protokołu dla konkretnego serwera. |
| Serwer MCP | Udostępnia możliwości i mapuje je na dane lub systemy zewnętrzne. |
| Tools | Operacje wykonywane przez model. |
| Resources | Dane i kontekst identyfikowane przez URI. |
| Prompts | Wielokrotnego użytku szablony promptów. |
Klasyczny model MCP rozdziela hosta, klienta i serwer. Host to aplikacja AI, klient implementuje komunikację protokołu, a serwer wystawia dane i operacje. W aktualnym wydaniu zachowano ten praktyczny podział odpowiedzialności, ale warstwa protokołu HTTP nie wymaga już utrzymywania sesji między żądaniami. [15][2]
Jeden host może łączyć się z wieloma serwerami MCP, na przykład z GitHubem, systemem zgłoszeń i wewnętrzną bazą wiedzy. To host decyduje, które możliwości udostępnić modelowi i użytkownikowi. [12][15]
Tools, resources i prompts: trzy podstawowe elementy
`Tools` to operacje, które model może wywołać, na przykład wyszukanie zamówienia, utworzenie zgłoszenia albo uruchomienie obliczenia. Specyfikacja określa nazwę narzędzia, opis oraz schemat wejścia. [5]
`Resources` udostępniają dane identyfikowane przez URI, na przykład pliki, schemat bazy lub dokumentację. `Prompts` pozwalają serwerowi udostępniać wielokrotnego użytku szablony promptów. [6][7]
STDIO, Streamable HTTP i stary transport SSE
| Transport | Typowe zastosowanie |
|---|---|
| STDIO | Lokalny proces, CLI, IDE, narzędzia deweloperskie. |
| Streamable HTTP | Zdalny serwer, usługa SaaS, infrastruktura produkcyjna. |
| HTTP+SSE | Stary transport HTTP; deprecated w wydaniu 2026-07-28. |
STDIO jest naturalnym wyborem dla lokalnego serwera uruchamianego jako proces przez aplikację kliencką. Streamable HTTP służy do zdalnych wdrożeń dostępnych przez sieć. [4][2]
W specyfikacji `2026-07-28` zdalny rdzeń jest bezstanowy. Legacy HTTP+SSE został oficjalnie oznaczony jako deprecated i ma co najmniej dwunastomiesięczny okres przejściowy. [2]
Jak wygląda wywołanie narzędzia w aktualnym MCP
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {"q": "invoice 2026"}
}
}Od wydania `2026-07-28` nie ma obowiązkowego `initialize` ani nagłówka `Mcp-Session-Id`. Każde żądanie może nieść wersję protokołu, informacje o kliencie i capabilities, a opcjonalny `server/discover` pozwala sprawdzić możliwości serwera przed wykonaniem operacji. [2]
Dla Streamable HTTP nagłówki `Mcp-Method` i `Mcp-Name` pozwalają gatewayom, WAF-om i limiterom routować oraz mierzyć ruch bez analizowania całego JSON body. [2]
Przykład praktyczny: agent pracujący z systemem zgłoszeń
Załóżmy, że firma ma własny system ticketowy. Serwer MCP może wystawić `search_tickets`, `get_ticket` i `update_ticket` jako tools, dokumentację procesu jako resources oraz gotowy prompt do analizy incydentu. Host AI pobiera katalog możliwości, model wybiera właściwe narzędzie, a serwer mapuje wywołanie na wewnętrzne API. [5][6][7]
Najważniejsza korzyść architektoniczna polega na tym, że ten sam serwer MCP może później obsłużyć różne zgodne hosty bez przepisywania całej integracji dla każdego z nich. [4][12]
Autoryzacja: OAuth 2.1, Bearer tokens i Client ID Metadata Documents
Dla transportów HTTP autoryzacja MCP opiera się na OAuth 2.1 i standardach discovery. Chroniony serwer działa jako resource server, klient MCP jako OAuth client, a token dostępu jest przekazywany w nagłówku `Authorization: Bearer`. Tokenów nie wolno umieszczać w query string. [8]
Specyfikacja wymaga walidacji audience tokena i stosowania PKCE tam, gdzie jest technicznie możliwe. W 2026 Dynamic Client Registration jest formalnie wycofywane na rzecz Client ID Metadata Documents, choć pozostaje wspierane dla kompatybilności. [2][8]
Bezpieczeństwo: MCP nie powinien oznaczać pełnego zaufania
Specyfikacja tools wymaga walidacji wejścia po stronie serwera, kontroli dostępu, ograniczania liczby wywołań i sanitizacji wyników. Klient powinien umożliwiać potwierdzanie operacji wrażliwych, pokazywać argumenty narzędzia, stosować timeouty i prowadzić audyt wywołań. [5]
Najbezpieczniejszy model produkcyjny to najmniejsze potrzebne uprawnienia. Serwer do odczytu dokumentacji nie powinien otrzymywać tokena pozwalającego usuwać dane, a operacje modyfikujące produkcję powinny mieć dodatkową kontrolę. [5][8][13]
MCP Apps: kiedy wynik narzędzia potrzebuje interfejsu
MCP Apps to oficjalne rozszerzenie pozwalające narzędziom zwracać interaktywne interfejsy, na przykład formularz, dashboard albo wizualizację. Narzędzie wskazuje zasób `ui://`, a host może renderować go w sandboxowanym iframe. [9]
Komunikacja UI z hostem pozostaje ustrukturyzowana i audytowalna. Host może wymagać zgody na wywołania narzędzi inicjowane z interfejsu. [9]
Tasks: długie operacje bez trzymania połączenia
MCP Tasks rozwiązuje problem operacji trwających sekundy, minuty lub godziny. Zamiast blokować połączenie, serwer może zwrócić trwały identyfikator zadania, a klient później sprawdza status i pobiera wynik. [10]
Rozszerzenie ma sens dla CI, zadań wsadowych, wdrożeń, zewnętrznych kolejek oraz procesów wymagających zatwierdzenia człowieka. W aktualnym modelu obsługa Tasks wymaga jawnego wsparcia po obu stronach. [10][2]
Adopcja: Anthropic, OpenAI, GitHub i ekosystem deweloperski
OpenAI dodał obsługę zdalnych serwerów MCP do Responses API w maju 2025 i dołączył do komitetu kierującego MCP. [11]
GitHub Copilot obsługuje MCP w wielu powierzchniach, w tym IDE, Copilot CLI, aplikacji Copilot i cloud agent. GitHub rozwija też registry oraz mechanizmy zarządzania i allowlist dla firm. [12][13][14]
MCP vs REST API i function calling
REST API opisuje interfejs systemu dla dowolnego klienta. Function calling opisuje sposób, w jaki konkretny model lub API wywołuje funkcje. MCP dodaje wspólną warstwę discovery, schematów i komunikacji między hostem AI a serwerem narzędzi. [4][5]
Jeśli masz jeden model i trzy proste funkcje we własnym backendzie, MCP może być niepotrzebną warstwą. Jeśli te same możliwości mają działać w wielu hostach albo chcesz udostępnić integrację jako niezależny produkt, MCP zaczyna dawać realną korzyść. [4][11][12]
Checklista produkcyjnego serwera MCP
Wdrożenie produkcyjne powinno zaczynać się od małego, jednoznacznego zestawu narzędzi. Każde narzędzie musi mieć konkretną nazwę, precyzyjny opis, walidowany schema input oraz uprawnienia ograniczone do niezbędnego zakresu. [5][8]
Dla serwera zdalnego warto budować pod aktualny Streamable HTTP, przygotować OAuth, metryki, rate limiting i tracing oraz świadomie zarządzać kompatybilnością ze starszymi klientami. [2][8]
- Projektuj pod specyfikację `2026-07-28`.
- Minimalizuj liczbę narzędzi i zakres ich uprawnień.
- Waliduj wszystkie argumenty i wyniki.
- Wymagaj potwierdzenia dla operacji wrażliwych.
- Dla HTTP wdrażaj poprawny OAuth i audience validation.
- Stosuj rate limiting, timeouty, audit log i tracing.
- Nie przekazuj serwerowi sekretów, których nie potrzebuje.
- Testuj kompatybilność hostów i zachowanie przy błędach.
Co zmieniło się w 2026 i dokąd zmierza MCP
Największa zmiana wydania `2026-07-28` to bezstanowy rdzeń, usunięcie handshake i sesji protokołu, cache dla list, routing nagłówkami, formalny system rozszerzeń i mocniejsze zasady autoryzacji. Roots, Sampling i Logging zostały oznaczone jako deprecated dla nowych implementacji. [2]
Roadmap z sierpnia 2026 wskazuje dalsze prace nad komunikacją agentową, webhookami i zdarzeniami, ujednoliceniem transportu HTTP, tożsamością agentów, bezpieczeństwem firmowym oraz doświadczeniem SDK. To kierunek rozwoju, a nie gotowe funkcje obecnej specyfikacji. [3]
