Model Context Protocol (MCP) zrozumiale wyjaśniony – z przykładem w n8n

Kto buduje agentów AI, zna ten problem: dla każdej funkcji podłączonej usługi trzeba zdefiniować osobne narzędzie. Wyszukanie wpisu w kalendarzu, jego utworzenie, zmiana, usunięcie – to już cztery odrębne elementy, i to tylko dla jednej usługi. Przy wielu połączeniach nakład na utrzymanie rośnie odpowiednio. Model Context Protocol (MCP) idzie inną drogą: standaryzuje sposób, w jaki model językowy komunikuje się z usługą – i drastycznie zmniejsza liczbę potrzebnych elementów. Ten wpis podsumowuje koncepcję oraz konkretny przykład praktyczny z n8n.

Co MCP właściwie rozwiązuje

Podstawowa idea Model Context Protocol tkwi w nazwie: model językowy ma rozumieć kontekst aplikacji. Konkretnie oznacza to: co ta aplikacja potrafi? Do czego służy? I jak wykonuję w niej działania?

Klasycznie przy budowie agenta podłącza się każde narzędzie osobno – każda funkcja to własny element. Na przykład w Google Calendar: narzędzie do wyszukiwania wpisów, jedno do aktualizacji, jedno do usuwania, jedno do tworzenia. Cztery funkcje dla jednej usługi. Przy złożonych agentach z wieloma podłączonymi usługami szybko zbiera się z tego kilkadziesiąt elementów.

Serwer, klient i jednolity schemat

MCP pracuje z dwiema rolami:

• Serwer MCP: stawia się przed właściwą usługą (np. Airbnb albo Google Calendar) i opisuje, jak można z tą usługą wchodzić w interakcję.
• Klient MCP: siedzi w agencie, pobiera funkcje serwera i je wywołuje.

W obecnej realizacji – na przykład w n8n – wystarczą do tego dwa kroki zamiast wielu pojedynczych narzędzi:

1. List Tools (wylistowanie): agent pyta serwer, jakie funkcje są dostępne.
2. Execute Tool (wykonanie): agent wywołuje konkretną funkcję z odpowiednimi parametrami.

Decydujący jest jednolity schemat. Niezależnie od tego, jaka usługa stoi za tym z tyłu: odpowiedź na zapytanie List Tools jest zawsze zbudowana tak samo. Zawiera dla każdej funkcji nazwę, opis oraz schemat z dopuszczalnymi parametrami. Treści i parametry różnią się między usługami – struktura pozostaje stała. Dokładnie to protokół narzuca i standaryzuje.

Przykład z narzędziem Airbnb

Gdy zapytamy agenta, jakie możliwości oferuje narzędzie Airbnb, sam pobierze listę funkcji przez narzędzie List Tools. W odpowiedzi wracają między innymi:

• Airbnb Search: wyszukiwanie ofert z filtrami i paginacją – na przykład lokalizacja, data zameldowania i wymeldowania, liczba osób dorosłych, dzieci, niemowląt i zwierząt domowych oraz przedział cenowy.
• Airbnb Listing Details: szczegółowe informacje o konkretnej ofercie na podstawie jej identyfikatora listing-ID.

Agent nie musiał tu dostać niczego z góry – sam zdobył dostępne funkcje, ich opisy oraz schemat parametrów. W schemacie widać na przykład pole tekstowe location (miasto, region itd.), pola dat zameldowania i wymeldowania, liczbę osób dorosłych oraz cenę minimalną i maksymalną.

Gdy postawimy potem konkretne zapytanie – na przykład o nocleg w Bangkoku dla sześciu osób za maksymalnie 50 euro za noc – agent działa dwustopniowo: najpierw wywołuje List Tools (nic nie zapamiętał, bo nie jest aktywna żadna pamięć), rozpoznaje na podstawie schematu potrzebne parametry i wykonuje wyszukiwanie przez Execute Tool. Wynik – na przykład nocleg z trzema łóżkami za ok. 35 euro za noc – wraca, i to przy zaledwie dwóch dodanych narzędziach. Gdyby Airbnb oferowało więcej funkcji, na przykład do zarządzania własnymi ogłoszeniami, dałoby się je odwzorować przez ten sam schemat, bez definiowania kolejnych elementów.

Jak odtworzyć MCP w n8n

Poniższe kroki pokazują konfigurację na przykładzie Airbnb. Nadaje się on dobrze do wypróbowania, bo nie wymaga klucza API.

