Redukcja kosztu tokenów MCP dzięki wykonywaniu kodu

Podłączyłeś serwer GitHub, serwer bazy danych, serwer przeglądarki i serwer dokumentacji. Przydatne — z tym wyjątkiem, że agent na początku każdej tury wciąga teraz do okna kontekstu definicje wszystkich narzędzi z całej czwórki, niezależnie od tego, czy ich używa, czy nie. Pojedynczy Chrome DevTools MCP ładuje dziesiątki schematów narzędzi. Zanim napiszesz choćby jedno słowo, dziesiątki tysięcy tokenów przepadają, odpowiedzi są wolniejsze, a model od czasu do czasu sięga po niewłaściwe narzędzie, bo wpatruje się w czterdzieści naraz.

Istnieje lepszy sposób na podpięcie serwerów o dużym wachlarzu narzędzi do agenta: pozwól modelowi wywoływać je jako kod, na żądanie, zamiast wstępnie ładować każdy schemat. Zespół inżynieryjny Anthropic udokumentował ten wzorzec “wykonywania kodu z MCP” w listopadzie 2025, a w jednym z ich przykładów skrócił on przepływ pracy z około 150 000 tokenów definicji narzędzi i wyników pośrednich do mniej więcej 2 000 — redukcja o 98,7%.

Co wyniesiesz z tego rozdziału

• Dlaczego każdy podłączony serwer MCP obciąża okno kontekstu, zanim rozmowa się zacznie
• Wzorzec wykonywania kodu: prezentowanie narzędzi MCP jako kodu, który agent czyta na żądanie
• Praktyczny przepis na opakowanie dowolnego serwera MCP w jednokomendowe CLI
• Regułę decyzyjną wskazującą, kiedy ten wzorzec się opłaca, a kiedy to przesada

Dlaczego schematy narzędzi MCP są kosztowne

Każdy podłączony serwer MCP wstrzykuje pełną listę swoich definicji narzędzi — nazwy, opisy i schematy JSON dla każdego parametru — do kontekstu modelu na początku każdego żądania. Oszczędny serwer dodaje 500-2000 tokenów. Bogaty, jak serwer przeglądarki lub platformy chmurowej z ponad trzydziestoma narzędziami, może dodać znacznie więcej. Podłącz kilka i wydajesz realny kontekst na funkcje, których w tej sesji możesz nigdy nie tknąć.

Nakładają się tu dwa koszty:

1. Podatek tokenowy z góry. Opisy narzędzi siedzą w prompcie systemowym przy każdej turze, konkurując o miejsce z twoimi plikami i rozmową.
2. Przeciążenie wynikami pośrednimi. Gdy narzędzie zwraca 20 000 znaków JSON-a, ten wynik również ląduje w kontekście — a jeśli łączysz wywołania w łańcuch (odczyt z jednego serwera, transformacja, zapis do innego), każdy ładunek pośredni przepływa przez model.

Przewodnik po najlepszych praktykach MCP radzi sobie z pierwszym kosztem, ograniczając cię do 3-5 aktywnych serwerów. Wykonywanie kodu atakuje oba koszty naraz i pozwala trzymać ciężki serwer dostępny bez płacenia za niego przy każdej turze.

Wzorzec wykonywania kodu

Pomysł jest prosty: zamiast prezentować narzędzia jako schematy, które model musi trzymać w kontekście, prezentujesz je jako kod w systemie plików, który model czyta na żądanie. Agent pisze mały skrypt wywołujący tylko te narzędzia, których potrzebuje, uruchamia go w piaskownicy i dostaje z powrotem wyłącznie wynik końcowy — a nie każdy ładunek pośredni.

Anthropic ujmuje korzyści tak:

• Stopniowe ujawnianie. Model ładuje definicję narzędzia dopiero wtedy, gdy zdecyduje się go użyć, tak samo jak czyta plik źródłowy dopiero wtedy, gdy jest istotny — zamiast czytać je wszystkie z góry.
• Wyniki oszczędne kontekstowo. Dane są filtrowane i przekształcane w środowisku wykonawczym, zanim cokolwiek wróci do modelu, więc zapytanie zwracające 20 000 wierszy może wrócić jako trzy wiersze, które miały znaczenie.
• Kompozycja. Agent może połączyć kilka wywołań narzędzi w jednym skrypcie i utrwalić wyniki pośrednie, zamiast przepuszczać każdy krok tam i z powrotem przez okno kontekstu.

Notatka

To wymiana jednego kosztu na inny: potrzebujesz miejsca do uruchamiania kodu (piaskownica, CLI, plik roboczy). Dla pojedynczego, lekkiego serwera ten narzut się nie opłaca. Wzorzec błyszczy, gdy serwer ma wiele narzędzi, zwraca duże ładunki lub jest wywoływany wielokrotnie w pętli.

Praktyczny przepis: opakuj serwer MCP jako CLI

Nie musisz budować piaskownicy, żeby uzyskać większość korzyści. Najbardziej przystępna wersja tego wzorca to skompilowanie serwera MCP do pojedynczego narzędzia wiersza poleceń i przekazanie agentowi tej komendy wraz z jej --help. Model uczy się wtedy interfejsu na żądanie — wywołując --help raz — zamiast nosić każdy schemat narzędzia przez całą sesję.

Narzędzie społecznościowe mcporter (autorstwa Petera Steinbergera) generuje samodzielne CLI z dowolnego serwera MCP:

# Generate and compile a standalone CLI from any MCP server.
# Drop --command when the inline command is the first positional argument.
npx mcporter generate-cli "npx -y chrome-devtools-mcp@latest" --compile

