Agent ma 90 narzędzi do wyboru i sięga po sąsiednie. Trafność spada już po przekroczeniu trzydziestu

Agent miał zmienić status zgłoszenia, a dopisał do niego komentarz. Dzień wcześniej zamiast przypisać sprawę do kolejki, przeniósł ją do innego projektu. W logu nie ma błędu: wywołanie się udało, narzędzie zwróciło sukces, tylko było to narzędzie sąsiednie wobec właściwego. Nikt nie ruszał promptu ani modelu. Zmieniła się jedna liczba: narzędzi do wyboru jest dziewięćdziesiąt, a jeszcze w zeszłym miesiącu było trzydzieści.

Przyrost wziął się z podłączenia czwartego serwera MCP – system ticketowy, repozytorium, komunikator i wewnętrzna baza klientów. To jest powierzchnia narzędzi: zbiór, z którego agent wybiera w każdej decyzji. Rośnie przez dołączanie serwerów, nigdy sama się nie kurczy i rządzi dwiema rzeczami naraz – trafnością wyboru oraz tym, co agent może zrobić w firmowych systemach, kiedy wybierze źle.

Po ilu narzędziach wybór przestaje być trafny

Granica jest niższa, niż sugeruje intuicja. Dokumentacja mechanizmu wyszukiwania narzędzi stawia ją wprost: trafność wyboru spada po przekroczeniu 30-50 dostępnych narzędzi. Zbiór HumanMCP mierzy to na 500 zapytaniach przy pulach 10, 50 i 100 narzędzi, licząc, jak często narzędzie poprawne jest pierwszym wskazaniem modelu.

Wartości w procentach, dane ze zbioru HumanMCP (arXiv 2602.23367). Przy stu narzędziach wszystkie trzy modele trzymają się blisko 88 proc., czyli mniej więcej jedna sprawa na osiem dostaje złe narzędzie w pierwszym podejściu. Przy dziesięciu narzędziach była to jedna na pięćdziesiąt.

Dalej spadek nie jest liniowy. W tym samym materiale Gemini 2.0 Flash przy puli 500 narzędzi trafia w 87,4 proc. przypadków, a przy 2000 narzędzi już tylko w 65 proc., przy czym najmocniejsze załamanie wypada między tysiącem a dwoma tysiącami narzędzi. Wcześniejsza praca o wyszukiwaniu narzędzi pokazuje drugą stronę mechanizmu: przy wszystkich narzędziach w prompcie trafność wyniosła 13,62 proc., a po podaniu modelowi wyłącznie wyszukanego podzbioru wzrosła do 43,13 proc. (RAG-MCP, arXiv 2505.03275). Kierunek jest w obu pracach ten sam: wybór z krótkiej listy jest trafniejszy niż wybór z pełnego katalogu.

Objaw jest trudny do przypisania, bo nie zapala się w żadnej metryce. Zamknięte sprawy się zgadzają, czas obsługi też, a rośnie tylko liczba poprawek wprowadzanych ręcznie po fakcie – najczęściej przypisywana „gorszej jakości zgłoszeń”. Test, który to rozstrzyga, jest tani: weź pięćdziesiąt spraw z logu, dla każdej zapisz narzędzie poprawne, a potem przepuść te same zapytania przez listę przyciętą do narzędzi jednego przepływu. Jeśli trafność skacze, problem był w powierzchni, a nie w prompcie ani w modelu.

Dwa narzędzia o nazwie search z różnych serwerów

Sama liczba nie wyjaśnia wszystkiego i to jest ważne przy diagnozie. Gorzej niż długa lista działa lista z bliskimi sąsiadami: dwa narzędzia, których opisy obiecują prawie to samo, bo jedno pochodzi z systemu ticketowego, a drugie z wewnętrznego serwera postawionego nad tą samą bazą. Model nie ma czym ich rozróżnić, skoro żaden opis nie mówi, który z nich jest właściwy dla tego przepływu.

Protokół sam w sobie tego nie porządkuje. Specyfikacja MCP mówi, że unikalność nazw obowiązuje w obrębie jednego serwera, a klient łączący kilka serwerów może natrafić na kolizje – na przykład dwa serwery wystawiające narzędzie search – i powinien sam wprowadzić strategię rozróżniania, choćby prefiks identyfikujący serwer. Co z tego wynika przy diagnozie złych wywołań:

