MCP Tools vs API

MCP Tools vs API – porównanie, by lepiej zrozumieć, dlaczego MCP jest potrzebny.

Ogólne założenia niemal identyczne

Część MCP zwana Tools pełni taką samą rolę jak API dostarczane przez niemal każdy serwis, jaki możemy sobie wyobrazić. Swoje API ma Allegro, Wikipedia, a nawet dobrapogoda24.pl! Dzięki API programiści mogą tworzyć programy, które automatycznie np. pobierają pogodę.

Częstym zarzutem w stosunku do MCP jest to, że wygląda jak po prostu nieco podrasowane API. Nic bardziej mylnego. Po pierwsze – jak już, to mówimy tylko o części MCP o nazwie Tools, a po drugie – różnic jest całkiem sporo. API jest stworzone z myślą o tradycyjnym podejściu, gdzie to programista na sztywno ustala komunikację z danym serwerem na podstawie dokumentacji. MCP Tools działa przy założeniu, że programista nie będzie czytał dokumentacji i implementował funkcjonalności w kodzie. Zamiast tego to AI czyta i stara się rozumieć zastosowanie odpowiednich funkcji (zwanych dla zmylenia przeciwnika Tools).

Tradycyjne API miały sens w sytuacji, w której nasza aplikacja nie posiadała żadnej inteligencji ani nawet najmniejszych zdolności programistycznych.

Precyzja requestu / zapytania

API: precyzyjnie opisane metody i parametry MCP Tool: również precyzyjny opis – konieczny, bo serwer odbierający żądanie nie posiada inteligencji interpretującej

W ujęciu tradycyjnym możliwe do wywołania polecenia i parametry są gdzieś spisane w formie jakiejś dokumentacji – zazwyczaj na stronie. Może być prosto i nieco nieprecyzyjnie jak np. dobrapogoda24.pl ([1]). Wówczas programista uradowany prostotą szybko zaimplementuje rozwiązanie, a co najwyżej coś tam nie zadziała, jeśli np. zamiast city=warszawa podamy city=zła wieś wielka.

Inne API mają z kolei solidną dokumentację, gdzie wszystko dopracowano w najmniejszych detalach, np. OpenWeatherMap, gdzie podajemy długość i szerokość geograficzną zamiast nazwy miasta. Bywa różnie.

Zasada jest prosta – opis zapytania musi być precyzyjny. Musi być wiadomo, w jakich jednostkach podajemy np. długość i szerokość geograficzną. Po stronie serwera nie ma miejsca na domysły w stylu „a, bo to w Europie to stopnie Celsjusza, a w USA to pewnie Fahrenheity”. Wszystko musi być jasno zdefiniowane, bo zakłada się, że w tradycyjnym wywołaniu API serwer nie posiada żadnej inteligencji. Ma być precyzyjnie, szybko i niezawodnie.

I w przypadku serwera MCP jest dokładnie tak samo – zapytania również muszą być precyzyjne, bo zakłada się, że serwer MCP raczej nie posiada inteligencji. Dlatego na etapie wywołania metody z parametrami większych różnic koncepcyjnych między tradycyjnym API a MCP Tools nie ma. Fajnie, ale dalej nie będzie już tak prosto.

Odpowiedź

API: duża dokumentacja i dużo pracy po stronie programisty MCP Tools: brak dokumentacji, brak pracy po stronie programisty, interpretacja odpowiedzi przerzucona na AI

Tradycyjne API bardzo precyzyjnie definiują, jak wygląda odpowiedź z serwera. Weźmy OpenWeatherMap. O ile opis samego zapytania jest dość krótki (How to make an API call), to opis odpowiedzi zajmuje kilka ekranów. Trzeba bowiem dokładnie wyjaśnić każde pole i format danych. Programista musi wiedzieć z góry, co konkretnie dostanie. Np. opady podane są w milimetrach na godzinę. Programista czyta to w dokumentacji i już wie, że jak serwer odpowie, że opady to 3, to są to 3 mm/h.

Bez dokumentacji byłoby łatwo o pomyłki, bo serwer nie pisze 3 mm/h, tylko samo 3, a jednostka jest w dokumentacji. Jest to wygodne, ale też mało elastyczne. Jakby twórcy uznali, że warto dodać możliwość podawania opadów w innych jednostkach, musieliby dodać pole jednostka. Zmiana w API = problem, bo programiści muszą aktualizować swoje aplikacje.

