Liczba MCP — 3-5 dobrze dobranych, nie 15 wszystkiego

Pytanie scorecard: Ile MCP serwerów masz aktywnych w głównym setupie? Odpowiedź na maks. punkty (3 pkt): 3-5 dobrze dobranych do mojego workflow (sweet spot).

Dlaczego to ma znaczenie w 2026

Instynkt, który ugryzł większość developerów pod koniec 2025, brzmiał: “MCP jest darmowe, więc instaluję wszystko.” Nie jest darmowe. Każdy podłączony MCP server wstrzykuje swój pełny katalog narzędzi do każdej wiadomości, którą wysyła agent — nazwy, opisy, schematy parametrów, całość. Pojedyncza dobrze udokumentowana definicja narzędzia kosztuje zwykle 100-500 tokenów, server z 10 narzędziami daje 1 500-3 000 tokenów czystego overheadu schematu na turę, a stack 4 serwerów z gadatliwymi opisami spala 12 000-20 000 tokenów zanim model w ogóle przeczytał Twój prompt. To kontekst, za który zapłaciłeś, a model nigdy nie użyje go do faktycznego rozumowania. Jakość outputu Claude widocznie spada powyżej około 50 wyeksponowanych narzędzi — model zaczyna odwoływać się do narzędzi zamiast odpowiadać na pytanie, ucieka w dygresje w przestrzeni listy narzędzi i myli semantycznie nakładające się czasowniki (“read_file” z filesystem MCP vs. “get_file_content” z GitHub MCP vs. “fetch” z Twojego własnego MCP). Cursor nauczył się tego boleśnie i teraz wymusza twardy limit 40 narzędzi. Konsensus 2026 mówi, że 3 serwery to sweet spot, a 5 to praktyczne maksimum na codzienną pracę — nie dlatego, że więcej jest technicznie niemożliwe, ale dlatego, że każdy serwer powyżej 5 udokumentowanie kosztuje Cię więcej w pogorszonym rozumowaniu, niż daje w nowych możliwościach. Wygrywa dopasowanie, nie liczba.

Jak wygląda “maks. punktów” w praktyce

Setup Q9 na maks. punkty jest mały, intencjonalny i nudny. Cztery MCP, każdy zarabia na swoje miejsce. Konkretny przykład dla typowego inżyniera full-stack TypeScript w 2026: GitHub MCP (@modelcontextprotocol/server-github) do PR review, triage’u issue i przeglądania repo bez wychodzenia z agenta; Context7 do pobierania aktualnej dokumentacji bibliotek on-demand (koniec z halucynowanymi API React 18, które wyleciały w React 19); Playwright/Chrome DevTools MCP do end-to-end weryfikacji w przeglądarce — agent jeździ realnym Chromium, robi screenshoty i potwierdza, że jego własne zmiany się wyrenderowały; oraz jeden MCP domenowy pod to, co płaci rachunki (Stripe MCP w codebase’ie płatności, Linear MCP do synchronizacji ticketów, Sentry MCP do triage’u błędów produkcyjnych, Polar MCP do subskrypcji). I tyle. Cztery serwery, około 25-35 łącznych definicji narzędzi, około 5 000-8 000 tokenów overheadu na turę — wyraźnie poniżej progu degradacji, a każde z tych narzędzi zarabia na swoje tokeny, bo sięgasz po nie w realnej pracy, nie “na wszelki wypadek.” Porównaj to z typowym rozdętym setupem: GitHub MCP, GitLab MCP, generyczny filesystem MCP, generyczny git MCP (już redundantny z wbudowanym Bashem Claude Code), trzy MCP do baz danych odpytywanych dwa razy w roku, Slack MCP, Notion MCP, Linear MCP, Jira MCP, dwa MCP od pogody/czasu z czyjegoś blog posta, plus cztery “fajne” MCP zainstalowane w jedno popołudnie. Trzynaście serwerów, 80+ narzędzi, 18 000 tokenów overheadu i zauważalnie głupszy agent. To jest pułapka.

Aktualny krajobraz (zweryfikowany web-search)

Publiczny rejestr MCP eksplodował z około 1 200 serwerów na koniec Q1 2025 do 3 400 do Q3 2025, 6 800 na koniec roku i ponad 9 400 do połowy kwietnia 2026 — ekspansja 7,8x rok do roku z miesięcznym wzrostem wciąż na poziomie +18% w Q1 2026. Asymetria, którą to tworzy, jest brutalna: każdy tydzień przynosi 60-80 nowych blog postów typu “musisz to zainstalować,” ale koszt każdej dodatkowej instalacji jest płacony cicho w każdej turze każdej sesji, jak długo serwer pozostaje podłączony. Rynek nie zbudował jeszcze silnych pętli zwrotnych, które wynoszą na wierzch “ten MCP czyni Twojego agenta głupszym,” więc dyscyplina musi pochodzić od developera.