• Agregacja serwerów domyślnie produkuje duplikaty nazw, bo każdy serwer pisze nazwy u siebie.
• Nazwa serwera nie służy do rozróżniania – specyfikacja nie gwarantuje jej unikalności.
• Prefiks per serwis (jira_, slack_) rozwiązuje kolizję i jednocześnie ułatwia wyszukiwanie grupy narzędzi jednym zapytaniem.
• Jeśli po prefiksowaniu dwa narzędzia nadal mają prawie identyczne opisy, to nie jest problem nazw, tylko sygnał, że jedno z nich nie powinno być widoczne w tym przepływie.

Agent szuka narzędzia, zamiast trzymać wszystkie w kontekście

Mechanizm, który rozcina ten węzeł, odwraca kolejność: najpierw wyszukanie narzędzia, potem wywołanie. W API Claude robi to flaga defer_loading na narzędziach plus jedno narzędzie wyszukujące, które zostaje w kontekście na stałe. Przebieg jest taki:

• W żądaniu wysyłasz nadal wszystkie definicje – potrzebne są po stronie serwera, żeby wyszukiwanie miało w czym szukać.
• Do kontekstu modelu wchodzi tylko narzędzie wyszukujące i te, których nie odroczyłeś.
• Model szuka wzorcem regularnym albo zapytaniem w języku naturalnym po nazwach, opisach i nazwach argumentów.
• Wyszukiwanie zwraca domyślnie do pięciu dopasowań, które API rozwija do pełnych definicji.
• Model wybiera z tego krótkiego podzbioru i wywołuje narzędzie.

Trzy szczegóły decydują o tym, czy to się opłaci. Odroczone narzędzia są wyłączone z prefiksu promptu, więc dołożenie serwera przestaje unieważniać pamięć podręczną – a to był dotąd ukryty koszt każdej integracji. Co najmniej jedno narzędzie musi pozostać nieodroczone, a dokumentacja zaleca trzymać w kontekście 3-5 najczęściej używanych, żeby typowa sprawa nie zaczynała się od wyszukiwania. Limit odroczonych narzędzi w jednym żądaniu to 10 tys., więc ograniczeniem nie jest ich liczba, tylko jakość opisów: narzędzie opisane słowami, których nikt nie używa w zgłoszeniach, jest w praktyce niewidoczne.

Koszt nie znika do zera. Wyszukiwanie to dodatkowy obrót pętli, a załadowane definicje liczą się jako zwykłe tokeny wejścia. Przy mniej niż dziesięciu narzędziach ten mechanizm jest stratą – dodaje obrót tam, gdzie wszystko zmieściłoby się w kontekście i tak. Granica opłacalności z dokumentacji to dziesięć narzędzi albo 10 tys. tokenów definicji.

Ile kontekstu zjada sama lista narzędzi

Powierzchnia ma też cenę, którą płaci się niezależnie od tego, czy agent cokolwiek wywoła. Klient MCP po podłączeniu serwera pobiera listę narzędzi zapytaniem tools/list i wkłada ją do kontekstu modelu: nazwy, opisy i pełne schematy wejścia z typami, wartościami dopuszczalnymi i opisami argumentów. Dokumentacja podaje, że typowy zestaw pięciu serwerów – GitHub, Slack, Sentry, Grafana i Splunk – zajmuje około 55 tys. tokenów samych definicji, zanim model wykona pierwszą czynność.

Przy 1200 sprawach miesięcznie i sześciu żądaniach na sprawę to 7200 żądań, w których ta sama lista jedzie od nowa. Stawki poniżej według cennika Claude Sonnet 5.5: 2 USD za milion tokenów wejścia i 0,10 USD za odczyt z pamięci podręcznej, przy jednym zapisie do pamięci podręcznej na sprawę.

To jest koszt wyłącznie definicji – bez treści spraw, historii wątku i wyjścia modelu. Pełne rozbicie rachunku agenta, razem z mechaniką pamięci podręcznej i tym, dlaczego ten sam wolumen drożeje po miesiącu, jest w osobnym materiale: rachunek za agenta obsługującego zgłoszenia. Tutaj liczy się jedna rzecz: pozycja za powierzchnię narzędzi jest stała w każdym żądaniu i nie zależy od tego, ile narzędzi agent faktycznie użył.

Agent dostaje narzędzia razem z dostępami

Powierzchnia narzędzi jest jednocześnie powierzchnią uprawnień i to jest argument mocniejszy niż trafność. Dziewięćdziesiąt narzędzi w kontekście znaczy, że w każdej sprawie – również w takiej, która wymaga wyłącznie odczytu – agent ma pod ręką narzędzia kasujące, przenoszące i wysyłające na zewnątrz. Pomyłka między dwoma odczytami kosztuje jedno dodatkowe wywołanie. Pomyłka między odczytem a zapisem kosztuje telefon od klienta.

