Podstawy MCP: hosty, klienci, serwery oraz format komunikacji JSON-RPC

Modele językowe stały się naprawdę przydatne dla firm w momencie, gdy mogły podejmować działania, a nie tylko odpowiadać. Trudnością nigdy nie był sam model; chodziło o połączenie go z bazami danych, API i narzędziami wewnętrznymi, gdzie faktycznie odbywa się praca, oraz o zrobienie tego połączenia tylko raz, a nie za każdym razem w nowej aplikacji czy u innego dostawcy modeli. Model Context Protocol (MCP) to próba standaryzacji takich połączeń. Ten artykuł wyjaśnia problem, który rozwiązuje MCP, role jego komponentów, co jest przekazywane przez sieć oraz w czym różnią się dwa standardowe protokoły transmisji, abyś mógł ocenić, jak serwer MCP pasuje do twojej architektury.

Gdzie LLM tworzą wartość: podejmowanie działań

Kiedyś duża część zautomatyzowania była niedostępna po prostu dlatego, że oprogramowanie nie potrafiło interpretować żądań o luźnej strukturze. Modele językowe usuwają tę barierę – po podłączeniu do narzędzi mogą sterować procesami wieloetapowymi, które wcześniej wymagały interwencji człowieka przy przechodzeniu pomiędzy systemami.

Weźmy na przykład asystenta, od którego wymaga się znalezienia i zarezerwowania pociągu z Casablanki do Rabatu. Zrozumienie żądania to dopiero pierwszy krok – asystent musi wyszukać informacje w usłudze rozkładu jazdy, wybrać godzinę odjazdu, skorzystać z API do rezerwacji i potwierdzić wynik. Każdy z tych kroków to wywołanie narzędzia. Gdy narzędzia są dostępne przez serwer MCP, każdy kompatybilny agent może przeprowadzić cały proces.

Kwestie biznesowe są oczywiste: mniej kroków ręcznych na zadanie oznacza niższe koszty operacyjne i szybszy czas realizacji. Istnieje również argument związany z doświadczeniem użytkownika. Pracownicy regularnie obsługują wiele paneli sterowania i interfejsów, z których każdy ma własną logikę. Interfejs konwersacyjny połączony z tymi backendami może ukryć dużą część tej złożoności za jednym interfejsem.

Problem integracji, który rozwiązuje MCP

Używanie narzędzi nie jest nowością. Każde ważne SDK LLM je obsługuje, ale każde robi to według własnych konwencji dotyczących deklarowania narzędzia, opisywania parametrów i zwracania wyników. W praktyce oznacza to, że to samo narzędzie jest implementowane kilka razy – po raz jeden dla każdego dostawcy modeli. Zmiana modeli lub obsługa dwóch jednocześnie wymaga przenoszenia kodu integracyjnego, co spowalnia pracę zespołów i utrudnia skalowanie produktów.

Pominięcie SDK-ów nie rozwiązuje tego problemu w pełni. Można stworzyć własną warstwę integracyjną, która mapuje intencje na działania, wywołuje punkty końcowe, zbiera parametry, radzi sobie z błędami i rejestruje dane analityczne. To dodaje złożoności, ale jest to do zarządzania. Głębszym problemem jest to, że taka warstwa zazwyczaj znajduje się wewnątrz jednej aplikacji. Gdy druga aplikacja potrzebuje tych samych narzędzi, zespół musi ponownie budować tę samą warstwę. Logika integracji jest powiązana z aplikacją korzystającą, a nie z systemem, który posiada daną funkcjonalność.

Czym jest MCP

MCP to otwarty standard, który zapewnia aplikacjom AI wspólny sposób łączenia się z źródłami danych i narzędziami. Nie umożliwia niczego, co wcześniej było całkowicie niemożliwe; sprawia jedynie, że te połączenia stają się prostsze i bardziej spójne. Dokumentacja protokołu dostępna na modelcontextprotocol.io stanowi autorytatywny punkt odniesienia.

Kluczową zmianą jest to, gdzie znajduje się logika narzędzia. Dzięki MCP usługa backendowa, taka jak baza danych, API lub narzędzie wewnętrzne, publikuje swoje możliwości za pośrednictwem serwera MCP. Powszechnie używanym porównaniem jest port USB-C: usługa udostępnia standardowy gniazdo, do którego może się podłączyć każda kompatybilna aplikacja. Aplikacja AI nie zawiera już wiedzy o tym, jak używać poszczególnych narzędzi; musi jedynie rozumieć protokół.

Architektura: hosty, klienci i serwery

MCP wykorzystuje architekturę kliencko-serwerową z trzema rolami, które łatwo pomylić:

