MCP: jak działa Model Context Protocol

LLM-y od pewnego czasu potrafią wywoływać narzędzia, ale Model Context Protocol (MCP) wprowadza do tego uporządkowany, ustandaryzowany sposób.

Nadal jednak nie ma jasności, czym MCP właściwie jest.

Wiele osób zakłada, że MCP to aplikacja, API albo jakieś narzędzie, ale nie jest żadną z tych rzeczy. To protokół, a to oznacza coś bardzo konkretnego.

Rozłóżmy to na części.

Jeśli chcesz tylko zobaczyć, co MCP umożliwia w praktyce, obejrzyj ten krótki film:

Czym jest protokół?

Protokół to po prostu zestaw reguł, które określają, jak dwa lub więcej systemów komunikują się ze sobą.

Sam z siebie nic nie robi. Definiuje jedynie strukturę i oczekiwania dotyczące rozmowy między dwoma podmiotami. Możesz myśleć o nim jak o wspólnym języku ze ścisłymi zasadami gramatyki, którego komputery używają do wymiany informacji.

Systemy pocztowe działają podobnie. Wszystkie urzędy pocztowe w danym kraju stosują ustandaryzowany format adresu, aby wysyłać listy.

Możesz też myśleć o tym jak o USB-C dla narzędzi AI. Dwadzieścia lat temu rynek był zalany różnymi typami kabli do ładowania i przesyłania danych. Podobnie ekosystemy AI miały wiele sposobów przekazywania narzędzi do modeli językowych. Frameworki takie jak LangChain, Haystack i Pydantic AI definiowały własne formaty integracji narzędzi, co oznaczało, że jeśli developer chciał napisać zestaw narzędzi dla Google Maps, musiał zrobić to dla każdej konkretnej technologii.

Aby pokazać to bardziej konkretnie, spójrzmy na najpopularniejszy protokół, HTTP (Hypertext Transfer Protocol), który obsługuje strony internetowe. HTTP definiuje między innymi, jak przeglądarka (klient) żąda strony od serwera WWW i jak serwer powinien odpowiedzieć.

Oto przykład cyklu żądanie-odpowiedź HTTP:

1. Przeglądarka wysyła żądanie HTTP

Gdy wpisujesz https://example.com w przeglądarce, przeglądarka wysyła ustrukturyzowane żądanie HTTP do serwera WWW:

Oto parametry i wartości HTTP użyte w naszym przykładzie:

"GET" – To jest akcja (żądanie strony internetowej).
"/index.html" – Konkretna strona internetowa, której dotyczy żądanie.
"HTTP/1.1" – Wersja używanego protokołu.
"Host: example.com" – Nazwa domeny strony internetowej.
"User-Agent: Mozilla/5.0" – Informacje o przeglądarce wysyłającej żądanie.

Serwer WWW wie, jak zinterpretować to żądanie, ponieważ HTTP standaryzuje ten format. Rozumie ten „język”.

2. Serwer odpowiada przy użyciu protokołu HTTP

Serwer przetwarza żądanie i odsyła ustrukturyzowaną odpowiedź HTTP:

"HTTP/1.1 200 OK" – Kod odpowiedzi (200 oznacza powodzenie).
"Content-Type: text/html" – Typ odsyłanej treści.
"Content-Length: 512" – Rozmiar odpowiedzi.
HTML Content – Właściwa treść strony internetowej (jest tam tylko nagłówek „Welcome to Example.com”)

Ważne: sam HTTP nie przechowuje stron internetowych ani ich nie wyświetla. Definiuje tylko reguły, według których przeglądarki i serwery WWW mogą się komunikować. Każdy system, który przestrzega tych reguł, może komunikować się przez Internet zdefiniowany przez HTTP.

Jak MCP działa jako protokół

Teraz zastosujmy to samo rozumowanie do MCP (Model Context Protocol).

MCP to protokół, który pozwala agentom AI komunikować się z zewnętrznymi narzędziami i źródłami danych. Podobnie jak HTTP, sam nie przechowuje danych ani nie wykonuje zadań. Definiuje po prostu ustandaryzowany sposób, w jaki AI może żądać i pobierać informacje z narzędzi.

Możesz zapytać, czym są te „narzędzia”.

