Serwery MCP, których naprawdę używam codziennie — i te, które usunąłem
Uczciwa inwentaryzacja mojego zestawu: które serwery MCP zasłużyły na stałe miejsce, które wyleciały w tydzień i jaka jedna reguła je rozdziela.
Od dłuższego czasu głównym środowiskiem mojej pracy są agenci AI do kodowania, a tym, co zmieniło się najbardziej, nie jest model. To hydraulika wokół niego — serwery MCP, dzięki którym agent dotyka moich prawdziwych narzędzi, zamiast tylko o nich mówić.
Zainstalowałem ich sporo. Większość wyleciała w ciągu tygodnia. Oto uczciwa inwentaryzacja: co zostało, co poszło i jaka reguła to rozdziela.
Co zostało
Mój własny system notatek. Wszystko, co czytam, oglądam albo sobie poukładam, ląduje w jednym miejscu przez mały serwer MCP, który sam napisałem. Tego brakowałoby mi najbardziej — i nie z powodu zapisywania, tylko czytania. Kiedy zaczynam sesję nad projektem, którego nie dotykałem miesiąc, agent sam wyciąga kontekst, zamiast żebym tłumaczył go od nowa. W tym jest cała wartość.
Serwer z danymi osobistymi. Waga, sen, posiłki, subskrypcje, domeny, majątek. Napisane tak brzmi przesadnie. W praktyce oznacza to, że pytanie „którym domenom kończy się ważność w ciągu dwóch miesięcy” albo „ile wydałem w tym kwartale na narzędzia” ma odpowiedź w jednej linijce zamiast wyprawy po arkuszach.
Projekty i zadania. Mój własny system produktowo-zadaniowy wystawiony przez MCP. Agent widzi, czym jest projekt, co jest zablokowane i jakie są kryteria akceptacji. Bez tego każda sesja zaczyna się od wklejania wciąż tego samego kontekstu.
Headless CMS. Ten zaskoczył mnie tym, jak często go używam. Opublikowanie wpisu z terminala — razem z poprawnie powiązanymi tłumaczeniami na cztery języki — to robota na pięć minut zamiast popołudnia kopiuj-wklej. Wszystkie moje strony biorą dziś stąd treść.
Dostęp do designu i przeglądarki. Figma, żeby wyciągać prawdziwe specyfikacje komponentów zamiast zgadywać, i sterowanie przeglądarką do rzeczy, które istnieją wyłącznie za logowaniem. Jedno i drugie używane rzadko, ale w potrzebie nie do zastąpienia.
Księgowość. Faktury, wydatki, kontrahenci. Bardzo nudne. Oszczędza godzinę miesięcznie, czyli dokładnie ten właściwy rodzaj nudy.
Co usunąłem
Wszystko, co zwraca ogromne bloki danych. Zabójca numer jeden. Serwer, którego wywołanie „list” zwraca każde pole każdego rekordu, spali okno kontekstu jednym callem i nie wyprodukuje nic użytecznego. Dokładnie to spotkało mnie dzisiaj: całkiem porządnie zrobione wywołanie CMS-a zwróciło 330 000 znaków, bo zawierało pełne treści pięćdziesięciu wpisów. Narzędzie nie było złe — po prostu zaprojektowano je bez myśli o tym, kto będzie czytał wynik.
Wszystko z czterdziestoma narzędziami. Duża powierzchnia narzędzi czyni agenta gorszym, nie lepszym. Zużywa uwagę na wybór między niemal identycznymi opcjami. Serwery, które zostały, wystawiają od pięciu do dwudziestu skupionych narzędzi.
Nakładki na rzeczy, które mają dobre CLI. Jeśli narzędzie działa dobrze z powłoki, nakładka MCP dodaje głównie warstwę pośrednią. git, ffmpeg, yt-dlp — pozwalam agentowi uruchamiać je wprost.
Wszystko z interaktywnym logowaniem, które wygasa. Serwer, przez który muszę logować się na nowo w przeglądarce, to serwer, który zepsuje się dokładnie wtedy, gdy coś działa bez nadzoru.
Reguła
Po odpowiedniej liczbie prób sprowadziło się to do jednego zdania: serwer MCP zasługuje na swoje miejsce, gdy udostępnia stan, którego agent inaczej nie widzi, w porcjach dość małych, by dało się je przeczytać.
Liczą się obie połowy.
Stan, którego agent nie widzi, to moje notatki, moje projekty, moje liczby, treści moich klientów. Nie dokumentacja — tę sobie znajdzie. Nie polecenia — ma powłokę.
Dość małe, by przeczytać, znaczy: wynik zaprojektowany dla czytelnika z ograniczonym oknem kontekstu. Domyślnie podsumowania. Szczegóły na żądanie. Identyfikatory zamiast zagnieżdżonych obiektów. To dokładnie ta dyscyplina, którą ma dobrze zaprojektowane API — a większość serwerów MCP pisze się tak, jakby konsument miał nieskończoną cierpliwość.
Co poradziłbym komuś, kto zaczyna
Zacznij od jednego. Wybierz system, z którego najczęściej kopiujesz kontekst — u większości ludzi to notatki albo tracker zadań — i podłącz właśnie ten. Pożyj z nim tydzień, zanim dodasz drugi.
Potem obserwuj typową awarię. Gdy sesja idzie źle, sprawdź, czy agent nie musiał przeczytać czegoś ogromnego, żeby odpowiedzieć na małe pytanie. To problem projektu serwera, nie modelu — i da się go naprawić: dodać parametr, zwracać mniej, stronicować.
I trzymaj łączną liczbę nisko. Mój zestaw ma poniżej dziesięciu serwerów, a najlepiej wychodzą sesje, w których agent ma dokładnie ten dostęp, którego wymaga zadanie, i nic ponadto.
Ciekawa zmiana nie polega na tym, że agenci potrafią pisać kod. Polega na tym, że widzą dziś te same systemy co ja. Jakość tego, co widzą, to wyłącznie decyzja projektowa — i należy do mnie.