Code execution w MCP: efektywność tokenowa dla złożonych agentów

Wykonywanie kodu z MCP to wzorzec działania agentów, w którym agent AI zamiast wielu pojedynczych wywołań narzędzi pisze i uruchamia kod, który programowo wywołuje narzędzia MCP w sandboksie. Zauważalnie zmniejsza to zużycie tokenów i opóźnienia, ponieważ definicje narzędzi i wyniki pośrednie są przetwarzane w kontekście kodu, zamiast w całości przechodzić przez okno kontekstowe modelu językowego. To optymalizacja dla złożonych przepływów pracy z dużą ilością danych, a nie zastępstwo dla klasycznych wywołań narzędzi.

Szybkie odpowiedzi

• Czym jest: agent generuje program, który wywołuje narzędzia MCP jak funkcje; do modelu wraca tylko skondensowany wynik końcowy.
• Do czego się przydaje: efektywność pod względem tokenów i opóźnień przy wielu narzędziach, wielu krokach i dużych wynikach pośrednich.
• Czego wymaga: izolowanego sandboksa, tokenów o ograniczonym zakresie i zasady najmniejszych uprawnień, bo wykonywalny kod modelu to osobna powierzchnia ataku.

Problem: wywołania narzędzi słabo się skalują

Model Context Protocol (MCP) został wprowadzony przez Anthropic 25 listopada 2024 roku jako otwarty standard łączenia aplikacji AI z systemami zewnętrznymi, takimi jak systemy plików, bazy danych, aplikacje biznesowe i narzędzia deweloperskie. Technicznie MCP opiera się na JSON-RPC 2.0 i dwóch standardowych transportach: stdio dla serwerów lokalnych oraz transporcie HTTP, który rewizja specyfikacji 2025-03-26 (marzec 2025) przestawiła z dotychczasowego HTTP+SSE na Streamable HTTP. Ta sama rewizja wprowadziła OAuth 2.1 i adnotacje narzędzi. Dodany wtedy również batching JSON-RPC został ponownie usunięty w rewizji 2025-06-18. W 2026 roku MCP jest de facto standardem komunikacji agentów z narzędziami; 9 grudnia 2025 roku Anthropic przekazał protokół nowo założonej Agentic AI Foundation (AAIF) pod egidą Linux Foundation. W tym czasie, według Anthropic, SDK notowały ponad 97 milionów pobrań miesięcznie w Pythonie i TypeScripcie.

W klasycznym wzorcu agent wywołuje każde narzędzie osobno. Każde wywołanie przechodzi przez model językowy (LLM): model widzi definicję narzędzia, formułuje wywołanie, otrzymuje pełny wynik z powrotem do okna kontekstowego i decyduje o kolejnym kroku. Przy prostych zadaniach to idealne rozwiązanie: przejrzyste i łatwe do audytu. W złożonych przepływach pracy pojawiają się jednak dwa pożeracze tokenów:

1. Definicje narzędzi ładowane z góry. Jeśli agent ma do dyspozycji dziesiątki lub setki narzędzi MCP, ich opisy trzeba z góry załadować do kontekstu. To często tysiące tokenów, zanim agent w ogóle zacznie pracę.
2. Wyniki pośrednie w kontekście. Narzędzie, które zwraca długą listę, duży dokument lub obszerną odpowiedź API, zapisuje ją w całości w oknie kontekstowym, nawet jeśli agent potrzebuje z niej tylko trzech wartości. W łańcuchach wieloetapowych to się sumuje.

Rozwiązanie: agent pisze kod

Wzorzec wykonywania kodu, który Anthropic opublikował pod koniec 2025 roku jako podejście inżynieryjne, odwraca logikę. Agent generuje program, zwykle w Pythonie lub TypeScripcie, który traktuje narzędzia MCP jak importowalne funkcje. Ten kod działa w sandboksie. Filtrowanie, pętle, rozgałęzienia i agregacje odbywają się tam, w kontekście wykonania kodu. Do okna kontekstowego modelu wraca tylko skondensowany wynik końcowy.

