Spis treści:
- Problem MxN
- Idea działania protokołu MCP
- Ramy protokołu MCP
- Architektura protokołu MCP
Integracja różnych systemów i narzędzi zawsze była kluczowym wyzwaniem dla inżynierów, administratorów oraz menedżerów IT. W tej układance pojawił się jednak kolejny element – systemy wykorzystujące AI/ML. MCP rozwiązuje problem braku standaryzacji komunikacji między aplikacjami AI a zewnętrznymi źródłami danych.
O pracowany przez Anthropic Model Context Protocol (MCP) oferuje zunifikowane podejście do standaryzacji komunikacji pomiędzy aplikacjami AI a zewnętrznymi źródłami danych i narzędziami. MCP można porównać do uniwersalnego złącza USB w świecie oprogramowania – zamiast tworzyć wiele niestandardowych integracji, protokół ten upraszcza procesy, umożliwiając płynną współpracę między różnorodnymi systemami. Takie porównanie proponują twórcy tego protokołu. Oby wraz z upływem czasu nie okazało się, jak w protokole USB, że powstanie kilka jego wersji. W artykule przyjrzymy się, jakie problemy rozwiązuje MCP oraz jakie korzyści niesie dla organizacji dążących do efektywnego wykorzystania sztucznej inteligencji w swoich środowiskach IT.
Problem M×N
Jednym z głównych wyzwań w integracji systemów IT jest tzw. problem M×N (czytany jako „M na N”). Jest to ogólna nazwa dla klasy problemów, które można przedstawić jako operacje lub działania na macierzy o rozmiarze M wierszy i N kolumn. W zależności od kontekstu (informatyka, matematyka, inżynieria, logistyka) znaczenie może się różnić. W matematyce i informatyce mówimy o przeszukiwaniu macierzy w celu znalezienia konkretnej wartości lub wzorca czy problemów grafowych. W uczeniu maszynowym dane wejściowe są często reprezentowane jako macierz M×N, gdzie M to liczba próbek, a N cech. W logistyce zaś problem M×N może opisywać sytuację, w której trzeba przypisać M zasobów do N zadań w sposób optymalny, np. minimalizując koszt lub czas.
Problem M×N w kontekście systemów AI/ML pojawia się, gdy mamy do czynienia z wieloma modelami uczenia maszynowego (M modeli) oraz wieloma kontekstami aplikacyjnymi lub operacyjnymi (N kontekstów), w których te modele muszą działać. Na początek wyjaśnijmy sobie te dwa pojęcia.
Modele uczenia maszynowego
To stworzone przy wykorzystaniu danych i algorytmów programy komputerowe, których celem jest rozpoznawanie wzorców, przewidywanie wyników lub podejmowanie decyzji bez konieczności ich ręcznego programowania. Taki model uczy się na podstawie danych historycznych – np. analizując tysiące zdjęć kotów i psów, może nauczyć się odróżniać jedno od drugiego. W uczeniu nadzorowanym model dostaje dane wejściowe (np. obraz) oraz etykietę (np. „pies”) i uczy się przewidywać poprawną odpowiedź. W nienadzorowanym odkrywa samodzielnie struktury i zależności w danych, np. grupując podobne produkty. Modele można trenować do rozmaitych zadań: od rozpoznawania mowy i przetwarzania języka naturalnego, przez prognozowanie pogody, aż po systemy rekomendacyjne w sklepach internetowych. Działają one zazwyczaj w ramach większych systemów, przetwarzając dane wejściowe (np. tekst, obraz, liczby), analizując je według wyuczonych reguł i zwracając dane wyjściowe (np. klasyfikację, wynik predykcji, odpowiedź w dialogu). Z modelami mamy teraz styczność praktycznie codziennie, nawet nie zdając sobie z tego sprawy. Gdy mówimy „Hej Siri” albo „OK Google”, w tle działa model, który zamienia dźwięk naszego głosu na tekst. To właśnie model rozpoznawania mowy, który nauczył się odczytywać słowa z fal dźwiękowych. Innym przykładem są rozmowy z modelami językowymi, które rozumieją pytania i generują sensowne odpowiedzi – to jeden z najbardziej zaawansowanych przykładów uczenia maszynowego. Takie modele jak GPT-4, Gemini czy Claude są trenowane na ogromnych zbiorach danych.
Konteksty aplikacyjne lub operacyjne
To warunki, środowiska lub sytuacje, w których dany model jest wykorzystywany. Na kontekst składa się wszystko, co otacza model w trakcie jego działania. Kontekst może być techniczny (np. urządzenie, na którym model działa – telefon, serwer, głośnik), semantyczny (np. język użytkownika, lokalizacja, pora dnia) lub funkcjonalny (np. czy użytkownik właśnie mówi, pisze, czy kliknął produkt). Na przykład wspomniany wcześniej model rozpoznawania mowy może działaćinaczej w kontekście samochodu (gdzie występuje dużo hałasu i polecenia są krótkie) niż w kontekście inteligentnego głośnika w domu, gdy możemy mówić pełnymi zdaniami i oczekiwać dłuższych odpowiedzi. W aplikacji mobilnej kontekst może obejmować również zasoby – czy użytkownik ma połączenie z internetem, jaki ma system operacyjny, jakie są ustawienia prywatności. W praktyce kontekst określa, jakie dane model może przetwarzać, jakie są jego ograniczenia i jak powinien się zachowywać, by być przydatnym i skutecznym w danym środowisku.
I to jest dokładnie problem M×N, z którym spotykamy się w środowisku AI/ML. Polega on na tym, że każdy z tych modeli musi współpracować z każdym kontekstem, czyli np. model rozpoznawania mowy musi być w stanie działa inaczej w samochodzie (gdzie hałas jest większy) niż w domu (gdzie mamy dostęp do wielu mikrofonów). Połączenie modelu uczenia maszynowego z kontekstem operacyjnym tworzy dynamiczny system, który musi dostosowywać swoje działanie do zmieniających się warunków. Bez odpowiedniego protokołu dochodzi do ogromnego rozrostu konfiguracji i kodu integracyjnego. Dla M modeli i N kontekstów potencjalnie potrzebujemy M×N ręcznie zarządzanych powiązań – czyli dla trzech modeli i czterech kontekstów mamy już 12 różnych kombinacji. Każda z nich może wymagać innego podejścia do danych wejściowych (np. różne sensory, języki, formaty danych), innego przetwarzania pośredniego (np. dodatkowe modele pomocnicze) oraz innego typu odpowiedzi (np. w kontekście zegarka wyświetlana na nim odpowiedź musi być skrócona, a w domu może być bardziej rozbudowana). Właśnie tutaj z pomocą przychodzi Model Context Protocol (MCP), który formalizuje i zarządza tymi zależnościami. Dzięki temu możliwe jest, by jeden model mógł działać w wielu kontekstach, a kilka modeli mogło współdziałać w ramach jednego systemu – bez konieczności ręcznego konfigurowania każdej z możliwych kombinacji.
Idea działania protokołu MCP
Model Context Protocol (MCP) został zaprojektowany jako otwarty standard przez Anthropic – firmę założoną w 2021 r. przez Dario Amodeia i innych byłych pracowników OpenAI. Organizacja powstała w odpowiedzi na rosnącą potrzebę rozwoju bezpieczniejszej i lepiej kontrolowanej sztucznej inteligencji. Misją Anthropic jest projektowanie systemów AI, które są bezpieczne, transparentne i zgodne z etyką, a także mogą być kontrolowane w sposób umożliwiający unikanie niezamierzonych i szkodliwych konsekwencji. Stawiają na rozwój zaawansowanych modeli AI, które nie tylko generują odpowiedzi na podstawie danych wejściowych, ale także rozumieją szerszy kontekst oraz intencje użytkownika. Firma ma na celu stworzenie systemów, które są bardziej zgodne z ludzkimi wartościami i lepiej adaptują się do rzeczywistych, złożonych sytuacji. Dodatkowo firma podkreśla znaczenie etyki i odpowiedzialności w rozwoju AI. W pewnym sensie Anthropic dąży do stworzenia sztucznej inteligencji, która, przy zachowaniu proporcji, przypomina komputer pokładowy z serialu „Star Trek” – taki, który jest w stanie prowadzić złożoną, naturalną rozmowę, pojmować kontekst oraz podejmować decyzje ze zrozumieniem sytuacji, intencji i celów użytkownika. Chociaż nie ma jeszcze sztucznej inteligencji dorównującej tej ze „Star Treka” (np. komputerowi Enterprise, który ma dostęp do wszystkich danych na statku i może natychmiastowo dostarczać trafne odpowiedzi na pytania), Anthropic pracuje nad kilkoma kluczowymi aspektami, które mogą zbliżyć nas do takiej technologii.
Komputer pokładowy na statku USS Enterprise, szczególnie w wersji przedstawionej w „Star Trek: The Next Generation” oraz „Star Trek: Discovery”, był czymś więcej niż tylko narzędziem – pełnił rolę centralnego systemu zarządzania całą infrastrukturą statku. Był zdolny do wykonywania złożonych obliczeń, zarządzania systemami (takimi jak osłony, napęd warp czy kontrola środowiska), a także odpowiadania na pytania załogi w sposób kontekstowy i precyzyjny. Podobnie jak MCP komputer ten działał jako interfejs między użytkownikami a ogromnymi zasobami danych i funkcji.
Jednakże, podczas gdy MCP jest obecnie standardem technologicznym, umożliwiającym integrację AI z różnorodnymi systemami, komputer Enterprise był bardziej zaawansowany i wszechstronniejszy w swoim zakresie działania. Obie technologie mają na celu uproszczenie interakcji między użytkownikiem a systemami. MCP działa jako uniwersalny protokół umożliwiający aplikacjom AI dostęp do danych i narzędzi poprzez standaryzowane serwery. Można to porównać do sposobu, w jaki startrekowy komputer integrował różne systemy statku w jedną spójną całość. Na przykład MCP pozwala modelom AI na wykonywanie skomplikowanych zadań, takich jak przeszukiwanie baz danych czy obsługa narzędzi programistycznych, bez potrzeby tworzenia dedykowanych integracji. W podobny sposób komputer Enterprise mógł jednocześnie analizować dane naukowe, kontrolować trajektorię lotu i odpowiadać na pytania załogi, monitorując jednocześnie, czy funkcja i stopień służbowy pozwalają na udzielenie odpowiedzi, a jeżeli tak, to jak obszernej. Oba systemy charakteryzuje także zdolność do pracy w kontekście. MCP umożliwia modelom AI utrzymanie kontekstu podczas korzystania z różnych narzędzi czy źródeł danych, co jest kluczowe dla efektywności ich działania. Komputer Enterprise również operował w sposób kontekstowy – potrafił dostarczać odpowiedzi lub podejmować decyzje na podstawie bieżących potrzeb załogi i sytuacji na statku.
Ramy protokołu MCP
Pierwsza wersja MCP została oficjalnie zaprezentowana w listopadzie 2024 r. Protokół szybko zdobył uznanie dzięki swojej prostocie i elastyczności. MCP opiera się na architekturze klient–serwer, gdzie aplikacje AI (klienci) mogą łączyć się z serwerami MCP, które udostępniają dane i funkcje w sposób ustandaryzowany. W lutym 2025 r. ekosystem MCP znacząco się rozwinął – powstało ponad 1000 otwartych konektorów, umożliwiających integrację z popularnymi narzędziami, takimi jak GitHub, Slack czy PostgreSQL. Inspiracją dla MCP była zaś frustracja wynikająca z ograniczeń istniejących rozwiązań, takich jak Language Server Protocol (LSP), które nie spełniały oczekiwań w kontekście integracji AI z narzędziami programistycznymi i innymi systemami. Prace nad MCP były intensywne i iteracyjne. Inżynierowie Anthropic skupili się na stworzeniu protokołu, który byłby zarówno lekki, jak i uniwersalny. Wykorzystano podejście oparte na JSON-RPC (JavaScript Object Notation-Remote Procedure Call), co pozwoliło na szybkie i efektywne komunikowanie się między klientem a serwerem. W trakcie rozwoju MCP Anthropic udostępnił specyfikację protokołu oraz zestawy SDK, które umożliwiły deweloperom łatwe wdrażanie serwerów MCP dla różnych systemów.
JSON-RPC to lekki, bezstanowy protokół zdalnego wywoływania procedur (RPC), który wykorzystuje format JSON do komunikacji między klientem a serwerem. Jego głównym celem jest umożliwienie klientowi wywoływania metod na zdalnym serwerze w sposób przypominający lokalne wywołania funkcji. JSON-RPC charakteryzuje się prostotą, elastycznością oraz niezależnością od transportu, co czyni go popularnym wyborem w wielu aplikacjach sieciowych i systemach rozproszonych. W protokole tym każde żądanie i odpowiedź są niezależne, co oznacza, że serwer nie musi przechowywać informacji o stanie klienta między kolejnymi wywołaniami. Sam standard zaś definiuje tylko podstawowe struktury danych i komendy, co minimalizuje narzut komunikacyjny. JSON-RPC może być używany z różnymi mechanizmami przesyłania danych, takimi jak HTTP, WebSocket czy gniazda sieciowe, i umożliwia wysyłanie kolejnych żądań do serwera bez konieczności czekania na odpowiedź, a same żądania mogą być obsługiwane asynchronicznie. JSON-RPC został po raz pierwszy zaprezentowany w 2005 r. jako alternatywa dla XML-RPC, oferując prostszy format danych dzięki wykorzystaniu JSON-a. Wersja 2.0, opublikowana w 2010 r., wprowadziła istotne ulepszenia takie jak obsługa nazwanych parametrów, precyzyjniejsze kody błędów oraz możliwość introspekcji metod. Programiści Anthropic wykorzystali zatem już dobrze znane, przetestowane i wielokrotnie implementowane podejście, zamiast wymyślać coś od samych podstaw, co zwiększałoby ryzyko błędów i wymagało więcej czasu.
Chociaż MCP nie jest jeszcze formalnie uznawany przez organizacje standaryzacyjne takie jak IEEE czy ISO, jego rosnąca adaptacja wskazuje na potencjał zostania de facto standardem w dziedzinie integracji AI z systemami zewnętrznymi. Dzięki swojej uniwersalności i otwartości MCP może stać się podstawą dla przyszłych rozwiązań w zakresie interoperacyjności sztucznej inteligencji.
Architektura protokołu MCP
Jak już wspomnieliśmy, MCP oparty jest na architekturze klient–serwer. Komponentów ekosystemu jest jednak trochę więcej. Aplikacje końcowe, zintegrowane środowiska programistyczne (IDE) lub narzędzia AI, które wykorzystują MCP do pozyskiwania kontekstu dla modeli językowych, nazywamy hostami MCP (MCP Host). Pełnią rolę interfejsu użytkownika, inicjując żądania i prezentując wyniki. Przykładem może być IDE żądające od MCP analizy kodu z repozytorium GitHuba. Klient (MCP Client) jest odpowiedzialny za utrzymanie połączenia z serwerem MCP oraz tłumaczenie operacji pomiędzy hostem a serwerem. Każdy klient obsługuje wyłącznie jeden serwer, co zapewnia izolację i bezpieczeństwo połączeń. Ponadto zarządza cyklem życia sesji, autoryzacją oraz formatowaniem danych zgodnie ze specyfikacją MCP. Serwery MCP (MCP Server) to lekkie programy działające jako adaptery między MCP a konkretnymi systemami lub danymi. Każdy serwer udostępnia zestaw predefiniowanych funkcji, takich jak wyszukiwanie w bazach i innych źródłach danych czy integracja z zewnętrznymi narzędziami. Same źródła mogą być lokalne (pliki na dyskach lokalnej macierzy czy bazy SQL/NoSQL) lub zdalne (chmurowe usługi analityczne, usługi typu Storage, API zewnętrznych aplikacji). W przypadku zdalnych źródeł serwery MCP pełnią rolę warstwy abstrakcji, ukrywając szczegóły techniczne przed modelami AI.
Mimo tego że MCP jest protokołem bardzo młodym, wydaje się, że idealnie trafił w zapotrzebowanie rynku. Na stronie Awesome MCP Servers (bit.ly/42Yo4KB) znajdziemy rekomendację wielu projektów, które w praktyce implementują ten standard w różnych obszarach. Znajdziemy tam m.in. projekt Johna Capobianco (bit.ly/4ktY9QT) – byłego pracownika Cisco i jednego z pionierów wdrażania mechanizmów automatyzacji sieci w połączeniu z AI. Pokazuje on, w jaki sposób serwer MCP można łączyć z biblioteką pyATS i tworzyć rozwiązania, które pozwolą na interakcję z urządzeniami sieciowymi. Na liście rekomendowanych uwadze serwerów MCP znajdziemy też narzędzia umożliwiające komunikację z dowolnymi zdalnymi urządzeniami za pomocą protokołu SSH, a także wykonywanie kodu napisanego w języku Python czy JavaScript w środowisku izolowanym (sandbox). Lista projektów jest ciągle rozwijana. Zauważmy, że kod każdego z rekomendowanych serwerów MCP nie jest nadmiernie rozbudowany ani skomplikowany w swojej składni. Należy więc się spodziewać, że wiele otwartych rozwiązań ujrzy jeszcze światło dzienne w najbliższych tygodniach i miesiącach.
Autor
Piotr Wojciechowski
Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Jest twórcą modułów do Docker Swarm w Ansible’u i jednym z opiekunów modułów w community.docker. Pracuje jako niezależny konsultant IT, posiada certyfikat CCIE.
