MCP w codziennej pracy inżyniera: lekkie sesje, ciężkie serwery na żądanie

TL;DR: MCP, czyli Model Context Protocol, to otwarty protokół, przez który agent kodujący łączy się z zewnętrznymi narzędziami i danymi. W mojej codziennej pracy miejsce zarabia pięć rodzajów serwerów: logi platformy, powiązania z danymi platformy, dostęp do lokalnej lub testowej bazy, automatyzacja przeglądarki i analityka produktowa. Każdy podłączony serwer kosztuje coś w każdej sesji, więc domyślnie ładują się tylko dwa, a ciężkie dochodzą z profilem wybranym przy starcie sesji. Dzięki odroczonym schematom narzędzi stały koszt sprowadza się do nazw narzędzi. Po stronie ryzyka nie ma dyskusji: zgody tylko do odczytu, testowe bazy i żadnych zapisów na produkcji z sesji agenta. Z serwerów MCP korzystam codziennie, ale własnego jeszcze nie opublikowałem.

Każdy serwer to podatek od każdej sesji

Problem dał o sobie znać przez kilka dni z rzędu: sesje wydawały się powolne. Przyczyną była lista serwerów MCP podpiętych do projektu. Każdy z nich kosztuje coś w każdej sesji, niezależnie od tego, czy sesja go używa: połączenie przy starcie, nazwy narzędzi w oknie kontekstu, a przy niektórych serwerach jeszcze więcej. Jeden serwer analityczny dorzuca do promptu spory blok instrukcji użycia. Jeden serwer z danymi o słowach kluczowych to lokalny proces uruchamiany przez npx przy każdym starcie. Przy zimnym cache paczek startował tak wolno, że musiałem podnieść timeout startu MCP. Trzy najcięższe serwery były potrzebne w mniejszości rozmów, a płaciłem za nie we wszystkich.

Jest też koszt fizyczny. Resztki procesów serwerów z wcześniejszych sesji, zwłaszcza instancja automatyzacji przeglądarki, zbierają się na maszynie, dopóki czegoś nie zabijesz. Na laptopie widać to jako ciepło i szum wentylatora, zanim zobaczysz to gdziekolwiek indziej.

Które serwery MCP naprawdę warto podłączyć?

Oto rodzaje serwerów, które zostawiam, w kolejności, w jakiej po nie sięgam. Żaden nie jest egzotyczny: to oficjalne albo powszechnie używane serwery platform, na których i tak już pracuję.

• Observability platformy. Logi i analityka żądań moich Cloudflare Workers, odpytywane z poziomu sesji zamiast z dashboardu. Incydenty są pilne, więc ten serwer ładuje się zawsze.
• Powiązania platformy. Zapytania do brzegowej bazy SQL i magazynów klucz-wartość aplikacji, nad którą pracuję. Zastępuje mnóstwo kopiowania i wklejania między terminalem a rozmową.
• Lokalne i testowe bazy danych. W innym produkcie agent dostaje lokalnego Postgresa i testowy projekt hostowanej bazy. To wystarczy, żeby czytać schematy i uruchamiać doradców dostawcy, którzy wskazują brakujące indeksy i wolne zapytania. Produkcji na tej liście nie ma.
• Automatyzacja przeglądarki. Playwright przez MCP to mój sposób na empiryczne sprawdzanie zachowania. Kiedy chciałem wiedzieć, czy strona nadal robi prefetch dziesiątek tras, agent otworzył build produkcyjny, przewinął na sam dół i wypisał żądania sieciowe odfiltrowane do wywołań prefetch. Pusta lista oznaczała, że poprawka działa.
• Analityka produktowa. PostHog przez MCP do alertów, zapytań SQL po zdarzeniach i ustawień projektu. Jedna zmiana ustawienia zrobiona tą drogą, czyli minimalna długość sesji dla nagrań, od razu powstrzymała wizyty skanerów przed przepalaniem limitu nagrań. Bez żadnego deployu.
• Dane marketingowe. API z danymi o słowach kluczowych i platforma reklamowa. Przydatne w sesjach marketingowych, wszędzie indziej to martwy balast.

Jeden serwer usunąłem całkowicie: serwer dokumentacji. Agent wystarczająco dobrze czyta oficjalną dokumentację zwykłym pobraniem strony, a jeśli to kiedyś przestanie działać, przywrócenie serwera to jedna linijka.

Globalnie, per repo czy per sesja?

Wypróbowałem trzy sposoby decydowania, jakie serwery dostaje sesja.