To produkuje pojedyncze binarium opakowujące każde narzędzie udostępniane przez serwer. Teraz, zamiast podłączać serwer i ładować jego schematy, agent uruchamia CLI:

# The agent discovers the interface on demand — one --help call, not 30 schemas
./chrome-devtools-mcp --help
# → it then calls only the subcommands it needs, generated from the server's real
#   tool names (navigate_page, performance_start_trace, performance_stop_trace, …)

Chrome DevTools MCP to dobry kandydat właśnie dlatego, że jest bogaty w narzędzia — udostępnia śledzenie wydajności, inspekcję konsoli, monitorowanie sieci, wprowadzanie danych do DOM i zrzuty sterty. Załadowany jako zwykły serwer MCP, wszystkie te schematy siedzą w kontekście przy każdej turze. Opakowany jako CLI, agent wciąga tylko tę jedną podkomendę, którą faktycznie wywołuje.

Wszystkie trzy narzędzia obsługują CLI tak samo — przez swoje narzędzie powłoki/Bash — więc ten wzorzec jest niezależny od narzędzia:

Cursor

Agent Cursora uruchamia polecenia terminalowe bezpośrednio. Wskaż mu skompilowane CLI w regule projektu lub w prompcie: “Use ./chrome-devtools-mcp --help to discover the interface, then run a performance trace.” Schematy narzędzi nigdy nie trafiają do kontekstu modelu — tylko wyjście komendy.

Claude Code

Claude Code uruchamia CLI przez swoje narzędzie Bash, a przepis możesz opakować w skill, aby agent ładował instrukcję użycia tylko wtedy, gdy jest istotna. Komponuje się to z własnym modelem stopniowego ujawniania Claude Code: skill kosztuje prawie nic, dopóki agent nie uzna, że jest potrzebny.

Codex

Codex wywołuje CLI przez swoje narzędzie powłoki w obrębie skonfigurowanej piaskownicy. Ponieważ binarium jest samodzielne, nie ma serwera MCP do zarejestrowania w ~/.codex/config.toml ani kosztu schematów na turę — agent po prostu wykonuje komendę i czyta wynik.

Wskazówka

Gotowy prompt do zastosowania tego wzorca:

“We have a compiled CLI at ./chrome-devtools-mcp that wraps an MCP server. Do NOT ask me to load it as an MCP server. Instead, run ./chrome-devtools-mcp --help to learn the available subcommands, then use only the subcommand needed to capture a performance trace of http://localhost:3000 and report the largest contentful paint. Keep raw output out of your summary — give me just the LCP value and the top blocking resource.”

Kiedy po to sięgnąć

Ten wzorzec to optymalizacja, nie domyślny wybór. Trzymaj się prostszego podejścia “podłącz serwer normalnie”, dopóki nie odczujesz jednego z tych bólów:

Sięgnij po wykonywanie kodu, gdy…	Zostań przy normalnym połączeniu MCP, gdy…
Serwer udostępnia wiele narzędzi (10+), z których rzadko korzystasz ze wszystkich	Masz 1-3 lekkie serwery
Odpowiedzi narzędzi są duże (schematy, zrzuty zapytań, treść strony)	Odpowiedzi są małe i czytasz je w całości
Wywołujesz serwer wielokrotnie w pętli lub wsadzie	Wywołujesz go sporadycznie i interaktywnie
Łączysz w łańcuch kilka serwerów, a dane pośrednie to szum	Wystarcza ci pojedyncza wymiana tam i z powrotem

Uwaga

Uruchamianie kodu napisanego przez agenta na twoich narzędziach to realna granica zaufania. Opakowuj serwery, którym ufasz, ograniczaj zakres dostępu CLI do sieci i systemu plików, i przejrzyj, co robi skrypt agenta, zanim uruchomi się na czymkolwiek, co potrafi zapisywać. Model zagrożeń znajdziesz w Bezpieczeństwie MCP.

Kiedy coś się psuje

Skompilowane CLI nie może znaleźć serwera. Wygenerowane CLI może odwoływać się do serwera MCP względną ścieżką; uruchom je z katalogu, w którym zostało wygenerowane, albo wygeneruj ponownie z komendą bezwzględną. Uruchom ponownie mcporter generate-cli, jeśli pakiet bazowego serwera się zaktualizował.

Agent uparcie próbuje “podłączyć” CLI jako serwer MCP. Jest uwarunkowany, by traktować rzeczy związane z MCP jako serwery. Zaznacz wprost w prompcie (a najlepiej w regule projektu), że to zwykłe CLI do uruchomienia, a nie do rejestrowania.

Zużycie tokenów nie spadło. Jeśli agent wrzuca pełne wyjście CLI do podsumowania, zaoszczędziłeś na schematach, ale nie na wynikach. Poinstruuj go, by filtrował w skrypcie/komendzie i zwracał tylko to, czego potrzebujesz — to właśnie tam kryje się większość oszczędności.

Wzorzec jest wolniejszy dla trywialnych zadań. Generowanie i wywoływanie CLI dodaje narzut. Dla jednego czy dwóch lekkich serwerów normalne połączenie MCP jest szybsze i prostsze — nie przeoptymalizowuj.

Co dalej

Najlepsze praktyki MCP Zarządzanie oknem kontekstu, liczba serwerów, cache'owanie i debugowanie.

Automatyzacja przeglądarki przez MCP Chrome DevTools MCP i Playwright do pracy w przeglądarce sterowanej przez agenta.

Budowanie własnych serwerów MCP Napisz własny serwer, gdy żaden istniejący nie pasuje.

Bezpieczeństwo MCP Ograniczaj uprawnienia i broń się przed prompt injection.