Dlaczego więcej nie znaczy lepiej

Są trzy niezależne, kumulujące się efekty i każdy z osobna wystarcza, by uzasadnić cap na 3-5. Po pierwsze, surowy koszt tokenów. Definicje narzędzi siedzą w system prompcie każdej tury, nie tylko pierwszej. Stack 15 serwerów typowo zjada 15 000-25 000 tokenów overheadu schematu na turę — pomnóż przez 50-turową sesję i spaliłeś pełne okno kontekstu Sonnet 4.5 na definicje narzędzi, których model użył dwa razy. Po drugie, jakość rozumowania. Modele trenowane z tool-use RLHF były optymalizowane pod stacki 5-20 narzędzi, nie 100+. Powyżej około 50 narzędzi jakość outputu mierzalnie spada: model wybiera złe narzędzie, gdy dwa mają nakładające się opisy, odwołuje się do narzędzi które nie istnieją (halucynacje z szumu) i ucieka w dygresje uformowane przez narzędzia, gdy zwykła odpowiedź tekstowa byłaby lepsza. Benchmark MindStudio ustawił setupy MCP-heavy na 72% niezawodności w trudnych zadaniach vs. 100% dla węższych stacków. Po trzecie, podatek od dwuznaczności. Gdy trzy różne MCP eksponują czasowniki typu read_file, każde wywołanie wymaga, by model spalił tokeny na odróżnienie, który wywołać. Ten koszt kumuluje się tura po turze i jest niewidoczny — nigdy nie pojawia się jako pojedynczy zły output, tylko jako wolniejszy, lekko gorszy agent przez całą sesję.

Token overhead na MCP serwer

Konkretne liczby, użyteczne do decyzji “na palcach”: minimalny MCP server z 3 dobrze opisanymi narzędziami kosztuje ~500-900 tokenów na turę. Typowy serwer (GitHub MCP z ~25 narzędziami z rozsądnymi opisami) kosztuje ~3 000-4 500 tokenów na turę. Rozdęty serwer (niektóre ze starszych community MCP typu “kuchnia ze zlewem” z 60+ narzędziami i kopiuj-wklej długimi opisami) kosztuje 8 000-12 000 tokenów na turę — sam z siebie. Stack 4 typowych MCP kończy na około 12 000-18 000 tokenów overheadu na turę; stack 13 serwerów z jednym czy dwoma rozdętymi spokojnie przekracza 30 000 tokenów na turę. Open-source proxy mcp-compressor od Atlassian (kwiecień 2026) demonstruje skalę przez kompresję opisów narzędzi o 70-97% bez psucia wywołań — dowód, że większość tych tokenów to czysty waste. Dopóki proxy i ładowanie narzędzi on-demand nie staną się defaultem we wszystkich agentach, najtańsza optymalizacja to “instaluj mniej serwerów.”

Jak wybrać te 3-5

Trzy reguły, stosowane w kolejności. (1) Czy dotyka Twojej dziennej krytycznej ścieżki? Jeśli nie otwierasz go w typowym tygodniu realnej pracy, nie zarabia na slot. Aspiracyjne instalacje (“może kiedyś będę potrzebował MCP do bazy danych”) są pojedynczym największym źródłem rozdęcia. (2) Czy pokrywa teren, którego Twój agent nie sięga bez niego? Claude Code ma już Basha, file I/O i grepa — instalacja generycznego filesystem czy git MCP duplikuje capability, którą masz już za darmo. Dobre MCP sięgają na zewnątrz lokalnego repo (realne API, realne przeglądarki, realne bazy danych, realne serwisy), nie do wewnątrz. (3) Czy ma czystą powierzchnię narzędzi? Preferuj MCP, które eksponują 5-15 dobrze nazwanych narzędzi z ostrymi opisami, ponad MCP z 40+ nakładającymi się czasownikami. Pierwszy typ dobrze się kompresuje w Twoim budżecie kontekstu; drugi to podatek od jakości, który płacisz na każdej turze. Zastosuj te trzy filtry do bieżącego .mcp.json i większość stacków skurczy się do 3-5 bez utraty żadnej realnej capability.

Usuwanie długiego ogona (wzorzec audytu)