W kontekście LLM-ów narzędzia to zewnętrzne systemy, API lub usługi, z którymi AI może wchodzić w interakcję, aby rozszerzyć swoje możliwości poza samo generowanie tekstu. Pozwalają agentom AI pobierać dane w czasie rzeczywistym, umawiać spotkania albo wysyłać wiadomości do znajomych, dzięki czemu są znacznie bardziej użyteczne w rzeczywistych zastosowaniach.

Załóżmy, że pytasz agenta AI:

„Która jest teraz godzina w Londynie?”

Ponieważ sama AI nie zna prawidłowej odpowiedzi, bo modele AI mają datę odcięcia wiedzy (październik 2023 dla modeli OpenAI), musi pobrać aktualne dane z usługi czasu. Ale zamiast używać HTTP do żądania strony internetowej, AI używa MCP do żądania danych o czasie.

Oto, co się dzieje:

1. Agent AI wysyła żądanie MCP do usługi czasu (przykład)

"method": "tools.call" → AI wywołuje zewnętrzne narzędzie.
"tool": "get_time" → Nazwa narzędzia, którego chce użyć.
"args": { "location": "London" } → Konkretne parametry wejściowe.

Podobnie jak w HTTP, to żądanie ma ścisły format, dzięki czemu każde narzędzie zgodne z MCP dokładnie wie, jak je zinterpretować.

2. Serwer czasu MCP odpowiada

Zewnętrzne narzędzie (serwer czasu) przestrzega reguł odpowiedzi MCP i odsyła:

"status": "success" → Potwierdza, że żądanie zostało poprawnie przetworzone.
"result" → Zawiera właściwe dane o czasie.

Teraz agent AI może wziąć te dane i przygotować rzeczywistą odpowiedź dla użytkownika:

„Aktualna godzina w Londynie to 12:20 PM (GMT).”

Podsumujmy i usuńmy niejasności:

„MCP to aplikacja.” → Nie, MCP to zestaw reguł. Aby faktycznie go używać, potrzebujesz oprogramowania AI i narzędzi, które implementują MCP, tak jak aplikacja Instagram potrzebuje działających serwerów Instagram, aby odpowiadać na żądania HTTP i dostarczać dane.

„MCP to baza danych.” → Nie, MCP nie przechowuje danych. Pomaga agentom AI komunikować się z bazami danych lub API.

„MCP jest jak API.” → Nie do końca. API to konkretny sposób interakcji z jednym systemem, natomiast protokół (taki jak MCP lub HTTP) definiuje uniwersalny sposób, w jaki wiele różnych systemów może się komunikować. MCP to język, którego system AI może używać do interakcji z wieloma rzeczywistymi API (czas, bazy danych, Stripe, Slack itd.).

Dlaczego MCP jest interesujące

Skoro wiemy już, że MCP to ustandaryzowany sposób interakcji oprogramowania AI z zewnętrznymi narzędziami i aplikacjami oraz że MCP nie jest API, zobaczmy, dlaczego społeczność developerów AI (w tym my) tak się nim zainteresowała.

Ponieważ MCP nie jest API, ale pozwala aplikacjom AI w skali korzystać z rzeczywistych API, pomaga szybciej uruchamiać projekty wymagające połączenia z wieloma zewnętrznymi systemami. Narzędzia zwiększają też zasięg modelu, a to, co wydarzyło się w incydencie OpenAI Hugging Face, pokazuje, jak wygląda taki zasięg, gdy wykracza poza zadanie. Aby to zrobić, developerzy czasem musieliby przejść przez pełny cykl tworzenia integracji API, ale dziś zwykle korzystają z istniejących bibliotek lub projektów open-source (na przykład dostępnych na GitHub), które zapewniają potrzebną funkcjonalność.

Użycie takich bibliotek przyspiesza development, ale poprawna integracja ich z twoim systemem (jeśli nie jest zgodny z implementacją znalezioną na GitHub) nadal wymaga pracy, aby narzędzie działało z AI.

Dzięki MCP, gdy framework jest już gotowy, dodanie nowej integracji (powiedzmy, integracji Google Drive) może sprowadzić się do połączenia z serwerem MCP Google Drive kilkoma liniami kodu. Nie napotkasz problemów ze zgodnością, ponieważ obie strony używają tego samego protokołu: MCP.