Protokół daje tu konkretny punkt zaczepienia, o którym łatwo nie wiedzieć: zbiór narzędzi zwracany przez tools/list może różnić się w zależności od poświadczeń przedstawionych w żądaniu – serwer ma prawo zwrócić tylko te narzędzia, na które pozwalają nadane uprawnienia. Zawężanie listy nie musi więc być sprytem po stronie orkiestratora ani filtrem w konfiguracji klienta. Osobne poświadczenia dla przepływu odczytowego i osobne dla zapisującego dają krótszą listę w kontekście oraz granicę, której zły wybór modelu nie przeskoczy: agent, który nie ma w kontekście narzędzia usuwającego, nie usunie rekordu nawet przy złym rozumowaniu.

Przy okazji zmienia się to, co trzeba nadzorować. Zatwierdzenie człowieka ma sens przy akcjach nieodwracalnych; jeśli przepływ odczytowy fizycznie nie widzi takich narzędzi, zostaje mniej punktów, w których ktoś musi klikać. Pytanie o zakres dostępu wraca przy każdym narzędziu pracującym na firmowych danych – w asystentach kodu rozstrzyga je miejsce, w którym powstaje indeks repozytorium, bo ono decyduje, co w ogóle opuszcza firmę.

Przycinanie powierzchni przed podłączeniem kolejnego serwera

Kolejność ma znaczenie, bo wyszukiwanie założone na nieuporządkowaną listę dziewięćdziesięciu narzędzi przenosi problem, zamiast go rozwiązać.

1. Spisz narzędzia per serwer wraz z kosztem. Policz tokeny definicji każdego serwera osobno. Zwykle jeden serwer odpowiada za większość objętości i to on jest pierwszym kandydatem do odroczenia.
2. Zbuduj macierz przepływ na narzędzie. Wiersze to przepływy, kolumny narzędzia. Puste kolumny pokazują narzędzia, których nie używa żaden przepływ.
3. Odłącz puste kolumny. Narzędzie bez przepływu to miejsce w kontekście przy każdym żądaniu i jeden dystraktor więcej przy wyborze.
4. Rozdziel odczyt od zapisu. Narzędzia zapisujące udostępniaj tylko przepływom, które zapisują, i na osobnych poświadczeniach – wtedy krótsza lista wynika z uprawnień, nie z konfiguracji klienta.
5. Ujednolić nazwy prefiksem serwisu i przejrzyj opisy par, które po prefiksowaniu nadal brzmią tak samo.
6. Włącz odroczone ładowanie i zostaw w kontekście 3-5 narzędzi, które wchodzą w grę w większości spraw.
7. Zmierz trafność na własnym zbiorze. Pięćdziesiąt par zapytanie-narzędzie z własnych logów mówi o twoim przepływie więcej niż każdy benchmark, bo zawiera twoje bliskie sąsiedztwa.

Do punktu siódmego potrzebny jest log, którego większość wdrożeń nie ma: wybrane narzędzie, etykieta przepływu i to, czy człowiek musiał poprawić skutek. Bez tych trzech pól nie odróżnisz spadku trafności od wzrostu liczby trudnych spraw, a oba objawy wyglądają identycznie w statystyce zamkniętych zgłoszeń.

Co zmierzyć, zanim doda się piąty serwer

Trzy liczby wystarczą do decyzji i wszystkie trzy da się wyciągnąć z własnego systemu w jeden dzień. Pierwsza: liczba narzędzi widocznych w kontekście w typowej sprawie – powyżej trzydziestu spadek trafności jest już w danych, nie w przewidywaniach. Druga: ile z nich potrafi zapisać, usunąć albo wysłać coś na zewnątrz, bo to jest realny zasięg złego wyboru. Trzecia: udział spraw, w których agent wywołał narzędzie sąsiednie wobec poprawnego; bez tej liczby nie ocenisz, czy zmiana cokolwiek dała.

Decyzja do podjęcia jest jedna: czy nowy serwer wchodzi do wspólnej puli wszystkich przepływów, czy tylko do tych, które go używają, na własnych poświadczeniach. Pierwsza droga jest o jedną linię konfiguracji krótsza i płaci się za nią w każdym żądaniu oraz w każdej sprawie, w której agent sięgnie o jedno narzędzie za daleko.