MCP a integracja przez API — kto decyduje, co się wydarzy

Dwa zdania brzmią podobnie, a znaczą co innego: „podłączyliśmy AI do systemu zleceń” oraz „wystawiliśmy system zleceń przez MCP”. W pierwszym ktoś zaprogramował, co ma się wydarzyć. W drugim model dostał zestaw możliwości i sam wybiera.

Ta różnica siedzi w warstwie integracji, poniżej tego, co widzi użytkownik. Ale to ona rozstrzyga, czy da się przewidzieć wynik, ile to kosztuje i jak długo szuka się przyczyny, gdy coś pójdzie nie tak.

Kto podejmuje decyzję#

Integracja przez API to ścieżka narysowana z góry. Programista ustalił: przychodzi zdarzenie, pobierz pola A, B i C, złóż z nich polecenie do modelu, weź odpowiedź, zapisz ją w polu D, wyślij powiadomienie. Model jest jednym krokiem w środku. Ma jedno zadanie i nic do powiedzenia w sprawie tego, co dzieje się przed nim i za nim.

MCP odwraca kolejność. Serwer MCP wystawia narzędzia — operacje do wywołania — oraz zasoby, czyli dane do odczytu. Każde narzędzie ma nazwę, opis i schemat parametrów. Model dostaje tę listę i to on decyduje, czy użyć jednego narzędzia, pięciu po kolei, czy żadnego.

Warto przy okazji ustawić słownictwo, bo mylą je nawet dostawcy. Klientem jest aplikacja AI. Serwerem jest system, który wystawia swoje operacje. Zdanie „podłączamy nasz system do asystenta” znaczy tyle, że system staje się serwerem, a asystent klientem — nie że jedno działa w środku drugiego.

I jeszcze jedno rozróżnienie, które oszczędza wielu nieporozumień: model nie dostaje dostępu do bazy. Dostaje listę narzędzi i może poprosić o ich wywołanie. Wywołuje je klient, w imieniu zalogowanego użytkownika.

Ta sama sprawa dwiema drogami#

Przykład: klient pisze maila z pytaniem o status zamówienia, a ty chcesz odpowiadać automatycznie.

Przez API. Kod odbiera wiadomość, wyciąga z niej numer zamówienia, odpytuje bazę, wkłada wynik w szablon polecenia, model układa z tego zdanie, kod wysyła odpowiedź. Jeden przebieg, zawsze ten sam. Jeżeli w mailu nie ma numeru zamówienia, ścieżka się kończy — nikt jej na taki przypadek nie przewidział.

Przez MCP. Aplikacja AI dostaje treść maila i listę narzędzi: znajdź klienta po adresie, wypisz jego zamówienia, pokaż szczegóły zamówienia. Brak numeru nie zatrzymuje sprawy — model znajduje klienta po adresie nadawcy, wypisuje zamówienia, bierze ostatnie otwarte. Nikt tego przebiegu nie zaprogramował.

To jest jednocześnie cała zaleta i cały problem. Ten sam mechanizm, który poradził sobie z brakiem numeru, przy następnym mailu może wybrać nie to zamówienie — bo klient ma trzy otwarte i żadne nie jest oczywistym kandydatem.

Cztery rzeczy, które się przez to zmieniają#

Przewidywalność. W integracji przez API to samo wejście daje ten sam przebieg. Zmienna jest wyłącznie treść odpowiedzi modelu, i to w jednym wąskim, opisanym miejscu. W MCP zmienna jest sama trasa: przy dwóch bardzo podobnych pytaniach model może sięgnąć po inne narzędzia.

Testowanie. Ścieżkę przez API testuje się jak zwykły kod: to wejście, to wyjście, zielony albo czerwony. Ścieżki przez MCP tak nie zamkniesz. Testujesz zachowanie na zestawie realnych pytań i sprawdzasz, w ilu przypadkach model wybrał właściwe narzędzie i właściwe parametry. Wynikiem nie jest werdykt, tylko rozkład trafień — a podmiana modelu na nowszy potrafi go przesunąć w obie strony.

