Myślisz, że podłączenie 50 serwerów MCP zrobi z Twojego AI genialnego asystenta? Z pewnością. Ale przy okazji wyczyści Twój budżet operacyjny i odczuwalnie spowolni działanie całego systemu.

Kiedy Model Context Protocol (MCP) zaczął zyskiwać na popularności, obietnice brzmiały rewelacyjnie. Mieliśmy otrzymać swoiste “USB-C dla AI”. Jeden uniwersalny standard, który ostatecznie pozwalałby modelom takim jak Claude czy GPT wchodzić w płynne, bezpośrednie interakcje z zewnętrznymi bazami danych, repozytoriami kodu czy oprogramowaniem analitycznym. Koniec z pisaniem własnych i drogich w utrzymaniu integracji dla każdego zewnętrznego narzędzia.

W praktyce ten system faktycznie działa bez zarzutu, dopóki nie zaczniesz analizować twardych metryk. Zaczynasz się bawić integracjami, podłączasz co się da. Ale po jakimś czasie patrzysz na dashboard zużycia API od OpenAI czy Anthropic i orientujesz się, że opłaty rosną w lawinowym tempie.

Mówi się, że w życiu są tylko dwie pewne rzeczy: śmierć i podatki. Okazuje się, że w świecie AI podatki również mają się dobrze, a jednym z nich jest “Podatek od narzędzi” (Tool Tax).

Zanim przejdziemy do anatomii kosztów i poszukiwania winnych w naszych portfelach, weźmy głęboki oddech i cofnijmy się na moment. Zobaczmy sam rdzeń tego, czym jest MCP i dlaczego uchodzi za rewolucję.

Na początku mierzyliśmy się z klasycznym, niezwykle kosztownym problemem “N x M”. Załóżmy, że masz do dyspozycji 5 różnych aplikacji bazujących na modelach językowych oraz 10 zewnętrznych źródeł danych. Żeby to wszystko spiąć, musiałeś zbudować i utrzymać 50 unikalnych, szytych na miarę integracji. Każda kolejna usługa dokładana do stosu wymuszała pisanie nowych łączników dla każdego modelu z osobna. Zero optymalności. Powtarzalna praca. Koszmar programisty.

I właśnie wtedy wchodzi MCP, cały na biało. Stworzony jako otwarty standard, funkcjonuje dokładnie jak złącze USB-C dla elektroniki, narzucając spójną komunikację (opartą na JSON-RPC) w formacie klient-serwer. Po stronie serwera definiujesz po prostu:

• Zasoby (Resources) – dane tylko do odczytu.

• Narzędzia (Tools) – akcje, które agent może wykonać (np. wysłanie maila czy wrzucenie rekordu do bazy).

• Prompty – gotowe szablony zapytań.

Po drugiej stronie, agenci z automatu orientują się, jakie zbiory danych i funkcje są dla nich w danej chwili dostępne.

To podejście błyskawicznie otworzyło drzwi do łatwej integracji LLM-ów z wieloma już istniejącymi aplikacjami. Problem “N x M” zamienił się w proste dodawanie “N + M”. Standard trafił natychmiast na radary takich firm jak Anthropic, Google czy AWS.

Niestety, zachłystując się łatwością wpinania do agenta dziesiątek serwerów na raz, jako branża zignorowaliśmy istotny problem. Problem, który teraz może bezwzględnie drenować Twój portfel.

I nie jest to tylko kwestia dla programistów używających narzędzi jak OpenCode, Gemini CLI czy Claude Code. To samo dzieje się, gdy używasz pluginów w Codexie czy Connectorów w Claude.

Zasada działania MCP narzuca konieczność dostarczania wytycznych dla każdej, nawet nieużywanej integracji w ramach okna kontekstowego (czyli tego, co fizycznie wysyłamy na wejściu do LLM-a). Zmusza to nas do ciągłego przesyłania potężnych paczek nadmiarowych informacji. Każde wywołanie agenta przez MCP nakłada kosmiczny wręcz narzut na wejściowe tokeny. Szczerze mówiąc, płacisz za ten proces podwójnie. Zobacz dlaczego:

Załóżmy, że podłączyłeś serwer MCP, który udostępnia Twojemu agentowi 40 różnych narzędzi programistycznych. Siłą rzeczy, zmuszasz swojego bota do załadowania pełnego schematu JSON (JSON schema) dla każdego z tych narzędzi podczas prawie każdej pojedynczej interakcji.