• Host: sama aplikacja AI, na przykład asystent czatowy, IDE z agentem lub własna usługa agenta. To z nią użytkownik wchodzi w interakcję i łączy się ze światem zewnętrznym za pośrednictwem jednego lub kilku serwerów MCP.

Klient: komponent wewnątrz hosta, który nawiązuje i utrzymuje połączenie z pojedynczym serwerem MCP. To „złącze” w analogii USB-C.

Serwer: program, który w standardowy sposób oferuje możliwości klientom.

Host nigdy nie komunikuje się bezpośrednio z serwerem. Tworzy jeden klient na każdy serwer i deleguje całą komunikację na niego, a każdy klient utrzymuje dedykowane, jedno-do-jednego połączenie. To rozdzielenie jest przydatne w praktyce: host połączony z serwerem systemu plików, serwerem do obsługi zgłoszeń i serwerem CRM uruchamia trzy niezależne klienty, dzięki czemu awaria lub ograniczenia uprawnień w jednym połączeniu nie wpływają na pozostałe.

Trzy podstawowe elementy serwera

Podstawowe elementy określają, co każda ze stron może oferować. Serwer udostępnia trzy główne rodzaje:

• Narzędzia: operacje, które model może wykonać, takie jak wywołanie API lub zapisanie rekordu.
• Zasoby: dane, które model może odczytać i wykorzystać jako kontekst, takie jak wiersze bazy danych lub dokumenty.
• Instrukcje: z góry określone szablony poleceń, które kierują modelem, podobne w istocie do wielokrotnie używalnych instrukcji systemowych.

Różnica pomiędzy narzędziami a zasobami ma znaczenie dla bezpieczeństwa i projektowania. Odczytywanie zasobu nie powinno powodować skutków ubocznych, natomiast wywołanie narzędzia może zmienić otoczenie, dlatego hostowie często stosują różne zasady zatwierdzania dla każdego z nich.

JSON i JSON-RPC: format wiadomości

JSON (JavaScript Object Notation) reprezentuje dane strukturalne jako tekst składający się z par klucz-wartość, tablic i zagnieżdżonych obiektów. Ponieważ format jest prosty i powszechnie obsługiwany, nadawca oraz odbiorca pisani w różnych językach mogą dojść do porozumienia co do znaczenia wiadomości.

JSON-RPC rozwija tę koncepcję, definiując ustaloną strukturę wiadomości dla zdalnych wywołań procedur. Prośba zawiera nazwę metody, parametry oraz identyfikator; jeśli obie strony przestrzegają tej struktury, klient może poprosić serwer o uruchomienie metody i otrzymać wynik lub błąd w równie przewidywalnym formacie. Poniższy przykład to prośba JSON-RPC 2.0 skierowana do serwera o wyszukanie informacji pogodowych dla Casablanki. Zwróć uwagę na cztery pola: wersję protokołu, identyfikator id prośby używany do dopasowania odpowiedzi, nazwę method oraz obiekt params.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "get_weather",
  "params": {
     "city": "Casablanca"
   }
}

To przykład ilustruje zwykłe JSON-RPC. W samym MCP narzędzia nie są wywoływane jako metody najwyższego poziomu nazwane imieniem narzędzia. Zamiast tego klient wysyła żądanie z metodą tools/call, umieszczając nazwę narzędzia oraz jego argumenty w polu params. To pośrednictwo umożliwia MCP zdefiniowanie ustalonej listy metod protokołu, podczas gdy serwery mogą swobodnie udostępniać dowolne narzędzia, które im się podobają.

Odkrywanie to brakujący element

JSON-RPC sam w sobie pozostawia jeden nierozwiązany problem: klient musi już znać, jakie metody oferuje serwer. MCP eliminuje tę lukę, standaryzując sposób, w jaki klienci odkrywają dostępne funkcje. Klient może poprosić serwer o wylistowanie jego narzędzi, zasobów i poleceń, otrzymując nazwy, opisy oraz schematy danych wejściowych, a następnie przekazać te opisy modelowi. MCP określa również, w jaki sposób inicjalizowana jest połączenie oraz jakie mechanizmy transportowe przenoszą wiadomości.

Mechanizmy transportowe: jak podróżują wiadomości

JSON-RPC definiuje słownictwo; transport określa, w jaki sposób bajty przemieszczają się pomiędzy klientem a serwerem. W chwili pisania dokumentacji MCP określa dwa standardowe mechanizmy transportowe. Przed poleganiem na szczegółach sprawdź aktualną specyfikację, ponieważ protokół nadal się rozwija.

stdio dla lokalnych narzędzi