1. Ustawienie zmiennej środowiskowej: Ustaw N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE na true. Pozwala to node’om społecznościowym na dostęp do narzędzi. Przy instalacji w Dockerze (np. na serwerze Hetzner) wpisujesz to w sekcji environment pliku docker-compose i uruchamiasz instancję ponownie.
2. Utworzenie AI Agent: Utwórz AI Agent i przypisz model (na filmie GPT-4.1 Mini).
3. Instalacja node’a społecznościowego: W Settings → Community Nodes instalujesz pakiet n8n-nodes-mcp i potwierdzasz ostrzeżenie o instalacji niesprawdzonego kodu z publicznych źródeł.
4. Dodanie narzędzia klienta MCP: Przez plus przy Tools wyszukaj „MCP”. Uwaga: nie pomyl tego z własnym MCP Client Tool od n8n – wariant społecznościowy poznasz po symbolu pudełka i jest on obecnie bardziej rozbudowany.
5. Utworzenie danych dostępowych: Jako rodzaj połączenia do wyboru są Command Line, Server-Sent Events i HTTP Streamable. W przykładzie zostaje Command Line. Właściwe wartości znajdziesz w repozytorium danego serwera MCP w sekcji o instalacji. Dla Airbnb: Command npx, argumenty wpisywane krok po kroku – -y, pakiet @openbnb/mcp-server-airbnb i opcjonalnie --ignore-robots-txt.

Uwaga do robots.txt: Opcja --ignore-robots-txt omija reguły dostępu strony internetowej. Do demonstracji jest to do przyjęcia – w środowiskach produkcyjnych należy respektować plik robots.txt danych usług.

Konfiguracja obu operacji

Następnie potrzebujesz dwóch narzędzi klienta MCP z różnymi operacjami:

• List Tools: Nazwij narzędzie np. „Airbnb List Tools” i podaj w opisie, że służy do pobierania wszystkich dostępnych narzędzi Airbnb. Testowe kliknięcie (Execute Step) powinno zwrócić znaną listę funkcji z nazwą, opisem i schematem.
• Execute Tool: Drugie narzędzie klienta MCP z operacją Execute Tool. Opis: do wykonywania narzędzi Airbnb, możliwych do wylistowania przez narzędzie List Tools. Nazwę narzędzia przekazujesz jako Expression, tak by agent sam decydował, którą funkcję wywołuje; parametry narzędzia zostawiasz wolne, żeby sam je ustalał.

Po uporządkowaniu i zapisaniu można przetestować agenta – na przykład ponownie zapytaniem o Bangkok. Pobiera listę funkcji, przekazuje ją modelowi, decyduje się na wyszukiwanie i dostarcza pasujące noclegi. Dokładnie to zachowanie z części koncepcyjnej, teraz we własnym workflow.

Poza n8n – i słowo o bezpieczeństwie

MCP nie ogranicza się do platform automatyzacji. Także aplikacje desktopowe jak Claude Desktop dają się połączyć z serwerami MCP. Dzięki temu można w czacie delegować zadania do lokalnie zainstalowanych programów – często cytowanym przykładem jest sterowanie oprogramowaniem 3D Blender przez MCP, w którym osoba bez znajomości Blendera tworzy renderingi. Serwer MCP działa przy tym lokalnie, sam model językowy nadal przez usługę chmurową.

Przy całym entuzjazmie obowiązuje: MCP to młode rozwiązanie. Istnieją już zastrzeżenia dotyczące bezpieczeństwa i znaleziono luki bezpieczeństwa. Zwłaszcza w środowiskach produkcyjnych technologię tę należy traktować z ostrożnością – warto obserwować dalszy rozwój, zanim oprze się na niej krytyczne procesy.

Podsumowanie

Model Context Protocol to pragmatyczne podejście do standaryzacji: model językowy uczy się przez serwer MCP sam, co dana usługa potrafi i jak się do niej zwracać – zamiast definiować z góry każdą funkcję osobno. Dla złożonych agentów AI oznacza to zauważalnie mniej elementów i mniejszy nakład na utrzymanie, w przykładzie n8n wystarczą dwa kroki: wylistować i wykonać. Podejście jest przekonujące, ale wciąż młode. Kto je wypróbuje, powinien zacząć od niekrytycznych usług, a w środowiskach produkcyjnych poważnie potraktować otwarte kwestie bezpieczeństwa.

Źródło: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) – kanał YouTube Philip Thomas, w języku niemieckim.