Model językowy musi przetrawić ten długi regulamin działania bez względu na to, czy w danym momencie w ogóle planuje sięgnąć po którekolwiek z narzędzi. Z audytów przeprowadzonych przez zespół GitHuba wynika, że takie podejście potrafi generować od 10 do 15 KB całkowicie martwego balastu w każdym jednym kroku konwersacyjnym! Płacisz Anthropic lub OpenAI za analizę danych, których agent w tej sekundzie w ogóle nie potrzebuje.

Jeżeli myślisz, że wejście jest drogie, spójrz, co dzieje się na wyjściu. Anomalie rodzą tzw. “Direct Tools” – czyli architektura oparta na ślepym wywoływaniu narzędzi, które zwracają dane od razu do agenta.

Wyobraź sobie prosty scenariusz. Zlecasz agentowi wyłuskanie pięciu najnowszych klientów z potężnej bazy CRM. Oprogramowanie pobiera pełny zestaw – powiedzmy 10 000 wierszy – ze źródła, by ułamek sekundy później, po chamsku, dokleić tę potężną ścianę tekstu do okna kontekstu modelu AI. Wszystko po to, żeby model przedarł się przez ocean znaków i wyekstrahował dla Ciebie 5 rekordów.

Zastanów się nad tym chwilę. Czy kazałbyś nowemu kumplowi w pracy przeczytać od deski do deski pełną książkę telefoniczną tylko po to, żeby potwierdził Ci jeden numer telefonu? No raczej nie. Tymczasem w konfiguracji opartej o Direct Tools, LLM zmuszany jest do takiego działania nagminnie. A każdy “przeczytany” wiersz bije Ci po karcie kredytowej jako kolejne zużyte tokeny.

Rozwiązaniem tego problemu nie jest odesłanie MCP do kosza. MCP to dobry protokół. Problemem jest naiwna architektura wokół niego. Bezpośrednie i ślepe wywoływanie narzędzi zaczyna być wypierane przez nieco inteligentniejsze mechanizmy.

Są już wytyczone szlaki obniżające to obciążenie. Spójrzmy na trzy podejścia, dzięki którym duże firmy tną koszty API.

Zamiast napychać model językowy zestawem sztywnych formatek narzędziowych do wypełnienia parametrami, dostarczamy mu dokumentację interfejsu (na przykład jako prostą bibliotekę Python lub TypeScript). Zamiast używać bezpośrednio wbudowanego toola, model AI przyjmuje polecenie od użytkownika i... samodzielnie pisze skrypt. Ten mały program jest w stanie sam wykonać brudną robotę.

Jak to zabezpieczyć? Ten wygenerowany “on-the-fly” kod wypychany jest do wykonania w izolowanej piaskownicy (sandbox), gdzie może zostać wykonany tylko w zakresie na jaki mu pozwolimy.

• Rezultat: Inżynierowie Anthropic dokumentują, że wdrożenie takiej warstwy kodującej potrafi zredukować koszt operacji ze 150 000 do zaledwie 2 000 tokenów. To oszczędności na poziomie 98,7%.

• Haczyk: Biorąc na siebie uruchamianie kodu tworzonego przez model w czasie rzeczywistym, trzeba też wziąć na klatę utrzymanie w stu procentach szczelnego środowiska uruchomieniowego (sandbox). Nikt nie chce odpalać obcego kodu na serwerze produkcyjnym bez zabezpieczeń.

Drugie podejście to klasyczny pragmatyzm. Często zdarza się tak, że agenci wykonują w kółko te same, nudne i powtarzalne prośby. Zawsze, gdy pracują z kodem, potrzebują na przykład statusu obecnego brancha w repozytorium.

Po co więc w ogóle pytać agenta, czy planuje użyć narzędzia MCP, żeby te dane pobrać? Zamiast tego, przed uruchomieniem silnika LLM, można odpalić osobny proces w tle (np. skrypt bash lub job CI), który weryfikuje otoczenie. Zbiera paczkę gotowych informacji i po prostu dodaje je do pierwszego zapytania kierowanego do modelu.

• Rezultat: Oszczędność czasu wywołania oraz wyeliminowanie kosztu “domyślania się” przez model, do którego narzędzia ma w ogóle uderzyć. Odciąża to LLM i natychmiast zapobiega halucynacjom.

• Haczyk: Agent traci elastyczność, stając się sztywno powiązanym z procesami pobierającymi dane. Cofa nas to trochę w stronę twardego oprogramowania – jeśli zmienią się biznesowe wymogi, i tak będziesz musiał aktualizować te skrypty.

Trzecia opcja, obiecująca dla środowisk programistycznych, to powrót do narzędziowych korzeni. Zamiast budować serwery MCP obsługujące AWS-a czy GitHuba, wpuszczamy agenta do terminala i pozwalamy mu korzystać z natywnego interfejsu wiersza poleceń (CLI).