Porównajmy oba podejścia, aby lepiej zobaczyć różnice.

Standardowa integracja a użycie Model Context Protocol (MCP)

Aby porównanie było konkretne, przejdźmy przez dodanie dostępu do plików Google Drive do Agenta AI, najpierw ręcznie, a potem z użyciem narzędzia zgodnego z MCP.

Standardowa integracja

1. Znajdź i dostosuj bibliotekę: szukasz klienta API Google Drive lub projektu open-source. Google udostępnia biblioteki klienckie (np. Google Drive API for Python), dodajesz je do swojego projektu. Nadal musisz upewnić się, że działają w środowisku twojej AI.

2. Zaimplementuj logikę: piszesz funkcje, na przykład do wyszukiwania plików lub pobierania dokumentu z Drive. Gdy AI czegoś potrzebuje, musi wywołać te funkcje. Formatujesz żądanie AI do wywołań specyficznych dla API Google Drive. Po otrzymaniu odpowiedzi od Google wyodrębniasz treść, aby przekazać ją z powrotem do kontekstu AI.

3. Obsłuż błędy i przypadki brzegowe: dodajesz kod obsługujący sytuacje takie jak „file not found”, błędy uprawnień lub limity wywołań API. Jeśli API Google zwróci błąd, przechwytujesz go i ewentualnie odpowiadasz przepraszającą wiadomością albo prosisz AI o przeformułowanie. Musisz też zabezpieczyć się przed tym, że AI wyśle zbyt wiele żądań zbyt szybko.

4. Utrzymuj: z czasem, jeśli Google zaktualizuje swoje API lub bibliotekę, musisz zaktualizować kod. Jeśli znajdziesz błąd w bibliotece, być może trzeba będzie go poprawić lub znaleźć inne źródło. W praktyce stajesz się maintainerem tej integracji Google Drive w swojej aplikacji AI.

Ten proces dotyczy też innych narzędzi: chcesz dodać Slack albo bazę danych do swojej AI? Musisz powtórzyć cały proces dla każdego z nich.

Integracja MCP

Zobaczmy teraz, jak ten proces wyglądałby z użyciem MCP.

Najpierw zdefiniujmy kluczowe pojęcia:

Client – aplikacja AI (ChatGPT, Claude app, Quickchat AI), która ustanawia połączenie z jednym lub większą liczbą serwerów i żąda informacji albo akcji potrzebnych do wykonania zadań zleconych przez użytkownika.

Server – każdy serwer może łączyć się z czymś takim jak baza danych, API (Google Drive) i definiować zestaw „narzędzi” lub danych, które może udostępniać. W tym przypadku server to program, który udostępnia te narzędzia i możliwości Client (aplikacji AI).

Developerzy, zależnie od tego, co chcą zrobić, mogą wybrać dowolną stronę: zbudować serwer, który udostępnia dane, albo zbudować klienta AI, który potrafi komunikować się z dowolnymi serwerami. Większość chce tej drugiej opcji, ale mimo to zacznijmy od strony serwera, aby zrozumieć krok po kroku, jak działa MCP:

• Inicjalizacja serwera MCP. Developer lub administrator systemu konfiguruje serwer MCP dla danego narzędzia lub źródła danych. Serwer MCP to zwykle po prostu mały program, który implementuje specyfikację MCP. Na przykład dostępny jest gotowy serwer MCP Google Drive, który wie, jak wyszukiwać i pobierać dokumenty.

  Podczas inicjalizacji serwera dajesz mu dostęp do systemu docelowego (Google Drive). Serwer następnie udostępnia zestaw narzędzi odpowiadających akcjom lub zapytaniom, które potrafi obsłużyć. To w istocie adapter API, który po jednej stronie mówi MCP, a po drugiej językiem natywnej usługi.

  Gdy serwer działa, czeka na żądania.

• Łączenie LLM-a (client) z serwerem MCP. Następnie aplikacja AI (strona „client”) musi połączyć się z tym serwerem. W praktyce, jeśli używasz platformy AI obsługującej MCP (takiej jak Claude Desktop), konfigurujesz ją, podając adres lub komendę uruchamiającą serwer. Po połączeniu client ustanawia sesję z serwerem zgodnie z handshake MCP. Jeśli używasz interfejsu Claude, zobaczysz, że Claude jest „connected” z określonymi serwerami MCP (UI może wskazywać dostępne konektory).

