Ograniczanie narzutu tokenów definicji narzędzi MCP w workflow agentów
Zaktualizowano September 19, 2026 · pierwsza publikacja September 19, 2026
Podłączenie agenta AI do wielu serwerów Model Context Protocol (MCP) wstrzykuje tysiące tokenów wejściowych przy każdej turze, zanim model przeczyta choćby jedno słowo intencji użytkownika. Każde zarejestrowane narzędzie dokleja schemat JSON zawierający nazwy funkcji, opisy parametrów, definicje enumów i ograniczenia typów. W firmowym workspace z 6 podłączonymi serwerami MCP (GitHub, Postgres, Slack, Jira, Brave Search, Filesystem) ta preambuła narzędzi zużywa od 4,500 do 12,000 tokenów wejściowych na każde wywołanie API. Przy 30 turach w ramach jednego zadania ten statyczny narzut kosztuje od 0.35 do 1.20 USD czystej redundancji schematów.
Anatomia podatku od schematów MCP
Protokół Model Context Protocol definiuje standardowy interfejs klient-serwer oparty na JSON-RPC dla możliwości LLM. Modele językowe nie są jednak w stanie wywnioskować dostępności narzędzi bez jawnego wstrzyknięcia schematu do system promptu lub bloku definicji narzędzi. Gdy inżynier podłącza serwer MCP do bazy danych z 24 narzędziami do inspekcji schematu i zapytań SQL, pełny schemat JSON musi być przedstawiony modelowi przy każdej turze wnioskowania, aby mechanizm uwagi mógł kierować wywołania narzędzi. Ponieważ standardowe rozliczanie API liczy wszystkie tokeny wejściowe przy każdym żądaniu, niekontrolowany katalog narzędzi MCP tworzy natychmiastowy, liniowy podatek bazowy nałożony na wszystkie operacje agenta.
Dlaczego definicje narzędzi MCP kosztują tyle tokenów?
Każda definicja narzędzia MCP wymaga rozbudowanych metadanych: nazw parametrów, zagnieżdżonych właściwości, czytelnych dla człowieka opisów oraz nagłówków specyfikacji JSON Schema. Pojedyncze, szczegółowe narzędzie do zapytań do bazy danych często zużywa od 350 do 600 tokenów. Przy dziesiątkach narzędzi z wielu serwerów MCP okno kontekstowe jest zajmowane przez statyczne kontrakty narzędzi, a nie przez dynamiczną historię rozmowy.
Trzy architektury eliminujące narzut MCP
Zespoły inżynierskie utrzymujące produkcyjne floty agentów stosują trzy odrębne strategie ograniczania inflacji tokenów narzędzi:
- Punkty przerwania prompt cachingu: Umieść statyczne definicje narzędzi MCP przed dynamiczną historią rozmowy w strukturze promptu i ustaw jawny breakpoint cachingu bezpośrednio po bloku narzędzi. W modelach Anthropic, OpenAI i Google Gemini, obsługujących cache o TTL 5 minut lub 1 godzina, trafienia w cache obniżają koszt wejściowy schematu narzędzi o 75% do 90% po pierwszej turze.
- Dwuetapowa dynamiczna rejestracja narzędzi: Unikaj udostępniania wszystkich narzędzi MCP globalnie. Użyj lekkiego modelu routującego lub indeksu semantycznego, aby określić domenę narzędzi potrzebną dla danego promptu użytkownika, i dynamicznie wstrzykuj do aktywnego payloadu agenta wykonawczego tylko odpowiednie 3–5 schematów narzędzi.
- Kompresja schematów i minifikacja opisów: Usuń zbędne formatowanie, wyeliminuj opisy w markdownie wewnątrz ciągów JSON Schema i zastąp długie objaśnienia pól zwartymi definicjami typów. Agresywna minifikacja schematów zwykle zmniejsza objętość definicji narzędzi o 35% do 50% bez pogorszenia trafności wyboru narzędzi.
Jak zespoły inżynierskie mogą ograniczyć narzut tokenów MCP?
Zespoły ograniczają narzut MCP, ustawiając breakpointy prompt cachingu po deklaracjach narzędzi, stosując dwuetapowy semantyczny routing narzędzi i minifikując zbędne opisy właściwości w JSON Schema.
Czy prompt caching może wyeliminować koszty schematów MCP?
Prompt caching nie usuwa w pełni opóźnień związanych z przetwarzaniem tokenów, ale drastycznie obniża koszt rozliczeniowy powtarzających się tokenów definicji narzędzi, nawet o 90% na modelach obsługujących prefix caching, pod warunkiem że blok definicji narzędzi pozostaje identyczny w kolejnych turach.
Powiązane
Chcesz zastosować to w swoim stosie? Przynieś faktury dostawców, logi bramy i najważniejsze przepływy pracy; wskażemy czynniki kosztów i ścieżkę oszczędności. Umów bezpłatny audyt →