Zamiast przekazywać modelowi potężny schemat JSON definiujący 150 endpointów do obsługi GitHuba, dajemy mu po prostu dostęp do powłoki bash oraz zainstalowane narzędzie gh cli. LLM świetnie zna to narzędzie ze swoich danych treningowych.

• Rezultat: Koszty wejściowe tokenów spadają drastycznie. A co najciekawsze – przenosisz całkowitą odpowiedzialność za bezpieczeństwo i zarządzanie dostępem (autoryzację) z agenta na CLI. To oficjalne narzędzie lokalne używa Twoich poświadczeń i bezpiecznie łączy się z serwerem, więc nie musisz wysyłać żadnych kluczy autoryzacyjnych do modelu LLM.

• Haczyk: Wymaga to od agenta doskonałej znajomości składni danego narzędzia. Zbyt “mały” model może zgubić się w dokumentacjach, podając błędne argumenty do terminala.

Kij ma jednak zawsze dwa końce. Spójrzmy w stronę twórców samych serwerów MCP, którzy te zbiory udostępniają. Sam miałem okazje sobie takie serwery wystawiać. Pisanie standardów pod sztuczną inteligencję
różni się od projektowania klasycznych interfejsów REST API. Niektóre twarde nawyki trzeba wyrzucić do kosza.

Tradycyjny system operuje deterministycznie – znasz endpoint, wysyłasz JSON-a, funkcja wykonuje kod. Model językowy operuje inaczej. Analizuje dostępne narzędzia używając wektorów semantycznych (embeddings), by na początek odgadnąć Twoją intencję. Dopiero kiedy “na logikę” dopasuje narzędzie do zadania, wrzuca w funkcję argumenty.

Jeżeli zbudujesz serwer MCP i swoje najważniejsze narzędzie oznaczysz po prostu jako execute_system_action, ukrywając wewnątrz głęboki labirynt nieintuicyjnych flag bez dokładnego wytłumaczenia w opisie – skazujesz deweloperów używających Twojego narzędzia na straty finansowe.

LLM w takim układzie zaczyna błądzić we mgle. Pobiera źle nazwane narzędzie, rzuca losową listą parametrów, dostaje odmowę od serwera... po czym uznaje, że po prostu popełnił “czeski błąd” i próbuje użyć tej samej funkcji, z drobnymi modyfikacjami parametrów. To tak zwana w branży pętla błędnych wywołań (fallback loop).

Znane są przypadki, w których pozbawiona logicznych etykiet i dobrego opisu funkcja została wezwana przez uwięziony w pętli model... aż 64 razy z rzędu. Ty, jako właściciel asystenta, płacisz wtedy w drogich tokenach za 64 bezużyteczne błędy.

Spójrz na różnicę:

Upraszczanie nazw narzędzi i dbanie o przejrzystość opisu ucina kosztowne halucynacje ze strony modeli. Traktuj pole “description” jako najważniejszy punkt swojego narzędzia, bo to on definiuje skuteczność całego rozwiązania dla Twoich użytkowników.

Jeżeli po przeczytaniu tego artykułu Twój stosunek do MCP zmienił się na powyższy, to jeszcze chwilę poczekaj!

MCP jest dobrym protokołem. Świat sztucznej inteligencji pędzi do przodu. Owszem, na razie jesteśmy na etapie “jaki budżet, ładuj w AI, tokenmaxxing!”. Ale w biznesie wcześniej czy później do głosu dochodzą Excel (teraz z Claude) i optymalizacje. Kiedy rachunki wystrzelą w kosmos przez asystentów operujących na tonach danych, wygrają ci, którzy rozumieją mechanikę kosztów i to, jak jej zaradzić.

Dla zaoszczędzenia trochę pieniędzy na subskrypcjach, po prostu zrób audyt i zweryfikuj, czy nie masz podpiętych zbyt wielu zbędnych serwerów MCP do swojego agenta. Bardzo możliwe, że z połowy nawet nie korzystasz, bo podłączyłeś je przelotnie na zasadzie “kiedyś mi się przyda integracja z Jirą”. Ale realnie... z niej korzystasz? Jeśli nie – odepnij.

Jeśli potrzebujesz czegoś więcej, korzystaj z Code Mode lub posiłkuj się CLI. Odcinaj ten balast w kontekście.

A jak Ty dzisiaj dbasz o to, by nie przepalać tokenów w swoich agentach AI?
Daj znać, chętnie poznam też inne podejścia!