Koszt. Ścieżka przez API to znana liczba wywołań o znanym rozmiarze. W MCP liczbę wywołań ustala model, a do każdego pytania dochodzi opis dostępnych narzędzi, bo bez niego model nie wie, czym dysponuje. Przy kilkunastu narzędziach nie ma to znaczenia; przy kilkudziesięciu zaczyna mieć — co się wtedy psuje i jak skrócić listę, rozkładamy osobno.

Debugowanie. Gdy integracja przez API zwróci bzdurę, znajdziesz linijkę. Gdy zrobi to agent na MCP, dziennik pokaże, jakie narzędzia wywołał i z jakimi parametrami — ale nie pokaże linijki, bo jej nie ma. Odpowiedź na pytanie „dlaczego wybrał akurat to narzędzie” brzmi zwykle: bo jego opis wyglądał na pasujący. Naprawa polega wtedy na poprawieniu opisu i schematu parametrów, nie kodu. To jest inna praca niż programowanie.

Kiedy API jest tańsze i lepsze#

Gdy przebieg jest znany i się nie zmienia. Przychodzi faktura, dane trafiają do systemu, ktoś dostaje powiadomienie. Nie ma tu decyzji do podjęcia, więc nie ma po co zatrudniać do niej modelu.

Gdy wynik ma się zgadzać co do znaku. Rozliczenia, przelewy, korekty stanów magazynowych. Wszędzie tam, gdzie odpowiedź „prawie dobra” jest gorsza niż brak odpowiedzi.

Gdy wolumen jest duży, a zadanie identyczne. Tysiąc takich samych operacji dziennie to tysiąc decyzji, których nikt nie musi podejmować. Płacenie za nie modelem to koszt bez wartości.

Gdy błąd jest nieodwracalny. Wysłany mail do klienta, wystawiony dokument, zamknięte zlecenie.

Reguła praktyczna: jeżeli potrafisz narysować przebieg na kartce i nie musisz co chwilę dopisywać „chyba że”, integracja przez API będzie tańsza — w budowie, w utrzymaniu i na rachunku za modele.

Kiedy MCP naprawdę coś zmienia#

Gdy wejście jest nieprzewidywalne. Pytania zadawane własnymi słowami nie mają skończonej listy wariantów. Ścieżka zapisana z góry obsłuży te, które ktoś przewidział, i odbije się od reszty.

Gdy operacji jest dużo, a ich kombinacji jeszcze więcej. Przy trzydziestu operacjach liczba sensownych sekwencji idzie w setki. Nikt nie napisze ścieżki pod każdą z nich, a większość i tak zostanie użyta raz.

Gdy chcesz pytać z narzędzia, którego nie kontrolujesz. Jeżeli zespół pracuje w kilku aplikacjach AI, integracja napisana pod jedną z nich nie działa w pozostałych. Serwer MCP nie jest pisany pod konkretnego klienta.

Gdy nowe wymaganie nie ma oznaczać zlecenia dla programisty. Dołożenie jednego narzędzia z opisem daje modelowi nową możliwość i wszystkie jej kombinacje ze starymi. W integracji przez API dokładasz jedną ścieżkę i dokładnie tyle dostajesz.

Podsumowanie#

Różnica między integracją przez API a MCP nie jest różnicą pokoleń technologii, tylko różnicą w tym, kto podejmuje decyzję w trakcie. Ścieżka przez API jest przewidywalna, tania i testowalna, dopóki świat wygląda tak, jak zakładał ją piszący. MCP kupuje elastyczność za przewidywalność, a płaci za nią w rachunku za modele i w trudniejszym debugowaniu.

W praktyce większość firm będzie miała jedno i drugie: sztywne ścieżki tam, gdzie proces jest ustalony, i narzędzia wystawione modelowi tam, gdzie pytania są otwarte. Pytanie do dostawcy nie brzmi więc „czy macie MCP”, tylko „które operacje wystawiacie modelowi i czyimi uprawnieniami je wywołuje”.

Szerszy kontekst w przewodniku o integracji AI z danymi firmy.