Tak wygląda to w Claude UI

• Odkrywanie dostępnych narzędzi. Po ustanowieniu połączenia pierwszą rzeczą jest sprawdzenie, co serwer oferuje (czasem dzieje się to automatycznie po połączeniu z serwerem). Client MCP wysyła do serwera żądanie tools/list (jest ono zdefiniowane w protokole). Serwer odpowiada listą dostępnych narzędzi, każde ze szczegółami takimi jak nazwa, opis i schemat wejścia.

  Na przykład serwer może odpowiedzieć, że ma dostępne narzędzia create_file(path, content), read_file(path) i search_files(query). Client następnie udostępnia te informacje LLM-owi. W wielu implementacjach client sformatuje opisy narzędzi i dołączy je do kontekstu modelu (na przykład dodając do promptu systemowego: „Masz dostęp do następujących narzędzi… [lista narzędzi]”).

Oto prompt systemowy AI wraz z wiadomością użytkownika proszącą o aktualną godzinę

Po zaimplementowaniu narzędzi MCP zintegrowane jest narzędzie o nazwie „get_current_time”, które pozwala AI uzyskać dostęp do zewnętrznego zasobu i pobrać dokładny czas w Londynie

To oznacza, że nie musisz z góry przewidywać i programować wszystkich potencjalnych akcji, których twoja aplikacja AI może potrzebować do wykonania jakiegoś zadania. Dzięki MCP AI może odkrywać wszystkie możliwe akcje w locie, pytając serwer MCP, i wybierać to, czego potrzebuje.

• Używanie narzędzia przez MCP. Gdy AI musi wykonać akcję lub pobrać dane, wywoła narzędzie przez MCP. Z perspektywy AI (szczególnie dla modeli takich jak Claude, które natywnie obsługują użycie narzędzi) model zdecyduje w swoim rozumowaniu: „Powinienem wywołać narzędzie X z tymi parametrami”. Client MCP przechwytuje tę intencję i wysyła żądanie tools/call w formacie MCP do odpowiedniego serwera (serwera MCP Google Drive).

• Serwer MCP działa jak most. Otrzymuje od agenta AI ustrukturyzowane żądanie zgodne z MCP, mapuje je na właściwy endpoint API Google Drive, przepisuje żądanie na rzeczywiste wywołanie API Google Drive, wykonuje żądanie, przetwarza odpowiedź i ponownie formatuje ją jako odpowiedź zgodną z MCP przed odesłaniem do agenta AI.

  Warto zauważyć, że serwery MCP stosują ustrukturyzowane podejście do obsługi błędów, dzięki czemu Agenci AI mogą je skutecznie interpretować i na nie reagować.

  Załóżmy, że Agent AI używa narzędzia MCP do znalezienia pliku w Google Drive. Jeśli żądanie zawiera nieprawidłowy identyfikator pliku (np. pięcioznakowy ciąg zamiast oczekiwanego formatu), serwer MCP zwróci komunikat błędu:

  Zamiast po prostu zakończyć się niepowodzeniem, Agent AI może wziąć tę ustrukturyzowaną odpowiedź i przeformułować ją jako przyjazną informację zwrotną dla użytkownika:

  “Wygląda na to, że podany identyfikator pliku jest za krótki. Identyfikatory plików Google Drive mają zwykle 28 znaków. Sprawdź go i spróbuj ponownie.”

  Takie podejście sprawia, że błędy nie prowadzą do ślepych zaułków, lecz stają się okazją, by Agent AI poprowadził użytkownika do skutecznego rozwiązania.

• Odpowiadanie na pytanie/prośbę użytkownika. Gdy serwer MCP zwróci wynik, client MCP przekazuje te dane z powrotem do aplikacji AI. Model następnie uwzględnia wynik w swoim rozumowaniu albo bezpośrednio w odpowiedzi generowanej dla użytkownika.

  Jeśli użytkownik poprosi o utworzenie nowego pliku Google Sheets, odpowiedź serwera (zawierająca identyfikator pliku i wygenerowany link) zostanie przekazana do modelu. Model odpowie wtedy użytkownikowi: „Dobra wiadomość! Twój nowy plik Google Sheets jest gotowy. Możesz uzyskać do niego dostęp tutaj: [link].”

