MCP (Model Context Protocol): definicja, działanie i przykłady

Agent AI, który potrafi rozmawiać wyłącznie sam ze sobą, niewiele wnosi. Aby naprawdę działać, musi czytać Państwa pliki, odpytywać bazy danych, zapisywać w narzędziach. MCP to protokół stworzony, by standaryzować to połączenie, zamiast wymyślać je od nowa przy każdym kolejnym narzędziu.

Definicja szczegółowa

Oficjalna strona protokołu definiuje go tak: MCP to „otwarty standard łączenia aplikacji AI z systemami zewnętrznymi”, który pozwala im uzyskać dostęp do źródeł danych (plików lokalnych, baz danych), narzędzi (wyszukiwarek, kalkulatorów) i workflow (wyspecjalizowanych promptów). Jego własna dokumentacja podsumowuje ideę prostym obrazem: MCP jest „jak port USB-C dla aplikacji AI”, standaryzowanym złączem zamiast osobnego kabla dla każdego urządzenia.

Protokół został ogłoszony przez Anthropic 25 listopada 2024 roku. Ogłoszenie opisuje problem, który MCP ma rozwiązać: asystenci AI pozostawali odizolowani od danych mimo ich krytycznego znaczenia, a każde nowe źródło wymagało implementacji na miarę, co mnożyło problem integracji przy każdym nowym narzędziu i każdym nowym modelu. Anthropic opublikowało jednocześnie specyfikację, zestawy narzędzi deweloperskich i repozytorium referencyjnych serwerów MCP dla narzędzi takich jak Google Drive, Slack, GitHub, Git czy Postgres. Zobacz ogłoszenie Anthropic.

IBM proponuje uzupełniające, techniczne ujęcie: MCP to „warstwa standaryzacji pozwalająca aplikacjom AI skutecznie komunikować się z usługami zewnętrznymi, takimi jak narzędzia, bazy danych czy predefiniowane szablony promptów”. Ten opis podkreśla często pomijaną kwestię: MCP nie mówi agentowi, kiedy użyć narzędzia, ani jak zorkiestrować kilka etapów. Standaryzuje wyłącznie sposób, w jaki narzędzie się opisuje i łączy. Zobacz artykuł IBM o MCP.

Jak to działa

MCP stosuje architekturę klient-serwer z trzema rolami, szczegółowo opisaną w oficjalnej dokumentacji i powtórzoną przez Microsoft w dokumentacji .NET. Host MCP (MCP host) to sama aplikacja AI, na przykład asystent lub edytor kodu. Tworzy dedykowanego klienta MCP dla każdej usługi, z którą się łączy. Każdy klient utrzymuje połączenie z serwerem MCP, programem faktycznie eksponującym dane lub działania. Serwer MCP może działać lokalnie na komputerze użytkownika lub zdalnie na serwerach dostawcy narzędzia.

W praktyce serwer MCP eksponuje trzy typy elementów: narzędzia (działania, które agent może wyzwolić, jak odpytanie bazy czy wysłanie wiadomości), zasoby (dane dostępne do przeglądania, jak zawartość pliku) oraz prompty (gotowe do ponownego użycia szablony zapytań). Klient najpierw odpytuje serwer, co ten oferuje, a następnie może wywołać konkretne narzędzie z konkretnymi argumentami, mechanizm zbliżony do opisanego w naszym artykule o tool calling.

To właśnie tutaj źródła różnią się co do dokładnego zakresu MCP. IBM i Microsoft zgadzają się, że MCP nie zastępuje tool calling: to mechanizm, który pozostaje pod spodem, ten, dzięki któremu model faktycznie żąda wykonania działania. To, co dodaje MCP, to wspólny sposób opisywania i odkrywania tych narzędzi, niezależny od dostawcy modelu, tam gdzie wcześniej każdy dostawca narzucał własny format wywołania. Podobnie MCP nie zastępuje zwykłych API: dokumentacja .NET Microsoftu precyzuje, że serwer MCP „może dostarczyć abstrakcję nad API REST”, aby udostępnić modelowi dane biznesowe. MCP jest więc wspólną fasadą nałożoną na istniejące API, a nie technologią, która czyni je zbędnymi.

Serwer MCP może też eksponować bazę dokumentów do przeszukania przed udzieleniem odpowiedzi, zastosowanie bezpośrednio pokrywające się z zasadą RAG: najpierw szukać w wiarygodnym źródle, potem generować odpowiedź na podstawie tego, co znaleziono.

Konkretny przykład z Atako

Plan Standard w Atako wymienia „Atako MCP” wśród swoich funkcji, obok integracji, obserwowalności czy BYOK, na stronie cennika. Klucz API wygenerowany w ustawieniach konta służy między innymi do łączenia zewnętrznych klientów MCP z platformą.

Reszta konkretnej implementacji, które serwery, jakie narzędzia eksponowane w szczegółach, nie jest obecnie publicznie udokumentowana. Lepiej pozostać przy faktach w tej kwestii, niż zgadywać listę narzędzi czy datę uruchomienia.

Częste błędy

Pierwszy błąd: przekonanie, że MCP to całkowicie nowy mechanizm, który zastąpiłby tool calling. Tak nie jest, MCP standaryzuje opis i odkrywanie narzędzi, ale samo wywołanie pozostaje klasycznym wywołaniem funkcji, produkowanym przez model.

Drugi błąd: myślenie, że „serwer MCP” oznacza koniecznie dużą, zdalną maszynę. Oficjalna dokumentacja wyraźnie rozróżnia serwery lokalne, działające na komputerze użytkownika i komunikujące się lokalnie, od serwerów zdalnych, hostowanych przez dostawcę narzędzia i dostępnych przez HTTP.

Trzeci błąd: mylenie MCP z gwarancją bezpieczeństwa samą w sobie. Protokół standaryzuje sposób, w jaki model odkrywa i wywołuje narzędzie, nie decyduje za niego o uprawnieniach przyznanych temu narzędziu. Na poważnej platformie ta decyzja pozostaje osobną warstwą, niezależną od użytego protokołu połączenia.

Czwarty błąd: przekonanie, że każde narzędzie połączone z agentem przechodzi koniecznie przez MCP. Wielu agentów, w tym korzystających z integracji takich jak GitHub czy Slack, wywołuje działania przez klasyczny tool calling bez dedykowanego serwera MCP. Atako nie dokumentuje publicznie szczegółów narzędzi eksponowanych przez własny MCP: MCP pozostaje jedną z opcji połączenia, nie obowiązkowym przejściem, by nadać agentowi narzędzia.

Zobacz też

MCP dość szybko narzuciło się jako standard wspierany przez szeroki ekosystem: oficjalna dokumentacja wymienia wśród zgodnych klientów MCP aplikacje takie jak Claude czy edytory kodu jak Visual Studio Code i Cursor. Aby poznać sąsiednie elementy tego protokołu, zapraszamy do pełnego słownika, z hasłami tool calling, RAG i BYOK, wszystkie to mechanizmy połączenia lub konfiguracji po stronie modelu.