Z użyciem transportu stdio klient uruchamia serwer MCP jako proces potomny. Serwer odczytuje przychodzące wiadomości ze swojego standardowego wejścia i zapisuje odpowiedzi do standardowego wyjścia. Każdy proces otrzymuje te rury automatycznie od systemu operacyjnego, więc nie są potrzebne żadne gniazda sieciowe ani porty.

Dzięki temu stdio jest idealne dla narzędzi działających na tej samej maszynie co host, np. serwera, który tworzy foldery w lokalnym systemie plików. Dodatkową zaletą jest izolacja: serwer istnieje tylko tak długo, jak długo host utrzymuje jego działanie, i nie jest dostępny z sieci.

Streamable HTTP dla współdzielonych, zdalnych serwerów

Z użyciem Streamable HTTP serwer jest niezależnym procesem działającym jako usługa HTTP i może obsługiwać wiele klientów jednocześnie. Wiadomości są wymieniane za pomocą zwykłych żądań HTTP.

To rozwiązanie umożliwia transmisję strumieniową. Zamiast czekać na pełną odpowiedź, serwer może wysyłać dane stopniowo, co jest przydatne przy długotrwałych wywołaniach narzędzi. Transmisja strumieniowa jest realizowana za pomocą Server-Sent Events (SSE) – jednokierunkowego kanału, w którym jedna długotrwała odpowiedź HTTP zawiera sekwencję zdarzeń wysyłanych przez serwer. Ruch w drugim kierunku nadal odbywa się jako zwykłe żądania HTTP od klienta. Dokładne zachowanie zależy od implementacji oraz używanej wersji HTTP.

Praktyczna zasada: wybierz stdio, gdy narzędzie znajduje się na komputerze jednego użytkownika, a Streamable HTTP wtedy, gdy funkcjonalność powinna być udostępniana między użytkownikami lub zespołami, przy zachowaniu mechanizmów autoryzacji i kontroli sieciowych niezbędnych w usługach współdzielonych.

Dlaczego protokół jest ważniejszy niż inne SDK

Protokoły istnieją po to, aby systemy stworzone przez różne zespoły, w różnych językach i według odmiennych harmonogramów wydawania, mogły nadal współpracować w przewidywalny sposób. Protokół to uzgodniona zbiór reguł określających, w jaki sposób niezależne komponenty komunikują się ze sobą, interpretują swoje wiadomości i budują wzajemne zaufanie.

Wartość standaryzacji dostępu do narzędzi jest przede wszystkim ekonomiczna. Gdy koszt integracji nowego modelu lub aplikacji zbliża się do zera, eksperymentowanie staje się tanie, a tanie eksperymenty przyspieszają proces iteracji. Zespół zarządzający systemem może opublikować jeden serwer MCP, a każda obecna i przyszła aplikacja AI w organizacji może go używać bez konieczności pisania specjalistycznego kodu łączącego. Aby zobaczyć, jak to wygląda w ramach frameworku agentów, przeczytaj nasz artykuł na temat standaryzacji integracji narzędzi w LangGraph za pomocą MCP.

Główne wnioski

• LLM-y przynoszą największą wartość, gdy mogą działać w rzeczywistych systemach, a wąskim gardłem jest integracja, a nie inteligencja.
• Bez standardu ten sam narzędzie musi być ponownie implementowane dla każdego SDK modelu i aplikacji; MCP przenosi tę logikę na serwer należący do systemu, który dostarcza daną funkcjonalność.
• Host uruchamia jeden klient na serwer, a każdy klient utrzymuje dedykowane połączenie; serwery oferują narzędzia, zasoby i polecenia.
• JSON-RPC określa strukturę wiadomości, natomiast MCP dodaje ustaloną listę metod, takich jak tools/call, oraz mechanizm odkrywania możliwości.
• Dla lokalnych narzędzi przeznaczonych dla jednego użytkownika używaj stdio, a dla udostępnianych zdalnych usług – Streamable HTTP; sprawdzaj również szczegóły transmisji zgodnie z aktualną specyfikacją.

Powiązane materiały

• Stateless MCP: Skalowanie serwerów bez sesji czy handshake’ów — Jak protokół Model Context Protocol typu stateless eliminuje sesje i handshake’i, oraz w jaki sposób _meta, wieloetapowe żądania, nagłówki routingu, cache i zadania zapewniają jego użyteczność.
• Agentic AI wyjaśnione: Od modeli językowych do autonomicznych agentów — Strukturalne omówienie tego, jak modele językowe ewoluują w systemy agentic poprzez narzędzia, pamięć, planowanie, architektury wieloagentowe oraz integrację z MCP.