W MCP struktura odpowiedzi w ogóle nie jest precyzowana. Zakłada się, że agent korzystający z tej metody sam zinterpretuje odpowiedź. Dlatego dobry serwer MCP powinien powiedzieć np. Opady: 3 mm/h, a nie tylko 3. Model językowy poradzi sobie z tym i ewentualnie sam przeliczy jednostki, jeśli będzie taka potrzeba.

Dokumentacja

API: dostępna gdzieś na stronach; brak standardu; musi opisywać zarówno zapytanie, jak i odpowiedź (odpowiedź zazwyczaj o wiele obszerniejsza) MCP Tools: opis co robi każda metoda oraz każdy parametr pobierany jest automatycznie przez klienta AI (zaszyte w serwerze). Nie trzeba niczego szukać na stronach, a struktury odpowiedzi w ogóle nie trzeba opisywać.

Efekty opisanych różnic

API były tworzone z myślą o programiście i ręcznej dłubaninie. MCP jest pomyślane z myślą o pełnej automatyzacji. Serwer MCP sam dostarcza w ramach protokołu wszystkich niezbędnych informacji, żeby poinformować swojego klienta, co może zrobić i jak to zrobić. Chodzi o to, by korzystać z narzędzi bez udziału programisty. AI dostaje tylko adres serwera i samo dopytuje o resztę.

Taki serwer nie wymaga żadnej dokumentacji zewnętrznej, a AI może korzystać z tysięcy serwerów MCP bez potrzeby angażowania człowieka. Można więc powiedzieć, że dokumentacja jest zintegrowana z samym API i przy okazji o wiele krótsza – bo nie musi opisywać odpowiedzi.

Zmiany, zmiany, zmiany

Jedyną niezmienną rzeczą są zmiany. MCP jest nieporównywalnie lepiej dostosowany do zmian niż tradycyjne API. Asystent AI i tak za każdym razem przed wywołaniem sprawdza zasady. Nie ma więc większych problemów z utrzymaniem wstecznej kompatybilności.

Serwery MCP mogą się szybko zmieniać i ewoluować, a zmiany nie wymagają ingerencji programistów po stronie klienta. Dodamy jednostkę w odpowiedzi? Spoko – klient sobie poradzi. Najwyżej sam przeliczy jednostki, używając jakiegoś kalkulatora, który... też może być serwerem MCP. Dodamy nowe pole do zapytania? AI to zauważy i doda, co trzeba.

Ta elastyczność to ogromna zaleta protokołu MCP. Nie byłaby możliwa, gdyby nie to, że za interakcję odpowiada AI, które samo w sobie jest elastyczne. Nowe czasy (AI) = nowe podejście = lepszy protokół. Nic dziwnego, że MCP tak szybko zdobywa popularność.

Wywołanie polecenia z parametrami

MCP Tools ma sporo wspólnego z tradycyjnymi API właśnie w tym kontekście.

Podejście tradycyjne – usługi z własnymi API

W tradycyjnym podejściu dostawca usług wystawia tzw. API. Przykład? Allegro: [2]. Po lewej są kategorie, a każda ma metody związane z danymi funkcjonalnościami (oferty, zniżki, kategorie itd.). Jest tego masa. Obecnie standardem jest, że taka dokumentacja opisuje wszystkie możliwe interakcje.

Dzięki temu programista może napisać automat, który np. śledzi zmiany cen i sam ustala ceny własnych produktów. Tylko że to trudne, żmudne i czasochłonne. Co prawda różne API są do siebie podobne, ale dokumentacja nie ma żadnej ustandaryzowanej formy.

Dlatego nawet dla AI może być ciężko zbudować program, który będzie korzystał z takiego API.

Definicja metody z parametrami

Tradycyjne API mają bardzo jasno zdefiniowane parametry. Przykład? Pogoda: [3].

API definiuje metody, kody błędów, strukturę odpowiedzi – wszystko, żeby nie było najmniejszych wątpliwości, jak program powinien to obsłużyć.

Co wyróżnia MCP

MCP stworzone jest z myślą o tym, żeby te metody były łatwiejsze w użyciu – zarówno dla AI, jak i dla człowieka.