Różnicę dobrze pokazuje pseudokod. Zadanie: agent ma znaleźć w CRM wszystkie kontakty, których ostatnie zamówienie przyniosło ponad 10 000 euro przychodu.

Podejście klasyczne, z wieloma wywołaniami narzędzi przez model:

LLM: ruf get_contacts() auf

-> 5.000 Kontakte (vollständig in den Kontext)

LLM: für jeden Kontakt ruf get_last_order(id) auf

-> 5.000 weitere Tool-Calls, jeder einzeln durchs Modell

LLM: filtere die mit Umsatz > 10.000

-> erneut große Datenmengen im Kontext

Wykonywanie kodu, z wygenerowanym programem:

# vom Agenten generierter, in der Sandbox ausgeführter Code

kontakte = mcp.crm.get_contacts()

umsaetze = {k.id: mcp.crm.get_last_order(k.id).umsatz for k in kontakte}

return [{"name": k.name, "umsatz": umsaetze[k.id]} for k in kontakte if umsaetze[k.id] > 10000]

W drugim przypadku model nie widzi ani 5000 kontaktów, ani 5000 odpowiedzi z zamówieniami. Widzi tylko kod, który sam napisał, a na końcu przefiltrowaną listę. Same wywołania narzędzi odbywają się programowo, a nie jako osobne rundy LLM. To ogranicza zarówno zużycie tokenów, jak i opóźnienia, bo pętle wykonują się bez kolejnych rund z modelem.

Drugim efektem jest wykrywanie narzędzi na żądanie: zamiast ładować z góry wszystkie definicje narzędzi, agent może przeglądać dostępne serwery MCP i ich funkcje jak katalog modułów i importować tylko te, których faktycznie potrzebuje. Dzięki temu narzut na starcie pozostaje mały, nawet jeśli teoretycznie dostępne byłyby setki narzędzi.

Przykład w liczbach

Uproszczone wyliczenie pokazuje skalę tej dźwigni. Założenie: agent ma wyłonić z CRM najważniejszych klientów i uzupełnić ich dane o informacje o zamówieniach. Liczby są poglądowe. Pokazują rzędy wielkości i nie są benchmarkiem. Kolumna klasyczna przedstawia przy tym najkorzystniejszy przypadek: uwzględnia tylko narzut na starcie i jedną surową listę z 5000 rekordów. Nie wliczono 5000 pojedynczych wywołań get_last_order z pseudokodu powyżej. Każde z nich oznaczałoby osobną odpowiedź z zamówieniem i jedną rundę z modelem. Klasyczna suma byłaby więc wielokrotnie wyższa.

W tabeli decydującą pozycją nie jest narzut na starcie, tylko wyniki pośrednie: są przetwarzane w kodzie i nie zajmują kontekstu modelu. Właśnie tu leży dźwignia. Im większe ilości danych i im więcej iteracji, tym większa różnica. Przy prostym pojedynczym zapytaniu rachunek się jednak odwraca: narzut związany z wygenerowaniem i uruchomieniem programu przewyższa korzyść.

Konkretne wartości Anthropic podaje we wpisie inżynieryjnym z 4 listopada 2025 roku. W przykładzie agent pobiera transkrypcję spotkania z Google Drive i dołącza ją do leada w Salesforce. Przy bezpośrednich wywołaniach narzędzi transkrypcja przechodzi przez model dwukrotnie. Przy dwugodzinnym spotkaniu może to oznaczać dodatkowe 50 000 tokenów. Jeśli narzędzia są dostępne jako pliki, a agent ładuje tylko definicje potrzebne do bieżącego zadania, zużycie według Anthropic spada ze 150 000 do 2000 tokenów, czyli o 98,7 procent.

Kiedy to ma sens, a kiedy nie