• Konfiguracja globalna. Wszystko dostępne wszędzie, nie trzeba o niczym pamiętać. Cena jest taka, że każda sesja w każdym projekcie płaci za każdy serwer, także za te, których projekt nigdy nie dotyka. Kiedy to sprawdziłem, dwa serwery ładujące się w jednym projekcie należały do platform, z których ten projekt w ogóle nie korzystał.
• Per repo, commitowane razem z kodem. Właściwe serwery dla projektu, przeglądane jak każdy inny config. Tyle że ciężkie serwery, których potrzebuje jeden rodzaj sesji, nadal ładują się we wszystkich sesjach w tym repo.
• Domyślny zestaw per repo plus profile per sesja. Mały zestaw domyślny w repo i pliki profili, które dokładają serwery przy starcie sesji. Tak pracuję obecnie.

W produkcie, od którego to się zaczęło, domyślny zestaw to tylko serwer observability i serwer powiązań. Profile dokładają serwer z danymi SEO, serwer reklamowy albo serwer analityczny. Cały mechanizm opiera się na dwóch zachowaniach CLI. Dodatkowe pliki konfiguracji MCP przekazane przy starcie nakładają się na config z repo. Flaga strict bez dodatkowych plików uruchamia sesję bez żadnego serwera, do pracy, która ich nie potrzebuje. Mały launcher czyta opis zadania, który wpisuję, wybiera profil po słowach kluczowych i startuje sesję z pasującymi serwerami, modelem i poziomem effort.

# illustrative shape of the launch flow
agent "fix the bug in the scan"     # default: logs + bindings
agent "keyword volumes for a page"  # default + SEO data server
agent --no-mcp "fix a typo"         # zero servers

Nie ma podpinania w locie: lista serwerów jest ustalana w chwili startu procesu. Tę lukę pokrywają dwa wzorce. Pierwszy to wyjście i restart z właściwym profilem oraz flagą wznawiającą ostatnią rozmowę. Kosztuje to około dwudziestu sekund i zachowuje pełny kontekst. Drugi to wyjście awaryjne dla serwerów, których dane uwierzytelniające już są na mojej maszynie: z krótką, spisaną ściągawką z HTTP API dostawcy pojedyncze zapytanie idzie przez curl w lekkiej sesji, w ogóle bez restartu. Serwery, które uwierzytelniają się przez hostowany przepływ OAuth, nie mają takiego wyjścia awaryjnego.

Dwie konsekwencje poznałem, potykając się o nie. Subagenty dziedziczą serwery sesji, w której działają, więc agent potrzebujący analityki musi działać w sesji uruchomionej z tym profilem. A drugie CLI, którego używam obok Claude Code, ma te same serwery odwzorowane we własnym configu: domyślnie wyłączone i włączane per profil, żeby oba narzędzia widziały ten sam świat.

Odroczone schematy narzędzi i dobór narzędzi

Druga połowa taniego MCP to sposób, w jaki definicje narzędzi trafiają do modelu. Przy odroczonych schematach narzędzi, które są domyślne w obecnym Claude Code, kontekst trzyma tylko nazwy narzędzi, a pełny schemat JSON narzędzia jest pobierany w chwili, gdy agent decyduje się go użyć. Przy ośmiu serwerach, które mam skonfigurowane w różnych projektach, to różnica rzędu dziesiątek tysięcy tokenów na sesję. O tym, co jeszcze ładuje się przy starcie, pisałem w tekście o architekturze kontekstu per projekt.

Odroczenie nie naprawi źle dobranego zestawu narzędzi. Reguła, którą wziąłem z wytycznych Anthropic o pisaniu narzędzi dla agentów, sprawdza się w praktyce: jeśli człowiek nie potrafi powiedzieć, którego z dwóch narzędzi użyć w danej sytuacji, model też tego nie wie, a ty płacisz za obie próby.

Jak używać serwerów MCP do triage incydentów?

Tu MCP zwrócił się najwyraźniej. Za pierwszym razem, gdy przeglądałem przez agenta serię maili z alertami, zajęło to jedną długą sesję i mniej więcej 400 tysięcy tokenów, bo każdy krok trzeba było odkryć od zera. Za drugim razem sesja szła według spisanego runbooka i zatrzymała się na pierwszej sekcji, która odpowiadała na pytanie.

Najpierw zasady pracy: sesja diagnozuje i niczego nie restartuje ani nie deployuje, dopóki nie powiem, a każde jej twierdzenie ma pokrycie w linii logu albo w sprawdzeniu HTTP. Wstępne kroki idą równolegle: ustalić okno czasowe, wypisać Workers i puścić jedno zgrupowane zliczenie na serwis, uzyskać zgodę dla analityki i sprawdzić status krytycznych stron razem z arkuszem stylów, do którego się odwołują.

Kształty zapytań do serwera logów wymagały prób i błędów. To najbardziej uniwersalna część całości:

