Autor: Jakub Rusinowski · Ostatnia aktualizacja 2026-08-04 · Wartości sprzętowe wyliczone naszym silnikiem VRAM
MCP daje agentowi kodującemu ustandaryzowany sposób sięgania poza siebie — po pliki, bazy danych, przeglądarki, systemy zgłoszeń. Haczyk na lokalnym sprzęcie polega na tym, że każdy podpięty serwer wstrzykuje pełny schemat swoich narzędzi do każdego żądania: garść serwerów potrafi zjeść więcej z okna 32K niż samo twoje zadanie. Podpinaj per projekt, trzymaj łączną liczbę narzędzi w granicach jednocyfrowych i wybieraj polecenie w powłoce zamiast serwera MCP wszędzie tam, gdzie robotę wykonuje już jakieś CLI.
Model Context Protocol to standardowy interfejs między agentem a systemami zewnętrznymi: serwer wystawia narzędzia z typowanymi schematami, a każdy klient mówiący po MCP może je wywołać. Rozwiązał prawdziwy problem — wcześniej każdy agent potrzebował osobnej integracji z każdym systemem — i do 2026 ekosystem zdążył urosnąć.\n\nPotem celujesz nim w lokalny model i trafiasz na ścianę, o której marketing milczy: schematy narzędzi są tokenami promptu, naliczanymi przy każdym żądaniu. Pomiary, które szeroko krążyły w 2026, wyceniają typową konfigurację z siedmioma serwerami na dziesiątki tysięcy tokenów samych definicji, zanim użytkownik cokolwiek napisze — jedna trzecia dużego okna z czołówki. Przy lokalnym oknie 16–32K to nie podatek, to cały budżet.\n\nMCP wciąż warto lokalnie używać. Trzeba je tylko racjonować.
Zanim podepniesz cokolwiek jeszcze, policz własną konfigurację. Zgrubny rachunek dla karty 24 GB serwującej 32K kontekstu:\n\n| Pozycja | Tokeny | Udział w oknie 32K |\n|---|---|---|\n| Prompt systemowy harnessu | około 4000 | 12% |\n| Trzy oszczędne serwery MCP | około 6000 | 19% |\n| Siedem typowych serwerów MCP | 25 000+ | 78% — nie do pracy |\n| Plik z regułami | około 500 | 2% |\n| Dwa edytowane pliki źródłowe | około 6000 | 19% |\n| Rozmowa i wyniki narzędzi | rośnie | cała reszta |\n\nAwaria, którą to wywołuje, jest myląca, a nie oczywista: agent nie zgłasza błędu, po prostu robi się gorszy. Okno zapełnia się, zanim ruszy właściwa praca, kompaktowanie włącza się wcześnie, a model wydaje uwagę na opisy narzędzi, po które nigdy nie sięgnie. Każdy objaw wygląda jak „model jest za mały”.\n\nSprawdź ten rachunek sam: większość klientów potrafi wypisać podpięte narzędzia, a zgrubne policzenie tokenów w opisach wystarczy. Jeśli narzędzia plus prompt systemowy przekraczają ćwierć twojego okna, tnij.
Motyw roku 2026 wśród ludzi, którzy szybko dowożą: w codziennym kodowaniu wygrywa zwykle terminal. Agent z dostępem do powłoki ma już git, rg, npm, docker, curl, psql i każde inne zainstalowane narzędzie — za *jedną* definicją narzędzia zamiast kilkudziesięciu, z wyjściem, które da się przepuścić przez potok i przyciąć.\n\nWybieraj polecenie w powłoce, gdy:\n\n- CLI już istnieje i mu ufasz. gh pr view, psql -c, docker logs. Jedno narzędzie, bez schematu, bez procesu serwera.\n- Okno jest ciasne. Poniżej 32K jedno narzędzie run_command plus dobry plik z regułami bije trzy serwery, prawie zawsze.\n- Wyjście trzeba ukształtować. CLI przepuścisz przez head, jq albo grep, zanim trafi do kontekstu. Wyniki MCP przychodzą sformatowane tak, jak zdecydował serwer.\n\nWybieraj MCP, gdy:\n\n- Nie ma dobrego CLI — automatyzacja przeglądarki to standardowy i całkiem prawdziwy przykład.\n- Potrzebujesz typowanych, ustrukturyzowanych wyników, nad którymi model może rozumować, zamiast wyłuskiwać je z tekstu.\n- Integracja wymaga poświadczeń, których wolisz nie zostawiać w historii powłoki — trzyma je wtedy proces serwera.\n- Chcesz mieć to narzędzie identycznie dostępne w kilku agentach, co jest właściwym celem tego protokołu.
Uszeregowany według wartości na token przy małym oknie. Podepnij pierwsze dwa albo trzy; kolejne dokładaj dopiero, gdy projekt tego wymaga.\n\n1. System plików (zawężony do jednego katalogu projektu) — wart zachodu, gdy wbudowane narzędzia plikowe twojego agenta są słabe. Zbędny przy Aiderze, Cline i OpenCode, które mają już dostęp do plików; tam go pomiń.\n2. Git / GitHub — historia, blame, pull requesty i zgłoszenia. Naprawdę użyteczny kontekst, do którego agent inaczej nie sięgnie. Jeśli potrzebujesz tylko lokalnej historii, git przez powłokę wychodzi taniej.\n3. Automatyzacja przeglądarki (w stylu Playwrighta) — najwyraźniejsza wygrana MCP. Przy pracy front-endowej agent, który wczyta stronę, kliknie i przeczyta konsolę, zamyka pętlę sprzężenia zwrotnego, jakiej nie da nic innego. Kosztowne tokenowo; podpinaj tylko na sesje front-endowe.\n4. Baza danych (w stylu Postgresa albo Supabase) — introspekcja schematu, żeby agent przestał wymyślać nazwy kolumn. Duża wartość przy pracy nad warstwą danych; podpinaj per projekt i tam, gdzie się da, tylko do odczytu.\n5. Serwery dokumentacji i wyszukiwania — zwykle pierwsze do wycięcia lokalnie. Plik z regułami linkujący do dwóch stron dokumentacji, z których faktycznie korzystasz, kosztuje setną część tego.\n\nWszystko inne: podepnij na sesję, która tego potrzebuje, i odepnij po niej. Konfiguracja per projekt zamiast globalnej to nawyk, który utrzymuje to w ryzach.
W ciągu 2026 pojawiły się trzy rodziny środków zaradczych, wszystkie będące wariantami stopniowego odsłaniania — nie ładuj pełnego schematu narzędzia, dopóki nie jest potrzebny.\n\n- Narzędzia odroczone i przeszukiwalne. Klient ogłasza wyłącznie *nazwy* narzędzi, a pełne schematy pobiera na żądanie. Tam, gdzie twój klient to obsługuje, jest to największa pojedyncza oszczędność.\n- Dostęp w stylu wykonywania kodu. Zamiast wystawiać kilkadziesiąt narzędzi, wystaw jedno, które uruchamia kod na powierzchni API, pozwalając modelowi komponować wywołania zamiast wybierać z menu. Znacznie mniej tokenów i lepsze dopasowanie do modeli, które dobrze piszą kod — czyli dokładnie do modelu kodującego.\n- Podpinanie per projekt. Ta mało efektowna, która działa wszędzie: konfiguracja o zasięgu projektu, wymieniająca tylko to, czego potrzebuje dane repozytorium. Dwa serwery na projekt biją dwanaście globalnie i nie wymagają żadnych funkcji po stronie klienta.\n\nNiezależnie od wszystkiego warto też przycinać wyniki MCP w harnessie. Zrzut schematu albo nieograniczone zapytanie to dziesiątki tysięcy tokenów. Ogranicz je, zostaw ogon i streść, zanim wylądują w lokalnym oknie.
Uruchomienie modelu na własnej maszynie usuwa jedną ekspozycję — twój kod nie wyjeżdża po to, żeby ktoś na nim liczył. Nie usuwa niczego z tego, co robią narzędzia. Serwer MCP to program, któremu przyznałeś dostęp do swoich plików, baz danych albo sieci, a każdy z nich jest zależnością z własnym łańcuchem dostaw. W tym ekosystemie ujawniono już systemowe podatności w implementacjach SDK, więc traktuj je jak zależności produkcyjne, nie jak wtyczki.\n\nLista kontrolna:\n\n- Czytaj to, co instalujesz. Preferuj serwery od dostawcy systemu, którego dotykają. Przypinaj wersje.\n- Zawężaj poświadczenia. Role bazodanowe tylko do odczytu, tokeny ograniczone do jednego repozytorium, żadnych długo żyjących kluczy administracyjnych.\n- Zakładaj, że wyjście narzędzia to niezaufane wejście. Treść zgłoszenia, strona internetowa albo plik pobrany przez agenta mogą zawierać instrukcje wycelowane w twojego agenta — prompt injection przez wyniki narzędzi to żywa ścieżka ataku i nie obchodzi jej, że twój model jest lokalny.\n- Trzymaj narzędzia destrukcyjne za człowiekiem. Odczyt można spokojnie zautomatyzować; zapis, wdrożenie i wszystko z efektem ubocznym po stronie sieci zasługuje na bramkę. Zbuduj to jako listę dozwolonych operacji plus sandbox, a nie jako strumień pytań, których nikt nie czyta (sandbox).\n- Najlepiej całkiem odetnij ruch wychodzący z sandboxa, chyba że zadanie go wymaga. Większość pracy z kodem nie wymaga.\n\nArgument o prywatności lokalnych modeli przechodzi przez to wszystko bez szwanku — ale tylko wtedy, gdy podpinasz narzędzia z tą samą starannością, jaką dałbyś każdej innej zależności.