Wzorzec audytu jest prosty i bezwzględny. Otwórz .mcp.json (lub ~/.claude/settings.json, jeśli masz globalny blok MCP), wypisz każdy serwer i dla każdego zadaj pytanie: kiedy ostatnio wywołałem narzędzie z tego MCP? Jeśli odpowiedź brzmi “w ciągu ostatnich 7 dni, na realnej pracy” — zostawiamy. Jeśli “w ciągu ostatnich 30 dni, raz, eksplorując” — odinstaluj i zainstaluj ponownie, jeśli pojawi się realny popyt. Jeśli “nigdy, zainstalowałem z blog posta” — odinstaluj natychmiast. Trackuj wywołania uczciwie przez logi sesji Claude Code (~/.claude/projects/<repo>/) lub historię Codex CLI — grepuj nazwy narzędzi serwera. Niemal każdy stack, który zaudytujesz, ujawni trzy lub cztery serwery niewywoływane od tygodni. To czysty overhead. Najtrudniejsza część jest psychologiczna: ludzie opierają się przed odinstalowaniem rzeczy, na konfigurację których poświęcili czas. Opieraj się drugiej stronie — podatek od tokenów nigdy nie śpi.

Krok po kroku: audyt i przycinanie stacku MCP

Zinwentaryzuj obecny stack. Otwórz .mcp.json w katalogu głównym repo (serwery scope’u projektu) oraz ~/.claude/settings.json lub ~/.codex/config.toml (serwery scope’u usera). Wypisz każdy MCP i przybliżoną liczbę narzędzi, które każdy eksponuje — claude mcp list i claude mcp get <name> to wypisują, jeśli nie chce Ci się liczyć ręcznie. Spisz listę na papierze. Jeśli przekracza 7 wpisów, prawie na pewno tracisz tokeny i jakość na overhead.
Oceń każdy serwer pod trzy filtry. Dla każdego serwera odpowiedz na piśmie: (1) czy wywołałem z niego narzędzie w ciągu ostatnich 7 dni realnej pracy? (2) czy pokrywa teren, którego built-iny mojego agenta nie sięgają? (3) czy powierzchnia narzędzi jest mała i ostra, czy 40+ gadatliwych czasowników? Trzy “tak” zarabia na pozostawienie. Cokolwiek innego zarabia silne nachylenie ku odinstalowaniu.
Bezwzględnie identyfikuj duplikaty. Generyczny filesystem MCP + wbudowane Read/Write Claude Code = duplikat, odinstaluj MCP. Generyczny git MCP + Bash + CLI gh = duplikat, odinstaluj. GitHub MCP + GitLab MCP, gdy używasz tylko jednego providera = odinstaluj nieużywany. Dwa MCP do baz danych dla tego samego silnika = wybierz lepiej utrzymywany. Każdy duplikat płaci koszt tokenów dwa razy za tę samą capability.
Tnij do czterech serwerów plus jeden opcjonalny piąty. Celuj w kanoniczny kształt max-score: jeden MCP do współpracy nad kodem (GitHub lub GitLab), jeden MCP do dokumentacji (Context7), jeden MCP do przeglądarki (Playwright lub Chrome DevTools) i jeden MCP domenowy pod to, na czym faktycznie pracujesz (Stripe, Linear, Sentry, Polar, Notion — wybierz jeden). Piąty slot jest OK, jeśli naprawdę widzi tygodniowe użycie. Szósty musi wyprzeć jednego z pierwszych pięciu, a nie ułożyć się na wierzchu.
Odinstaluj długi ogon w jednym przejściu. Dla Claude Code: claude mcp remove <name> per serwer, lub edytuj .mcp.json bezpośrednio i usuń blok. Dla Codex CLI: edytuj ~/.codex/config.toml i usuń tabelę [mcp_servers.<name>]. Zrestartuj agenta, by zmiany weszły w życie. Nie pomijaj restartu — listy MCP serwerów są ładowane na starcie sesji, nie per turę.
Zweryfikuj, że overhead tokenów faktycznie spadł. Wystartuj świeżą sesję, daj agentowi trywialny prompt (wymień jakie masz narzędzia) i sprawdź długość listy narzędzi. Jeśli trzymasz przybliżony szacunek (średnio 200-400 tokenów na narzędzie), powinieneś zobaczyć spadek overheadu per-turę z “alarmującego” na “pomijalny.” Komendy /cost i /context Claude Code też to pokazują; użyj ich, by potwierdzić, że wygrana jest realna, nie teoretyczna.
Zablokuj stack w repo. Zacommituj .mcp.json, żeby Twoje przyszłe ja i Twoi koledzy z zespołu dziedziczyli wyselekcjonowane 3-5, a nie cokolwiek ad-hoc, co akurat siedzi na Twoim laptopie. Dodaj jednolinijkowy komentarz wyjaśniający dlaczego każdy serwer jest na liście. To artefakt, który zapobiega następnemu cyklowi rozdęcia za pół roku, gdy zapomnisz, które były warte zostawienia.

