Strona główna / Rozdział 5 · Agenci
Ostatnia zmiana · 9 min czytania
MCP
MCP (Model Context Protocol) to otwarty standard podłączania narzędzi i danych do aplikacji z modelem. Integrację piszesz raz jako serwer MCP i używasz jej w Claude, ChatGPT, IDE czy własnym agencie. Model o MCP nic nie wie: nadal widzi definicje narzędzi w prompcie i wypisuje wywołania.
Po ludzkuGniazdko w ścianie. Producent czajnika nie zna twojej instalacji, a elektryk nie zna czajnika: wystarczy wspólny kształt wtyczki. Gniazdko nie sprawdza jednak, co do niego wkładasz, więc za podłączenie wadliwego sprzętu odpowiadasz ty.
Podłączaj serwery MCP i patrz, co trafia do kontekstu modelu, zanim użytkownik cokolwiek napisze
Definicje w prompcie, czyli to, co czyta model. Narzędzia oznaczone „zapis” zmieniają dane.
GitHub według przykładu Anthropic: 35 narzędzi, ok. 26 tys. tokenów (z listy pokazujemy kilka). Pozostałe serwery i system prompt są poglądowe. Host ładuje tu wszystkie definicje z góry. Koszt przy 3 USD za milion tokenów wejścia, bez prompt cachingu (trafienie w cache kosztuje ok. jednej dziesiątej).
Po co standard: M + N zamiast M × N
- Bez standardu każda aplikacja z modelem pisze własną integrację z każdym systemem: M aplikacji i N systemów to M × N integracji. Z MCP system dostaje jeden serwer, a aplikacja jeden klient, więc wystarczy M + N. Anthropic opublikował MCP w listopadzie 2024, a w grudniu 2025 przekazał go do Agentic AI Foundation przy Linux Foundation, więc standard nie należy do jednego dostawcy.
- MCP standaryzuje stronę aplikacji: jak znaleźć narzędzia serwera (
tools/list) i jak je wywołać (tools/call). Strona modelu się nie zmienia. Host zamienia definicje z serwera na zwykłe narzędzia w API modelu, model wypisuje wywołanie, a host przekazuje je właściwemu serwerowi i oddaje wynik. Sam mechanizm opisuje temat „Narzędzia (function calling)”. - MCP łączy agenta z narzędziami i danymi, A2A (Agent2Agent, stworzony przez Google, od czerwca 2025 projekt Linux Foundation) łączy agentów ze sobą. Agent A2A publikuje Agent Card ze swoimi umiejętnościami, a inny agent zleca mu zadanie i dostaje statusy i artefakty, nie widząc jego narzędzi ani promptu. Stan na wrzesień 2026: ponad 150 wspierających organizacji i integracje w platformach agentowych Google, Microsoftu i AWS, ale bez publicznych danych o użyciu. Subagenci w jednej aplikacji go nie potrzebują (temat „Wielu agentów”). A2A opłaca się, gdy drugi agent należy do innego zespołu albo dostawcy.
Host, klient, serwer
- Host to aplikacja z modelem, np. Claude Desktop, IDE albo twój agent. Dla każdego serwera tworzy osobnego klienta i to host decyduje, co trafia do modelu. Serwer nie widzi rozmowy ani innych serwerów, dostaje tylko skierowane do siebie wywołania. Wiadomości to JSON-RPC 2.0 w jednym z dwóch transportów: stdio, gdy host uruchamia serwer jako lokalny proces i rozmawia z nim przez stdin i stdout, albo Streamable HTTP dla serwerów zdalnych, gdzie każda wiadomość to POST na jeden adres.
- Serwer wystawia trzy rodzaje rzeczy, różniące się tym, kto decyduje o użyciu. Narzędzia (tools) wybiera model. Zasoby (resources), np. plik albo schemat bazy, dołącza do kontekstu aplikacja. Prompty (prompts), czyli gotowe szablony, wybiera użytkownik, zwykle jako polecenie z ukośnikiem. W drugą stronę serwer może w trakcie wywołania poprosić użytkownika o dane albo zgodę (elicitation): formularzem, a przy hasłach i płatnościach linkiem otwieranym poza aplikacją. Sampling (serwer prosi model hosta o odpowiedź), roots (host wskazuje katalogi) i logowanie na poziomie protokołu są od wersji 2026-07-28 przestarzałe. Działają jeszcze co najmniej 12 miesięcy, a zastępują je bezpośrednie wywołania API dostawcy, parametry narzędzi oraz stderr albo OpenTelemetry. Opcjonalne rozszerzenia, negocjowane przez capabilities, dodają Tasks (długie wywołanie zwraca uchwyt, który klient odpytuje) i MCP Apps (interaktywny interfejs renderowany przez hosta w rozmowie).
- Wersja specyfikacji 2026-07-28, aktualna we wrześniu 2026, zrobiła protokół bezstanowym. Nie ma już handshake’u
initializeani sesji: każdy request niesie w_metawersję protokołu i możliwości klienta, aserver/discover, które każdy serwer musi obsługiwać, a klient może wywołać, zwraca wersje i możliwości serwera. Dzięki temu zdalny serwer skaluje się za zwykłym load balancerem. Gdy serwer potrzebuje czegoś od użytkownika, nie wysyła własnego requestu, tylko odpowiadainput_required, a klient ponawia wywołanie z odpowiedzią. Starsze serwery (do wersji 2025-11-25) zaczynają odinitializez negocjacją możliwości i trzymają sesję. Klient, który chce z nimi rozmawiać, wykrywa wersję i przełącza się na stary tryb. W drugą stronę to nie działa: klient na wersji 2025-11-25 lub starszej nie umie przejść na nowy tryb, więc serwer, który ma obsłużyć także takich klientów, musi obsługiwać obie ery i nadal odpowiadać nainitialize. - Zdalny serwer autoryzuje requesty przez OAuth 2.1 i jest w nim resource serverem. Na request bez tokena odpowiada 401 z adresem swoich metadanych. Klient znajduje w nich serwer autoryzacji, przeprowadza użytkownika przez logowanie i dostaje token wydany dla tego jednego serwera. Serwer nie może przyjąć tokena wystawionego dla innej usługi ani przekazać tokena klienta dalej do API (token passthrough). Lokalny serwer stdio bierze poświadczenia ze zmiennych środowiskowych.
Przejdź krok po kroku przez wymianę z serwerem kalendarza. Patrz, co jest protokołem MCP, a co zwykłym function calling
Wiadomości skrócone. Każdy request musi nieść _meta z wersją protokołu i możliwościami klienta, a serwer odrzuci request bez tego pola. Dla oszczędności miejsca pokazujemy je tylko w kroku server/discover, tak jak przykłady w samej specyfikacji. Format wywołania w API modelu jest ogólny, każdy dostawca nazywa pola trochę inaczej.
Każdy serwer kosztuje tokeny
- Prosty host dokleja definicje wszystkich narzędzi ze wszystkich podłączonych serwerów do każdego requestu. Anthropic opisuje pięć serwerów z 58 narzędziami, które zajmowały ok. 55 tys. tokenów, zanim padło pierwsze pytanie. Płacisz za to w każdej turze, a model częściej się myli, gdy narzędzia mają podobne nazwy, np.
notification-send-userinotification-send-channel. - Ogranicz to po stronie hosta: podłączaj tylko potrzebne serwery i włączaj z nich tylko potrzebne narzędzia. Przy dużym katalogu host odracza ładowanie definicji: model dostaje narzędzie do wyszukiwania narzędzi, a pełne definicje trafiają do kontekstu na żądanie. Stan na wrzesień 2026: Claude Code, Codex i Cursor robią tak domyślnie, a Claude Code na starcie ładuje tylko nazwy narzędzi i instrukcje serwera. Dokumentacja MCP radzi ten tryb, gdy definicje zajmują 1–5% okna. Nie przestawiaj ani nie usuwaj narzędzi w trakcie rozmowy, bo to unieważnia prompt cache (temat „Prompt caching”). Definicje znalezione wyszukiwaniem dopisuje się za prefiksem zapisanym w cache’u, więc go nie unieważniają.
- Serwer projektuj wokół zadań, nie endpointów API: jedno
schedule_event, które szuka wolnego terminu i tworzy spotkanie, zamiast trzech opakowańlist_users,list_eventsicreate_event(przykład Anthropic). Zwracaj zwięzłe wyniki, tylko z polami potrzebnymi modelowi, filtrowane i stronicowane po stronie serwera, bo wynik zostaje w kontekście na wszystkie kolejne tury. Gdy host odracza ładowanie definicji, to nazwa, opis narzędzia i instrukcje serwera decydują, czy model w ogóle znajdzie narzędzie, więc najważniejsze informacje dawaj na początku. Gdy agent łączy wiele wywołań, pomaga code mode: model pisze skrypt, który woła narzędzia w sandboksie, a do kontekstu wraca tylko wynik końcowy.
Obcy serwer to obcy kod i obcy tekst
- Lokalny serwer działa z uprawnieniami twojego użytkownika i może czytać pliki czy klucze SSH. Zdalny dostaje każdy argument, który przekaże mu model. Opisy narzędzi i ich wyniki trafiają do promptu jako tekst, a model nie odróżnia ich od twoich instrukcji (temat „Prompt injection”).
- Tool poisoning to polecenie ukryte w opisie narzędzia. Model czyta je, nawet jeśli nigdy tego narzędzia nie wywoła: w każdym requeście, gdy host ładuje definicje z góry, albo gdy wyszukiwanie zwróci to narzędzie, a użytkownik zwykle widzi tylko nazwę i skrót opisu. Invariant Labs pokazał w kwietniu 2025 narzędzie
add, którego opis nakłonił agenta w Cursorze do odczytania klucza SSH i konfiguracji MCP i wysłania ich w dodatkowym parametrze. Złośliwy opis może też zmienić sposób używania narzędzi innych, zaufanych serwerów (shadowing). - Rug pull: serwer zmienia definicje po tym, jak go zatwierdziłeś. Wystarczy, że następne
tools/listzwróci inny opis albo nowa wersja pakietu zrobi coś innego niż poprzednia. - Złośliwy serwer sam dostarcza dwa z trzech składników „lethal trifecta”: niezaufany tekst i kanał wyjścia, bo wszystko, co model wpisze w argumenty jego narzędzi, trafia do właściciela. Prywatne dane daje dowolny inny podłączony serwer. Szkodę mnożą zbyt szerokie uprawnienia: token do wszystkich repozytoriów zamienia jeden udany atak w wyciek wszystkiego.
- Obrona leży w hoście, nie w prompcie: lista dozwolonych serwerów, z nich tylko potrzebne narzędzia, przypięte wersje i ponowna zgoda przy zmianie definicji, lokalne serwery w sandboksie, tokeny z minimalnym zakresem rozszerzanym na żądanie. Narzędzia, które coś zmieniają albo wysyłają, wywołuj dopiero po zgodzie człowieka, który widzi argumenty. Adnotacje takie jak
readOnlyHintdeklaruje sam serwer, więc od niezaufanego nic nie znaczą.
Kiedy nie potrzebujesz MCP
- Jedna aplikacja z kilkoma własnymi narzędziami: wystarczy zwykłe function calling w kodzie aplikacji. MCP dokłada osobny proces albo usługę, transport, autoryzację i wersjonowanie, a zysk z M + N pojawia się dopiero wtedy, gdy tej samej integracji używa kilka aplikacji.
- MCP opłaca się, gdy integracja ma działać w wielu hostach (twoje produkty, IDE zespołu, Claude i ChatGPT klientów) albo gdy chcesz użyć gotowego serwera dostawcy zamiast pisać integrację. API OpenAI (narzędzie
mcpw Responses API) i Anthropic (MCP connector) same łączą się ze zdalnym serwerem, więc nie musisz pisać klienta.
Sprawdź się
Czym jest MCP i kiedy użyjesz go zamiast zwykłego function calling?
MCP to otwarty protokół oparty na JSON-RPC, który standaryzuje stronę aplikacji w function calling: host odkrywa narzędzia serwera przez tools/list i wywołuje je przez tools/call. Model nic nie zauważa, nadal widzi definicje w prompcie i wypisuje wywołania. Zysk to M + N integracji zamiast M × N: serwer pisze się raz i działa w Claude, ChatGPT czy IDE. Cena to definicje podłączonych serwerów w kontekście (wszystkie w każdym requeście, chyba że host ładuje je na żądanie przez wyszukiwanie narzędzi) i nowa granica zaufania, bo obcy serwer to obcy kod i obcy tekst w prompcie. Dla jednej aplikacji z kilkoma własnymi narzędziami wystarczy zwykłe function calling.
In English
MCP is an open JSON-RPC protocol that standardises the application side of function calling: the host discovers a server’s tools with tools/list and invokes them with tools/call. The model notices nothing; it still sees tool definitions in the prompt and emits calls. The gain is M + N integrations instead of M × N: a server is written once and works in Claude, ChatGPT or an IDE. The cost is the connected servers’ definitions in the context (all of them on every request, unless the host defers them through tool search), and a new trust boundary, because a third-party server is untrusted code that puts untrusted text into the prompt. For one app with a few internal tools, plain function calling is enough.
Pytania pogłębiające (5)
- Masz 30 serwerów MCP i agent zaczyna wybierać złe narzędzia. Co robisz?
- Zmierz, ile tokenów zajmują definicje i które narzędzia się nakładają. Zostaw tylko narzędzia potrzebne do zadania, resztę ładuj przez wyszukiwanie narzędzi albo podziel między subagentów z własnymi zestawami. Nie przestawiaj ani nie usuwaj narzędzi w trakcie rozmowy, żeby nie psuć prompt cache’u.
- Jak dopuścić serwery MCP w firmie, żeby nie otworzyć drogi do wycieku?
- Lista zatwierdzonych serwerów z przypiętymi wersjami i porównywaniem definicji przy każdej aktualizacji, lokalne serwery w sandboksie, tokeny OAuth z minimalnym zakresem wydane dla konkretnego serwera. Akcje zapisujące i wysyłające zatwierdza człowiek w hoście, a każde wywołanie trafia do logu audytowego.
- Czym różnią się tools, resources i prompts?
- Tym, kto decyduje o użyciu. Narzędzia wybiera model, zasoby dołącza aplikacja, np. plik albo schemat bazy jako kontekst, prompty wybiera użytkownik, zwykle jako polecenie z ukośnikiem. Nie każdy host obsługuje wszystko: MCP connector w API Anthropic obsługuje tylko narzędzia.
- Po co wersja 2026-07-28 usunęła sesje i initialize?
- Żeby zdalny serwer skalował się jak zwykłe API. Każdy request niesie wersję i możliwości klienta, więc może trafić na dowolną instancję za load balancerem bez wspólnego stanu. Stan między wywołaniami przekazuje się jawnie: narzędzie zwraca uchwyt, a model podaje go w kolejnym wywołaniu.
- Budujesz serwer MCP nad istniejącym REST API. Jak do tego podchodzisz?
- Nie mapuj endpointów jeden do jednego. Wybierz kilka zadań, które agent naprawdę wykonuje, i zrób z nich narzędzia, które same łączą kilka wywołań API. Zwracaj tylko potrzebne pola, filtruj i stronicuj po stronie serwera, a błędy walidacji odsyłaj jako wynik z isError i wskazówką, jak poprawić argumenty.