W całym tym procesie AI zachowuje kontrolę nad przebiegiem: decyduje, kiedy wywołać narzędzie i jak użyć wyniku do sformułowania odpowiedzi. Jednocześnie developer nie musi ręcznie orkiestracyjnie układać tych kroków, robią to framework MCP i model AI. Efekt końcowy jest taki, że użytkownik może zadać AI złożone pytania lub zadania wymagające zewnętrznych informacji albo akcji, a AI może autonomicznie je wykonać przez MCP i zwrócić wynik.

Korzyści z użycia MCP

Zauważ, jak to podejście ukrywa wiele szczegółów: client nie obsługiwał kluczy API ani kodów statusu HTTP, tym zajmuje się serwer MCP.

Najważniejsza jest prostota punktu integracji: „prosimy” o klientów i ich otrzymujemy. Logika pobierania jest zamknięta gdzie indziej. Oznacza to, że developer pracujący po stronie AI nie musi pisać nowych wywołań HTTP dla każdej nowej akcji, po prostu wywołuje narzędzia po nazwie. Ciężka praca (uwierzytelnianie, wywoływanie endpointów Google Drive, formatowanie odpowiedzi) odbywa się w kodzie serwera MCP, który jest wielokrotnego użytku i ustandaryzowany.

Oto podsumowanie najważniejszych korzyści:

• Ogranicza kod łączący specyficzny dla API. Przed MCP sprawienie, aby AI używała zewnętrznej usługi, zwykle wymagało napisania sporej ilości kodu „klejącego”: wywołania API, przekształcenia odpowiedzi w tekst zrozumiały dla modelu, potem parsowania wyjścia modelu, aby ewentualnie wywołać kolejne API itd. Dzięki MCP duża część tego kodu znika. Client modelu i serwer obsługują wymianę danych w ustrukturyzowany sposób, więc nie musisz ręcznie przekształcać innych formatów (takich jak JSON) na tekst ani odwrotnie, robi to protokół. Nie musisz też pisać logiki decydującej, co i kiedy wywołać. Robi to AI (kierowana opisami narzędzi oraz własnym rozumowaniem lub promptem).

• Współdzielone konektory wielokrotnego użytku zamiast jednorazowych wrapperów API. Dzięki MCP piszesz integrację raz i możesz używać jej w wielu projektach oraz systemach AI. Na przykład możesz utworzyć serwer MCP dla wewnętrznej wiki swojej firmy. Każda aplikacja AI obsługująca MCP może połączyć się z tym jednym serwerem, aby odpytywać wiki. Nie musisz ponownie implementować „wyszukiwania w wiki” dla każdego nowego chatbota AI lub każdego innego dostawcy LLM. Ta wielokrotna używalność to zmiana względem przeszłości, gdy każdy zespół mógł pisać własną, nieco inną integrację z tym samym API. MCP zachęca do tworzenia biblioteki konektorów, które można współdzielić i wspólnie ulepszać.

• Integracja plug-and-play z różnymi LLM-ami. MCP jest niezależny od modelu. Protokół nie przejmuje się tym, czy clientem jest Claude, GPT-4, DeepSeek czy jakikolwiek przyszły model, o ile client potrafi obsłużyć interfejs MCP. W przyszłości, jeśli zechcesz przejść na inny model, możesz to zrobić bez przepisywania wszystkich integracji.

• Łatwiejsze utrzymanie. Ponieważ to otwarty standard, rośnie społeczność, która dostarcza gotowe serwery (dla baz danych, popularnych API itd.), z których możesz skorzystać zamiast budować wszystko od zera. Gdy integrujesz więcej systemów, MCP pomaga uniknąć „spaghetti” wielu integracji punkt-punkt. Nie musisz też śledzić wszystkich aktualizacji API od innych dostawców.

Czy integracje API staną się przestarzałe?

Zarówno tradycyjne integracje API, jak i MCP mają swoje miejsce. Najlepsze podejście zależy od charakteru projektu, kompetencji zespołu i długoterminowych celów.