Częste pułapki

Instalowanie “na wszelki wypadek.” Pojedynczym największym źródłem rozdęcia MCP jest aspiracyjna instalacja: “może kiedyś będę odpytywał bazę z agenta, więc dodam Postgres MCP teraz.” Ten MCP potem siedzi w stacku 14 miesięcy, opodatkowuje każdą turę, nigdy nie zostaje wywołany. Reguła: instaluj w dniu, gdy masz konkretne zadanie, które tego potrzebuje, nie wcześniej.
Duplikowanie funkcjonalności. Filesystem MCP, git MCP, “shell” MCP, “everything” MCP — to duplikaty capability, które Twój agent terminalowy ma już natywnie przez Basha i wbudowane narzędzia do plików. Wyglądają niegroźnie, ale każdy dodaje 1 000-3 000 tokenów overheadu za capability, która była darmowa. Audytuj specyficznie pod kątem built-in duplikatów najpierw.
Traktowanie liczby jako metryki. Ludzie chwalą się “mam 22 MCP!” tak, jak kiedyś chwalili się liczbą rozszerzeń VS Code. Poprawny brag w 2026 jest odwrotny: “mam 4 MCP i wszystkie widzą codzienne użycie.” Liczba jest anty-sygnałem powyżej 5.
Mieszanie MCP do prywatnej ciekawości z MCP do pracy. Weather MCP, time MCP, joke MCP, “zapytaj LLM o astronomię” MCP — fajne do zainstalowania raz, ale potem siedzą w stacku i konsumują kontekst dla każdego zadania w pracy na zawsze. Albo trzymaj je w osobnym scratch projekcie, albo nie instaluj wcale. Twój główny stack roboczy powinien wyglądać jak kuchnia profesjonalna — ostry, rzadki, każde narzędzie zarabia na swoją szufladę.
Zapominanie, że MCP serwery kosztują tokeny też na modelach Tier 1 (tanich). Niektórzy myślą: “zarutuję do Haiku zadania tanie, overhead MCP nie ma znaczenia.” Ma znaczenie — okno kontekstu Haiku jest mniejsze, więc overhead MCP konsumuje większy jego ułamek. Stack 15 MCP na Haiku potrafi zjeść 25% kontekstu definicjami narzędzi, zanim cokolwiek się wydarzy.
Brak audytu w rytmie. Czysty stack dziś dryfuje z powrotem do rozdęcia w 6 miesięcy, bo każdy nowy blog post dodaje jeszcze jeden “niezbędny” serwer. Zaplanuj kwartalny audyt MCP — zaproszenie w kalendarzu, 15 minut, przejdź trzy filtry z powyższego wzorca audytu. Ten jeden powtarzalny nawyk trzyma Q9 na maks. punktach na zawsze.

Jak zweryfikować, że jesteś na miejscu

Twój .mcp.json ma między 3 a 5 serwerów — nie 8, nie 12, nie 20.
Każdy serwer w pliku był wywoływany na realnej pracy w ciągu ostatnich 7 dni.
Żadne dwa serwery nie eksponują nakładających się czasowników (brak kolizji read_file + get_file_content + fetch).
Twój stack pokrywa cztery strefy funkcjonalne: współpraca nad kodem, dokumentacja, przeglądarka/weryfikacja, jeden domenowy.
Overhead listy narzędzi per-turę jest poniżej ~8 000 tokenów (przybliżony check: liczba narzędzi × 250).
Potrafisz w jednym zdaniu na serwer wyjaśnić, dlaczego każdy zarabia na swój slot.
Usunąłeś co najmniej jeden MCP serwer w ciągu ostatnich 90 dni, który okazał się nie odrabiać swojej wagi.
Twój .mcp.json jest zacommitowany do repo z jednolinijkowym komentarzem wyjaśniającym rolę każdego serwera.

Dalsze materiały

Q10 · Essential MCP trio GitHub + Context7 + browser MCP pokrywa większość workflow — kanoniczna trójka startowa.

Q11 · Budowanie MCP Kiedy instalować, a kiedy pisać własne — i minimalny działający MCP.

Q8 · Agent skills Skills pokrywają luki, gdzie MCP byłby przerostem — lżejsze, lokalne dla repo, bez podatku od tokenów.

Zrób Developer Scorecard Zobacz gdzie stoisz w 25 pytaniach.