Wykonywanie kodu to optymalizacja, a nie standardowy wzorzec do wszystkiego. Pasuje do powtarzalnych przepływów pracy z wieloma narzędziami, które przetwarzają dużo danych. Przy prostych, jednorazowych akcjach bezpośrednie wywołania narzędzi pozostają szybsze, tańsze i bardziej przejrzyste: ślad pokazuje każdy krok bezpośrednio, bez pośrednictwa wygenerowanego kodu.

Bezpieczeństwo: sandbox to obowiązek

Największa różnica w porównaniu z klasycznymi wywołaniami narzędzi dotyczy bezpieczeństwa: we wzorcu wykonywania kodu system uruchamia wykonywalny kod wygenerowany przez model językowy. To odrębna powierzchnia ataku. Dla MCP w 2026 roku udokumentowany jest świadomie optymistyczny model zaufania, który utożsamia poprawność składniową z bezpieczeństwem semantycznym. Do tego dochodzą konkretne klasy ataków: pośrednie wstrzykiwanie promptów przez opisy serwerów, Tool Poisoning (PoC Invariant Labs, kwiecień 2025), squatting serwerów look-alike oraz opisane przez CyberArk Full-Schema Poisoning, w którym każda część schematu narzędzia może być wektorem wstrzyknięcia. Utwardzanie zabezpieczeń jest przy tym wyraźnie zadaniem operatora.

W przypadku wykonywania kodu oznacza to konkretnie:

• Izolowany sandbox. Wygenerowany kod działa w odizolowanym środowisku uruchomieniowym bez szerokiego dostępu do plików i sieci, z limitami zasobów i czasu, które chronią przed nieskończonymi pętlami i wyczerpaniem zasobów.
• Tokeny o ograniczonym zakresie. Serwery MCP za OAuth 2.1 (od rewizji specyfikacji 2025-03-26, marzec 2025) z minimalnymi niezbędnymi uprawnieniami. Kod dostaje dostęp tylko do tego, czego wymaga zadanie.
• Zasada najmniejszych uprawnień i żadnej autonomicznej instalacji. Agenci nie mogą samodzielnie dociągać ani instalować serwerów MCP z niezaufanych rejestrów.
• Pełne logowanie audytowe. Każde wywołanie narzędzia z kodu w sandboksie jest rejestrowane, z pełnym śladem end-to-end, przypiętymi wersjami modeli i korelacją przez identyfikator śladu (trace ID). W regulowanych branżach w Europie audytorzy i organy nadzoru mogą wymagać takich dowodów.

Kto uruchamia wykonywalny kod modelu bez tych warstw ochrony, płaci za efektywność tokenową poważnym ryzykiem dla bezpieczeństwa i ochrony danych. W regulowanych branżach w Europie to wykluczone.

Dla agencji i decydentów B2B

Dla agencji w Europie i dostawców AI, którzy przekształcają swoje usługi w produkty, wykonywanie kodu z MCP jest bezpośrednią dźwignią dla unit economics produktów agentowych. Kto prowadzi usługi multi-tenant (na przykład agentów SEO, newsletterowych lub badawczych), płaci za każdy przebieg w tokenach; wzorzec wykonywania kodu wymiernie obniża te koszty w przepływach pracy z dużą ilością danych, a jednocześnie zmniejsza opóźnienia, co poprawia postrzeganą jakość produktu. Na start warto przejrzeć istniejących agentów opartych na MCP pod kątem tego, które przepływy pracy przechodzą przez wiele narzędzi i duże wyniki pośrednie, przestawić właśnie te na wykonywanie kodu i od pierwszego dnia wbudować sandbox, zakresy OAuth 2.1 i logowanie audytowe. Dla decydentów B2B najważniejsze jest to: wzorzec to decyzja architektoniczna podejmowana osobno dla każdego przepływu pracy, a nie zmiana platformy. Opiera się na i tak już ugruntowanym standardzie MCP i można go wdrażać stopniowo, bez odrzucania istniejącej integracji narzędzi.