Podłączyłeś swojego agenta AI do piętnastu serwerów MCP — Slack, GitHub, Jira, baza danych — i testowałeś, aż wszystko śmigało jak w zegarku. MCP (Model Context Protocol) to uniwersalny standard podłączania narzędzi do agentów AI, coś jak USB, tylko do danych. Demo wyglądało świetnie. Szef kiwał głową. Wrzuciłeś na produkcję.

I tu zaczyna się część, o której nikt cię nie uprzedził: serwery MCP to nie statyczne paczki leżące sobie na dysku. To żywe procesy i zdalne endpointy. A na dzień 25 kwietnia 2026 roku żadna platforma agentowa nie poinformuje cię, kiedy któryś z nich padnie, zacznie chodzić jak muł albo zacznie zwracać śmieci.

Połowa twoich narzędzi może już nie żyć

20 kwietnia RapidClaw przebadał 1847 publicznych serwerów MCP w siedmiu rejestrach. Wynik: 52% jest martwych lub porzuconych. Tylko 17% — 315 serwerów — nadawało się na produkcję. Medianowy serwer MCP ma sześć commitów w całej historii, jednego maintainera, zero testów i nie był aktualizowany od 142 dni.

To jest ekosystem, od którego zależy twój agent. Rzut monetą decyduje, czy narzędzie, które właśnie wywołuje, jeszcze w ogóle działa.

A sam protokół MCP w niczym tu nie pomaga. Nie ma wbudowanego endpointu health check — żadnego ustandaryzowanego sposobu, żeby serwer powiedział 'żyję i działam". SDK-i implementują podstawowy ping, ale nie ma /health, nie ma /ready, nie ma liveness probe. Każdy zespół klepie własne rozwiązanie albo — co częstsze — nie klepie niczego.

Dziura w kształcie protokołu

Problem nie leży tylko w platformach — siedzi w samej specyfikacji. HTTP ma kody statusów. gRPC ma health checking services. Kubernetes ma liveness i readiness probes. MCP ma... metodę ping, która potwierdza, że warstwa transportowa żyje, a nie że serwer faktycznie potrafi zrobić swoją robotę.

Serwer MCP do bazy danych może odpowiedzieć na ping, mając wyczerpany connection pool. Serwer MCP do GitHuba może odesłać pong, podczas gdy jego token autoryzacyjny wygasł trzy tygodnie temu. Protokół nie rozróżnia 'transport działa" od 'narzędzie działa". A to rozróżnienie ma znaczenie, kiedy twój agent przepala tokeny, ponawiając zapytania do narzędzia, które technicznie odpowiada, ale funkcjonalnie kłamie.

Agent Observability od Google'a, wypuszczony 22 kwietnia jako część Gemini Enterprise Agent Platform, śledzi liczbę requestów i p95 latency dla serwerów MCP. Dwie metryki. Już pisaliśmy o szerszych lukach tej platformy — w skrócie: Google zbudował tracing na poziomie agenta, nie monitoring na poziomie narzędzi. AWS zaprezentował podobne katalogowe podejście z Agent Registry 17 kwietnia — książka telefoniczna dla agentów, nie monitor zdrowia. Obie firmy przyznają, że narzędzia wymagają traktowania jak infrastruktura. Żadna z nich tak naprawdę nie sprawdza, czy twoje narzędzia żyją.

Dla porównania: byle średnio przyzwoity mikroserwis — mały, niezależny kawałek backendu — dostaje health checki, statystyki błędów, analizę jakości odpowiedzi i automatyczne alerty. Twój serwer MCP dostaje licznik requestów i stoper.

Co się psuje, kiedy narzędzie się psuje

Kiedy serwer MCP cicho degraduje, twój agent nie ma o tym pojęcia. Albo halucynuje odpowiedź (wymyśla coś z głowy), albo po cichu ponawia próby, przepalając tokeny — porcje tekstu, które AI przetwarza, a każda kosztuje pieniądze — albo pada bez informacji, które narzędzie nawaliło. Trace'y z observability agenta pokazują, co agent zdecydował. Nie pokazują, czy narzędzie było zdrowe, kiedy odpowiadało. Widzisz objaw. Nie jesteś w stanie postawić diagnozy.

To jak monitorowanie aplikacji webowej bez monitorowania jej bazy danych. Dashboard świeci na zielono, dopóki wszystko nie stoi w płomieniach.

Co zrobić tu i teraz

Jeśli odpalasz agentów na produkcji, traktuj każdy serwer MCP jak zależność mikroserwisową:

  • Ustaw timeouty. Protokół MCP tego za ciebie nie zrobi.
  • Zdefiniuj fallbacki. Jeśli narzędzie leży, twój agent potrzebuje planu B, a nie improwizowanej halucynacji.
  • Monitoruj jakość odpowiedzi. 200 OK, które zwraca bzdury, jest gorsze niż czysty błąd.
  • Opakuj połączenia w circuit breakery — wzorzec, który odcina padający serwis, zanim pociągnie za sobą resztę.
  • Zaakceptuj sufit. Twój agent jest dokładnie tak niezawodny jak jego najsłabsze narzędzie.

Większość zespołów nie zabudżetowała tej hydrauliki. Większość zespołów zaraz się dowie, dlaczego powinna była.

Brakująca warstwa

Stos agentowy w kwietniu 2026 ma mądrzejsze modele, większe rejestry i ładniejsze bramy. Czego nie ma, to tool SRE — Site Reliability Engineering stosowane do narzędzi, od których agenty zależą. Wcześniejsze artykuły na tym kanale argumentowały, że inżynieria niezawodności agentów jeszcze nie istnieje. Audyt RapidClaw dowodzi, że problem sięga jeszcze głębiej: nie da się mieć niezawodnych agentów, kiedy protokół, którym mówią, nie definiuje nawet, co znaczy 'zdrowy" w kontekście narzędzia.

Pierwsza platforma, która dostarczy monitoring zdrowia na poziomie narzędzi z endpointami /health i /ready wbudowanymi w specyfikację MCP — nie doklejanymi przez każdego vendora z osobna — przejmie warstwę niezawodności, której brakuje całemu ekosystemowi.

Zacząłeś z piętnastu serwerami MCP, które świetnie chodziły na devie. Na produkcji mniej więcej osiem z nich jest o rzut monetą od śmierci. Nikt tego nie pilnuje. Może zacznij od tego.