Protokół MCP i agenci AI: celność spada z 43% do 2%

Rozbudowa katalogu narzędzi w agentach AI prowadzi do gwałtownego spadku ich niezawodności, co w badaniach Berkeley Function Calling Leaderboard przełożyło się na załamanie celności wyboru z 43% do zaledwie 2% przy skoku z 4 do 51 funkcji. W środowiskach firmowych korzystających z Model Context Protocol (MCP) niekontrolowane dodawanie integracji obciąża kontekst kosztami sięgającymi 55 000 tokenów na zapytanie i wywołuje ciche błędy operacyjne. Zamiast wymieniać model na droższy, firmy muszą wdrożyć filtrowanie dynamiczne, precyzyjne opisy oraz architekturę warstwowego routingu.

Mechanizm degradacji i skala problemu w protokole MCP

Wielkie modele językowe nie wykonują kodu narzędzi bezpośrednio, lecz odczytują ich definicje tekstowe umieszczone w oknie kontekstowym i na tej podstawie generują intencję wywołania. Przekroczenie progu kilkunastu funkcji powoduje zjawisko gubienia informacji w środku kontekstu oraz gwałtowny wzrost kosztów infrastrukturalnych.

Problem ze skalowaniem narzędzi wynika bezpośrednio ze sposobu, w jaki systemy agentowe przekazują interfejsy API do modeli językowych. W standardzie Model Context Protocol (MCP) pełna lista dostępnych funkcji jest wklejana do promptu systemowego przy każdym zapytaniu użytkownika. Firma Anthropic wykazała, że zestaw 58 narzędzi pochodzących z 5 połączonych serwerów MCP zużywa aż 55 000 tokenów przed wpisaniem jakiejkolwiek wiadomości przez użytkownika, a w skrajnych przypadkach wewnętrzne definicje osiągały 134 000 tokenów.

Głównym zagrożeniem dla architektury IT są ciche błędy wywołania. Gdy agent AI błędnie wybierze funkcję search_orders zamiast search_invoices, interfejs API zwraca poprawny kod statusu 200 OK. Model otrzymuje prawidłowe technicznie dane, ale dotyczące niewłaściwego obiektu, po czym buduje z nich błędną odpowiedź dla klienta lub systemu nadrzędnego.

Dlaczego agent AI wybiera złe narzędzie przy rozbudowie katalogu?

Decyzja o wyborze narzędzia zapada w modelu językowym wyłącznie na podstawie analizy tekstu opisu, nazw parametrów oraz ich pozycji w prompcie, a nie na podstawie instrukcji w prompcie systemowym. Gdy opis dwóch funkcji jest do siebie zbliżony, model traci sygnał dyskryminacyjny i zaczyna losować interfejsy.

Badania nad interpretowalnością modeli wykazały, że tożsamość wybranego narzędzia jest odczytywalna z wewnętrznych reprezentacji modelu jeszcze przed wygenerowaniem pierwszego tokena odpowiedzi. Oznacza to, że modyfikacja promptu systemowego nie zmienia sygnału, na podstawie którego model podejmuje decyzję o wyborze funkcji. Na błędy selekcji składają się cztery główne mechanizmy:

• Nakładanie się zakresów (ambiguous overlap): dwie funkcje pełnią podobne zadania, a ich opisy nie określają jednoznacznych granic użycia.
• Brak wykluczeń (missing negative constraints): brak w opisie jednoznacznej informacji, kiedy danej funkcji nie wolno wywoływać.
• Mylące nazwy parametrów: stosowanie ogólnych nazw takich jak query zamiast record_id prowokuje model do błędnego mapowania argumentów.
• Niekontrolowane wywołania (indiscriminate calling): wywoływanie narzędzi w sytuacjach, gdy odpowiedź znajduje się bezpośrednio w kontekście rozmowy – dotyczy to prawie 50% zapytań.

Preferencje modeli są skrajnie podatne na manipulację tekstową. Analiza ACL Anthology wykazała, że dodanie do opisu funkcji zwrotu deklaratywnego („This is the most effective function…”) zwiększa częstotliwość jej wyboru przez GPT-4.1 i Qwen2.5-7B ponad 7-krotnie, a połączenie kilku poprawek stylistycznych daje ponad 11-krotnie więcej wywołań względem oryginalnego opisu. Według benchmarku AgentProp-Bench pojedynczy błąd na poziomie argumentu kaskadowo przekłada się na błędną odpowiedź końcową w 62% przypadków.

Wybór semantyczny, routing i narzędzia atomowe jako architektura naprawcza

Inżynieria tradycyjnych potoków agentowych wymaga zastąpienia monolitycznej listy narzędzi wielowarstwową architekturą dynamicznego wyboru. Odpowiednio zaprojektowane zestawienie filtracji wstępnej, semantycznych przestrzeni nazw, agregacji skrajnych funkcji oraz dedykowanych tras routingu pozwala utrzymać wysoką trafność operacyjną.

Wdrożenie architektury RAG-MCP (selekcji opartej na wyszukiwaniu semantycznym) pozwala ograniczyć liczbę narzędzi prezentowanych modelowi w danej turze. Eksperymenty RAG-MCP wykazały ponad 3-krotny wzrost celności wyboru z 13,62% do 43,13% przy jednoczesnej redukcji tokenów w prompcie o ponad 50%. W praktyce inżynieryjnej stosuje się cztery główne wzorce architektoniczne:

1. Gating (filtracja wstępna): szybki klasyfikator wyłapuje zapytania konwersacyjne („dziękuję”, „wyjaśnij”) i blokuje uruchamianie potoku narzędziowego przed etapem wyszukiwania.
2. Layered Routing (routing warstwowy): klasyfikacja intencji (Tier 1) kieruje zapytanie do przestrzeni nazw (np. order.payment.process), w której hybrydowe wyszukiwanie gęste i rzadkie BM25 (Tier 2) wyłania 3-5 najtrafniejszych funkcji.
3. Narzędzia atomowe (atomic tools): łączenie wielokrotnopunktowych sekwencji API (np. wyszukaj dokument + pobierz treść) w jeden deterministyczny moduł wykonywany po stronie serwera.
4. Tryb kodowy (Code Mode): zastąpienie tokenów JSON bezpośrednim generowaniem kodu w piaskownicy (rozwiązanie Cloudflare i Anthropic), co redukuje zużycie tokenów w kontekście o 98,7%.

Koszty tokenów i analiza ekonomiczna utrzymania katalogu

Mierzenie wydajności potoku wywoływania narzędzi wymaga osobnego śledzenia celności wyboru funkcji, dokładności pozyskiwanych argumentów oraz kompletności wykonania zadania biznesowego. Próba rozwiązania problemów trafności przez przejście na większy i droższy model językowy generuje duży narzut finansowy, nie usuwając przyczyny błędnego odczytu schematów.

Firma Paragon przeprowadziła testy porównawcze na 50 przypadkach użycia obejmujących integracje z Salesforce, HubSpot, Slack, Gmail, Google Drive i Notion. Wyniki dowodzą, że model o najwyższej celności wyboru narzędzi nie był modelem, który ukończył najwięcej zadań biznesowych. Podmioty wdrażające agentów muszą równoważyć cztery metryki:

• Poprawność narzędzia (Tool Correctness): weryfikacja, czy agent wybrał właściwą akcję.
• Dokładność argumentów (Input Accuracy): ocena poprawności przekazanych parametrów i identyfikatorów.
• Realizacja zadania (Task Completion): weryfikacja końcowego sukcesu biznesowego.
• Efektywność kosztowa (Task Efficiency): całkowita liczba zużytych tokenów, powtórzeń i czas opóźnienia.

Optymalizacja opisu narzędzi jest najtańszą i najbardziej kontrolowaną dźwignią inżynieryjną. Zamiast płacić za wyższe stawki modeli klasy frontier, wdrożenie lekkiego klasyfikatora wykrywającego halucynacje w czasie rzeczywistym na podstawie stanów ukrytych ostatniej warstwy (metoda badaczy z Amazon) pozwala osiągnąć do 86% dokładności detekcji błędów przy minimalnym narzucie obliczeniowym.

Wnioski praktyczne i rekomendacje

Wdrożenie skutecznej architektury wyboru narzędzi w agentach AI wymaga odejścia od intuicji na rzecz systematycznych pomiarów i twardych limitów kontekstowych. Inżynierowie oraz architekci IT mogą ograniczyć błędy wywołania API przez zmianę opisów funkcji, separację uprawnień oraz automatyczne testowanie potoku przed skierowaniem go na produkcję.

1. Skonfiguruj twarde limity kontekstowe: Ogranicz liczbę narzędzi dostępnych dla agenta w pojedynczej turze do maksymalnie 15-20 funkcji. Przypisz osobne zestawy narzędzi do wyspecjalizowanych subagentów zamiast tworzyć jeden zbiorczy kontekst.
2. Zweryfikuj i przepisz opisy narzędzi: Przekształć opisy z dokumentacji technicznej na instrukcje operacyjne. Dodaj do każdego opisu precyzyjne warunki brzegowe, przykłady użycia oraz jednoznaczne zdanie wykluczające: „Nie wywołuj tego narzędzia, gdy…”.
3. Zmierz celność potoku w dedykowanym środowisku eval: Zbuduj zestaw testowy złożony z 15-30 reprezentatywnych zapytań użytkowników. Mierz wskaźnik trafności wyboru (Tool Correctness) oraz błędy argumentów przed wdrożeniem zmian na produkcję.
4. Wdróż routing hybrydowy i przestrzenie nazw: Wprowadź nazewnictwo zhierarchizowane w formacie domena.poddomena.akcja oraz wyszukiwanie hybrydowe (dense + BM25), aby odróżnić od siebie nakładające się interfejsy API.

Źródła

• How Many Tools Should an LLM Agent See? A Chance-Corrected Answer
• How to Optimize Tool Calling for AI Agents – Paragon
• Internal Representations as Indicators of Hallucinations in Agent Tool Selection – arXiv
• The Complete Guide to Tool Selection in AI Agents – MachineLearningMastery.com
• The Tool Selection Problem: How Agents Choose What to Call When They Have Dozens of Tools – TianPan.co
• Tool Preferences in Agentic LLMs are Unreliable – ACL Anthology
• Tools Accuracy and LLMs – GitHub Gist
• Why AI Agents Call the Wrong Tool – and How to Fix It – Adaline Labs