Jeśli potrzebujesz integracji tylko z jedną lub dwiema zewnętrznymi usługami, a interakcje są dość proste, bezpośrednia integracja API często jest najszybszym rozwiązaniem. Jeśli twoja aplikacja webowa musi tylko zweryfikować token płatności Stripe przy checkout, bezpośrednie wywołanie API Stripe jest proste i skuteczne. Wprowadzanie MCP w takim scenariuszu może być przesadą. Możesz połączyć Agenta AI z dowolnym udokumentowanym REST API za pomocą jednej sprawdzonej HTTP Action albo użyć integracji jednym kliknięciem, takiej jak Google Sheets do zapisywania leadów i próśb o demo, bez uruchamiania serwera MCP.

W przypadkach, gdy potrzebujesz bardzo ścisłej kontroli nad żądaniem/odpowiedzią (w celu strojenia wydajności, specjalnej obsługi danych lub obsługi zastrzeżonych protokołów), bezpośrednie pisanie do API może być lepsze. Tradycyjne integracje pozwalają używać wszystkich zaawansowanych funkcji API i precyzyjnie dostosować wywołania. Jeśli API ma nietypowe wymagania albo chcesz uniknąć jakiejkolwiek warstwy abstrakcji dla maksymalnej przejrzystości i kontroli, podejście tradycyjne jest odpowiednie.

Aby zobaczyć konkretny przykład, jak narzędzia MCP są udostępniane produkcyjnemu Agentowi AI obok niestandardowych akcji API, zobacz, jak Quickchat AI Agents łączą oba podejścia. Głębsze omówienie tego, kiedy używać MCP, pojedynczych AI Actions lub „Generate from Text”, znajdziesz w APIs for AI Agents: From MCP to Custom Endpoints. Aby wypróbować to samodzielnie, skorzystaj z przewodnika krok po kroku, jak połączyć swojego Agenta AI ze zdalnym serwerem MCP, aby wywoływał działające narzędzie w trakcie rozmowy.

Lista dostępnych serwerów MCP

Jeśli chcesz zacząć pracę z MCP, sprawdź poniższe katalogi serwerów MCP:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Możesz też uruchomić jeden bez pisania kodu: każdy Quickchat AI Agent może zostać przekształcony w serwer MCP z hostowanym URL, który Claude, ChatGPT i Cursor wywołują jako narzędzie. Połączenie działa też w drugą stronę: Quickchat AI Agent może wywoływać hostowany serwer MCP dostawcy jako swoje narzędzia. W ten sposób asystent AI do umawiania spotkań zbudowany na serwerze MCP Calendly sprawdza rzeczywistą dostępność i rezerwuje spotkania z czatu, a chatbot Notion AI odpowiada z aktywnego help center i zapisuje zgłoszenia supportowe z powrotem do bazy danych Notion.

Quickchat AI uruchamia też zdalny serwer MCP dla twojego konta. Połącz go z ChatGPT, Claude, Cursor lub Codex, a będziesz mógł zarządzać stamtąd swoimi AI Agents: analityką, transkryptami rozmów, aktualizacjami bazy wiedzy i tworzeniem nowych Agentów, za jednym logowaniem OAuth. Instrukcję konfiguracji dla każdego clienta znajdziesz w Manage Your AI Agent from ChatGPT, Claude, and Codex with MCP.

FAQ

Czy MCP działa tylko z Claude?

MCP jest niezależny od modelu. Protokół nie przejmuje się tym, czy clientem jest Claude, GPT-4, lokalna pochodna LLaMA czy jakikolwiek przyszły model, o ile client potrafi obsłużyć interfejs MCP. Oznacza to, że budując integracje narzędzi, nie jesteś związany z jednym dostawcą AI.

Czym MCP różni się od przekazania modelowi wszystkich potrzebnych informacji z góry? Dlaczego nie upchnąć danych w prompcie?

MCP zasadniczo różni się od upychania danych w prompcie modelu, ponieważ pozwala modelowi dynamicznie pobierać informacje wtedy, gdy są potrzebne, zamiast pracować ze statycznym, wstępnie załadowanym promptem. Upychanie tekstu w prompcie napotyka ograniczenia, ponieważ modele AI mają stałe okno kontekstu, co oznacza, że zbyt duża ilość danych może spowodować utratę ważnych szczegółów, spowolnić odpowiedzi i zwiększyć koszty API (ze względu na modele cenowe per token stosowane przez dostawców LLM). Daje też wiedzę tylko z jednego punktu w czasie, podczas gdy MCP umożliwia dostęp w czasie rzeczywistym do aktualnych danych zewnętrznych i pozwala AI wykonywać działania, a nie tylko czytać informacje. AI z przeładowanym promptem może znać szczegóły klienta, ale nie będzie w stanie zaktualizować rekordów ani przetworzyć transakcji.

