Tekst źródłowy strony 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 [https://dobrapogoda24.pl 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.

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 ([https://dobrapogoda24.pl/api-pogoda]). 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. [https://openweathermap.org/api/one-call-3 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. Co innego odpowiedź.

== 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ć.

== Kluczowa różnica - Eliminacja programistów ==
MCP Tools eliminuje programistę po stronie klienta. Niezależnie od tego jak duże sa zmiany zachodzace w serwerach MCP, nie trzeba dostosowywac działania klientów. Działanie klienta niejako dostosowywane jest do serwerów dzięki temu,  ze klient posiada inteligencję. Samo utrzymywanie serwera MCP tez jest prostsze, bo nie trzeba przejmowac się kompatybilnością wsteczną.

== 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. Asystent AI po prostu dostosowuje sie do zmian na serwerach na bieżąco.

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: [https://developer.allegro.pl/documentation]. 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.