• Używaj widoku zagregowanego z grupowaniem. Widoki na poziomie zdarzeń rzucały błędami schematu, gdy tylko wynik zawierał wiersze z samymi logami, czyli przez większość czasu.
• Proś tylko o zliczenie. Dodanie min albo max znacznika czasu obok zliczenia zwracało puste agregacje. Pierwsze i ostatnie wystąpienie wynikają z przedziałów czasowych, które narzędzie i tak wypisuje.
• Wiersze ze statusem odpowiedzi równym zero to linie logów konsoli, a nie odpowiedzi. Żeby policzyć prawdziwe żądania, filtruj do wierszy, które mają wynik (outcome).
• Filtr z wieloma wartościami nie działał jak trzeba. Jedno zapytanie na wartość działało.

Z tym zestawem triage sprowadza się do pięciu pytań, po jednym zapytaniu na każde: czy są błędy 5xx? czy są przekroczone limity zasobów albo awarie? co się wysypało? co dało ostrzeżenie? kto spowodował skok? Jedna wersja deployu w całym oknie pozwala też wykluczyć wydanie, zanim ktoś zacznie je obwiniać.

Dlaczego logi i analityka produktowa w jednym przebiegu? Strumieniowe renderowanie po stronie serwera potrafi zamienić awarię w odpowiedź 200. Framework strumieniuje error boundary wewnątrz odpowiedzi, która już się zaczęła, więc log platformy pokazuje udane żądanie. Widzi to tylko zdarzenie błędu wysłane z hooka błędów serwera do narzędzia analitycznego. Same logi powiedziałyby mi, że serwis jest zdrowy, podczas gdy jedna strona była zepsuta. Istnieje też odwrotna ślepa plamka: strona, która zwraca 404 dla istniejącej treści, nigdzie nie zgłasza błędu i wyłapie ją tylko test syntetyczny albo crawler.

Jakie ryzyko niesie dostęp agenta przez MCP?

MCP zamienia model w coś, co może działać na prawdziwych systemach, więc model uprawnień liczy się bardziej niż lista narzędzi.

• OAuth w każdej sesji, z wyboru tylko odczyt. Serwer analityczny wymaga świeżej zgody w każdej sesji i startuje w projekcie, który był aktywny ostatnio, więc pierwsza komenda przełącza projekt. Strona zgody domyślnie prosi o zapis do wszystkiego. Za każdym razem wybieram tylko odczyt. Callback musi dotrzeć, zanim przepływ wygaśnie, dlatego przed każdym przebiegiem bez nadzoru zgoda jest pierwszą rzeczą, jaką robię.
• Powiązania z produkcyjną bazą to duża władza. Chodzi o zapytania do odczytu. Przywracanie do punktu w czasie jest siatką bezpieczeństwa dla bazy brzegowej, ale nie czyni zapisów bezpiecznymi. Zapisy na produkcji nie przechodzą przez sesję agenta.
• Testowe bazy wszędzie, gdzie się da. W produkcie z serwerami baz danych agent widzi lokalną instancję i projekt testowy.
• Twarde blokady poza rozmową. Reguły deny zatrzymują komendy CLI, które usuwają bazy albo Workers, a sam plik konfiguracji MCP jest chronioną ścieżką, której agent nie może po cichu nadpisać. Ten warstwowy układ opisałem w tekście o zabezpieczeniach, których używam.
• Dane uwierzytelniające nigdy w repo. Commitowany config MCP tylko nazywa serwery. Każdy klucz, którego potrzebuje lokalny serwer, pochodzi ze zmiennych środowiskowych mojej powłoki.

Czego nie zrobiłem i co bym ci doradził

Korzystam z serwerów MCP, ale nie napisałem ani nie opublikowałem własnego. Jak dotąd każdą lukę pokrywał oficjalny serwer albo udokumentowane HTTP API plus jednostronicowa ściągawka, czyli opisane wyżej wyjście awaryjne przez curl. Jeśli kiedyś zbuduję własny serwer, to właśnie na taki przypadek: API dostawcy, które już odpytuję z lokalnymi danymi uwierzytelniającymi, opakowane w cienki serwer tylko do odczytu. Sesja mogłaby wtedy z niego korzystać bez restartu i bez mojego wskazywania ściągawki.

• Trzymaj domyślny zestaw malutki. Serwery potrzebne podczas incydentu i nic więcej.
• Ciężkie serwery dokładaj per sesja przy starcie i naucz się flagi wznawiania, żeby dodanie serwera w trakcie zadania kosztowało sekundy.
• Zostaw schematy narzędzi odroczone i dobieraj narzędzia tak, żeby żadne dwa nie robiły tego samego.
• Spisuj kształty zapytań, które działają. To one odróżniają triage za 400 tysięcy tokenów od krótkiego.
• Czytaj logi i analitykę produktową razem, bo każde z tych źródeł jest ślepe na awarie, które widzi drugie.
• Dawaj zgody tylko do odczytu, serwery z prawem zapisu kieruj na dane testowe i trzymaj zapisy na produkcji poza sesjami agenta.