Do you speak MCP?

„Prawdziwy postęp dokonuje się nie w chwili,

gdy znajdujemy odpowiedzi na dawno postawione pytania,

lecz wtedy, gdy samo ich zadawanie traci sens”

Ludwig Wittgenstein

Język jest głównym medium komunikacji. Inne sposoby jak obraz, mowa ciała, gesty, emocje i inne pozasłowne formaty tylko go uzupełniają. W świecie pęczniejącym od ciśnienia na AI można domniemać, że ta zasada prawdopodobnie zostanie wzmocniona. Stanie się tak dlatego, że różnorodność i w konsekwencji bariery językowe tworzące biblijną wieżę Babel powoli przestają istnieć, AI (już od dawna) pozwala na tłumaczenie z dowolnego języka na inny dowolny. To pierwszy argument. Kolejny (może ważniejszy), to rodzaj strawy której AI używa do nauki. AI uczy się odczytując naszą inteligencję zakodowaną w tekstach znalezionych w przepastnych przestrzeniach internetu. Uczy się także na podstawie obrazów i video, ale to język w postaci tekstu jest wciąż głównym źródłem, bo właśnie tekst (jako cyfrowa postać języka) jest naszą inteligencją najbardziej nasączony.

W tym kontekście można by się zastanowić nad kwestią fundamentalną. To, że przyszłość to AI, już wiemy, ale czy AI będzie monolitem, unikalnym i pojedynczym tworem, czy raczej będzie konglomeratem komponentów, bytem złożonym, społecznym wręcz, no właśnie,  jak to będzie? Sądzę, że powinniśmy jako bardziej prawdopodobną rozważać tę drugą opcję. Skoro tak, skoro mamy mieć wielo-byt, multi-komponentowość, to oczywistym pytaniem jest, jak te byty będą się komunikować, jakim językiem, formatem, protokołem? Jaki będzie wewnętrzny język AI?

Szukając analogii, zauważmy, że w niedawnych czasach usług SOA, mieliśmy SOAP i WSDL, co do idei bardzo formalne standardy mogące definiować pełnoprawny język komunikacji. Tak się stało, jednak pewne słabo rozwiązane szczegóły implementacyjne, dające dużą zawiłość, sprawiły, że dzisiaj używamy bardziej API REST’a, niestety ze słabo przyjętym WADL’em oraz znacznie lepiej OpenAPI. Ta historia z kręgu SOA wpisuje się w zasadę, że tam gdzie są komponenty, gdzie jest podział i rozproszenie, potrzebny jest język komunikacji.

Wracając do AI, czy w tym obszarze powstają jakieś analogiczne do SOA rozwiązania? Model Context Protocol (MCP) to protokół, format, język, który zaproponowała firma Anthropic (jeden z liderów rynku AI). Jest to bardzo świeży temat, trudno mówić na razie o przemysłowym standardzie, ale jest to chyba pierwszy, sensowny ruch w tym kierunku. Schemat architektury wykorzystującej MCP może wyglądać tak

AI Client, czyli jakaś forma systemu, aplikacji, która pozwala nam „obcować z AI”, aby dostarczyć nam możliwości które dają usługi (np. wysyłka maila, założenie spotkania w kalendarzu, odczyt jakieś informacji z bazy danych, itp.) konwersuje z Agentem AI, który to prowadzi rejestr dostawców takich usług (Tools Registry). Agent, do każdego z dostawcy (Tool), za pomocą protokołu MCP, wysyła zapytanie o katalog czynności które może on (w ramach usługi) dla nas wykonać (service discovery), a następnie wiedza ta służy silnikowi AI (zazwyczaj oparty o LLM) do automatyzowania pracy (AI automation) właśnie za pomocą dostępu do tych wszystkich usług i czynności. Katalog ten zawiera jednocześnie opis metod składowych usługi (LLM musi przecież jakoś zrozumieć kto i co umie robić), jaki i jej parametrów wejściowych i wyjściowych (taki jakby WSDL, LLM musi przecież zrozumieć, jak je wywoływać). Pięknie. Dzięki temu, że mamy MCP, wszystkie usługi na świecie (tak naprawdę te które implementują ten protokół, więc nie wszystkie, ale może kiedyś … ), są łatwo, bez pisania kodu, „integrowalne” z naszym Agentem AI.

Co to może dla nas oznaczać? Wyobraźmy sobie komputer, a w zasadzie jakiś interfejs komunikacyjny z komputerem, niekoniecznie klawiatura i myszka, bardziej ekran z mikrofonem i głośnikiem, któremu możemy głosowo, w języku naturalnym i w konwersacyjny sposób, zlecać wykonywanie zadań, oglądać ich wyniki lub odsłuchać odpowiedzi na pytania, możemy z nim po prostu porozmawiać i coś mu kazać zrobić. To w zasadzie dzisiaj już prawie mamy. Ale wyobraźmy sobie, że nasze banki, dostawcy jedzenia, pkp, taksówki, systemy ERP w naszej firmie, a nawet proste aplikacje desktopowe, zegarki, drukarki i dosłownie cokolwiek co możemy sobie wyobrazić a ma procesor i implementuje MCP. Gdyby tak było, wtedy ten nasz mądrala z którym konwersujemy, umie sprawdzić stan konta, ostrzec przed przelewem powyżej pewnej kwoty, podać wydatki na paliwo w tym miesiącu, roku, zamówić nam pizzę taką jak ostatnio, sprawdzić czy jest połączenie pociągiem z rana do Poznania, zamówić taxi do domu z biura, sprawdzić czy sprzedaż z tego miesiąca jest już na poziomie z zeszłego roku, powiedzieć 30 min przed spotkaniem że trzeba się udać w odpowiednie miejsce, zamówić brakujący tusz do drukarki i w zasadzie … wszystko. Rozszerzanie tego katalogu czynności polega wyłącznie na dodawaniu kolejnych dostawców MCP, a samo to rozszerzanie też odbywa się konwersacyjnie … bo ktoś już napisał usługę do tego, także z obsługą MCP oczywiście.

Bajka? No nie specjalnie jest to bajka. Sadzę, że to tylko kwestia czasu, krótkiego, kiedy tak to będzie wyglądać. W „dawnych” czasach mówiło się, że jak chcesz się liczyć w sieci, musisz mieć REST’a. No to mamy nowe hasło „Do you speak MCP?” Nie? No to jak chcesz się liczyć, to powinieneś.