Ви підключили свого AI-агента до п'ятнадцяти MCP-серверів — Slack, GitHub, Jira, база даних — і тестували, поки все не заспівало в унісон. MCP (Model Context Protocol) — це універсальний стандарт підключення, який дозволяє AI-агентам спілкуватися із зовнішніми інструментами. Щось на кшталт USB, тільки для даних. Демо виглядало чудово. Бос кивав головою. Ви викатили в продакшн.

А тепер та частина, про яку вас ніхто не попередив: MCP-сервери — це не статичні пакети, що тихенько лежать на диску. Це живі процеси й віддалені ендпоінти. І станом на 25 квітня 2026 року жодна платформа для агентів не скаже вам, коли один із них ляже, почне гальмувати або повертати сміття.

Половина ваших інструментів, можливо, вже мертві

20 квітня RapidClaw проаудитував 1 847 публічних MCP-серверів у семи реєстрах. Результат: 52% мертві або покинуті. Лише 17% — 315 серверів — відповідали вимогам до продакшну. Медіанний MCP-сервер має шість комітів за весь час існування, одного мейнтейнера, нуль тестів і не оновлювався 142 дні.

Ось така екосистема, від якої залежить ваш агент. Підкидання монетки визначає, чи працює інструмент, який він викликає.

І сам протокол MCP нічим не допоможе. Немає вбудованого ендпоінта для перевірки стану — жодного стандартизованого способу для сервера сказати «я живий і працюю». SDK реалізують базовий ping, але немає ні /health, ні /ready, ні liveness probe. Кожна команда пише своє рішення. Або — що частіше — не пише нічого.

Діра розміром з протокол

Проблема не тільки в платформах — вона в самій специфікації. HTTP має статус-коди. gRPC має health checking services. Kubernetes має liveness і readiness probes. MCP має... метод ping, який підтверджує, що транспортний рівень живий, а не те, що сервер реально може виконувати свою роботу.

MCP-сервер бази даних може відповідати на ping, поки його пул з'єднань вичерпано. MCP-сервер GitHub може повертати pong, поки його auth-токен протух три тижні тому. Протокол не розрізняє «транспорт працює» і «інструмент працює». А ця різниця критична, коли ваш агент спалює токени — ті шматочки тексту, які AI обробляє за гроші — повторюючи запити до інструменту, який технічно відповідає, але функціонально бреше.

Agent Observability від Google, випущений 22 квітня як частина Gemini Enterprise Agent Platform, відстежує кількість запитів і p95 latency для MCP-серверів. Дві метрики. Ми вже розбирали ширші проблеми платформи — коротко: Google побудував трейсинг на рівні агента, а не моніторинг на рівні інструмента. AWS показав схожий підхід з каталогом — Agent Registry 17 квітня — телефонний довідник для агентів, а не монітор здоров'я. Обидві компанії визнають, що інструменти потребують інфраструктурного підходу. Жодна реально не перевіряє, чи ваші інструменти живі.

Для порівняння: будь-який більш-менш пристойний мікросервіс — невелика незалежна частина вашого бекенду — отримує health checks, відсоток помилок, аналіз якості відповідей і автоматичні алерти. Ваш MCP-сервер отримує лічильник запитів і секундомір.

Що ламається, коли ламається інструмент

Коли MCP-сервер тихо деградує, ваш агент про це не знає. Він або галюцинує відповідь (вигадує щось із повітря), або мовчки ретраїть, спалюючи токени, або падає, не повідомляючи, який саме інструмент зламався. Трейси agent observability показують, що агент вирішив. Вони не показують, чи був інструмент здоровий, коли відповідав. Ви бачите симптом. Діагноз поставити не можете.

Це як моніторити веб-застосунок, але не моніторити його базу даних. Дашборд зелений, поки все не горить синім полум'ям.

Що робити прямо зараз

Якщо ви запускаєте агентів у продакшні, ставтеся до кожного MCP-сервера як до залежності-мікросервісу:

  • Встановіть таймаути. Протокол MCP не зробить це за вас.
  • Визначте фолбеки. Якщо інструмент лежить, вашому агенту потрібен план Б, а не імпровізована галюцинація.
  • Моніторте якість відповідей. 200 OK, що повертає нісенітницю, гірше за чисту помилку.
  • Загорніть з'єднання в circuit breakers — патерн, який відсікає сервіс, що падає, перш ніж він потягне за собою все інше.
  • Прийміть стелю. Ваш агент рівно настільки надійний, наскільки надійний його найслабший інструмент.

Більшість команд не заклали бюджет на цю сантехніку. Більшість команд скоро дізнаються, навіщо треба було.

Відсутній шар

Стек агентів у квітні 2026 має розумніші моделі, більші реєстри та модніші шлюзи. Чого він не має — це tool SRE, тобто Site Reliability Engineering, застосований до інструментів, від яких залежать агенти. Попередні статті на цьому каналі стверджували, що інженерія надійності агентів ще не існує. Аудит RapidClaw доводить, що проблема на рівень глибше: не може бути надійних агентів, коли протокол, яким вони спілкуються, навіть не визначає, що означає «здоровий» для інструменту.

Перша платформа, яка випустить моніторинг здоров'я інструментів з ендпоінтами /health і /ready, вшитими в специфікацію MCP — а не прикрученими збоку кожним вендором — захопить рівень надійності, якого бракує всій екосистемі.

Ви починали з п'ятнадцяти MCP-серверів, які ідеально працювали в деві. У продакшні приблизно вісім із них — підкидання монетки до смерті. Ніхто не стежить. Може, варто почати з цього.