Co jeśli podłączymy do AI dziesiątki narzędzi? Czy to nie przytłoczy modelu albo nie spowoduje ich błędnego użycia?

To zależy od implementacji, ale prawdą jest, że obecne LLM-y mają ograniczenia w rozróżnianiu i wybieraniu spośród wielu opcji. Jeśli przedstawisz modelowi na przykład 50 możliwych narzędzi, istnieje ryzyko, że wybierze niewłaściwe. Samo podejście MCP nie zmusza cię do ładowania wszystkiego naraz. Należy podłączać odpowiednie narzędzia w zależności od kontekstu. Dobrą praktyką jest podłączanie tylko narzędzi potrzebnych do danego zadania/domeny i wykorzystanie współpracy multiagentowej, czyli rodzaju routingu narzędzi lub agenta, który najpierw decyduje, jaki podzbiór narzędzi wziąć pod uwagę.

MCP a Function Calling

Tradycyjne function calling (znane z API OpenAI lub innych LLM-ów) pozwala developerowi zdefiniować zestaw funkcji, przekazać ich definicje modelowi i sprawić, aby model „wywoływał” je po nazwie z argumentami. To był duży krok w integracji AI, ale ma ograniczenia. Jedna z głównych różnic dotyczy tego, kiedy i jak definiowane są narzędzia. W klasycznym function calling wszystkie możliwe funkcje muszą zostać zadeklarowane z góry (na etapie projektowania) w prompcie lub przez API. Model może wywoływać tylko te stałe funkcje. W MCP narzędzia są odkrywalne w czasie działania, AI może zapytać, co jest dostępne, a nawet otrzymać nowe narzędzia w trakcie sesji.

MCP a GPT Actions i Plugins

GPT Actions/Plugins odnoszą się do ekosystemu OpenAI, w którym można było włączać pluginy (takie jak przeglądarka internetowa lub czytnik PDF) dla ChatGPT albo „GPTs” (niestandardowych agentów ChatGPT), które mogą używać narzędzi. Było to interesujące, ale wymagało niestandardowego developmentu dla każdego pluginu i było ograniczone do platform OpenAI. Jeśli chciałeś plugin ChatGPT do danego zadania, musiałeś utworzyć API i manifest, a następnie przejść przez zatwierdzenie OpenAI albo co najmniej włączyć go ręcznie. Każdy plugin był zasadniczo silosem, plugin pogodowy, podróżniczy itd., każdy z własnymi endpointami i logiką. MCP ulepsza tę koncepcję przez ujednolicenie i otwarcie jej.

MCP a RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) to technika, w której LLM jest uzupełniany zewnętrzną bazą wiedzy. Zwykle RAG obejmuje bazę wektorową lub indeks wyszukiwania: zapytanie użytkownika jest używane do pobrania odpowiednich dokumentów lub danych (przez wyszukiwanie semantyczne albo inne metody), a te dokumenty są przekazywane modelowi jako dodatkowy kontekst do „przeczytania” podczas tworzenia odpowiedzi. RAG polega na dostarczeniu modelowi wiedzy, której pierwotnie nie miał, co jest szczególnie pomocne w faktograficznym QA lub informacjach specyficznych dla domeny. Jednak RAG jest tylko do odczytu, model pobiera fragmenty tekstu, ale nie wykonuje działań poza pobieraniem.

MCP natomiast dotyczy wykonywania działań lub przeprowadzania dowolnych operacji, a nie tylko pobierania kontekstu informacyjnego. Dzięki MCP AI może robić rzeczy: zapisywać dane w bazie, wysyłać e-mail, wykonywać kod itd. Nie ogranicza się do pobierania wiedzy, może wywoływać zmiany w zewnętrznych systemach. Dlatego pod wieloma względami RAG i MCP służą różnym celom.