- Классические REST и gRPC-контракты уже недостаточны для динамики микросервисов и автономных LLM-агентов.

- Model Context Protocol вводит единый формат обмена с самоописанием инструментов, динамическим обнаружением, stateful-сессиями и двусторонними сообщениями.

- Крупнозернистые инструменты MCP сокращают количество сетевых вызовов и упрощают оркестрацию на стороне клиента.

- Разбор того, где MCP улучшает наблюдаемость, безопасность и масштабируемость, а где традиционные API остаются предпочтительнее.

- Опыт продакшен-внедрения MCP: переработка API, сложности и рабочие решения.

---

Более детально:

1. Проблемы

- В микросервисной среде при появлении нового клиента приходится писать адаптер к каждому из N сервисов, а при добавлении очередного сервиса требуется адаптировать его ко всем M клиентам, что приводит к квадратичному росту связей и усложнению версионирования.

- LLM-клиенты формируют запросы автономно, и чем разнообразнее эндпоинты, тем выше вероятность некорректного или «галлюцинированного» вызова.

2. MCP — что меняется

- Протокол вводит единый метод `tools/call` с аргументами в одном JSON-объекте и стандартизированным форматом ответа, что избавляет от множества ручных коннекторов.

- Метод `tools/list` позволяет клиенту динамически получать актуальный набор инструментов без пересборки SDK.

- Handshake при установлении соединения создаёт stateful-сеанс, в котором сервер объявляет ресурсы и шаблоны промптов и хранит их на протяжении диалога.

3. MCP vs классические API

- Один инструмент MCP покрывает целую бизнес-операцию, сокращая число сетевых переходов, необходимых при цепочке CRUD-вызовов в REST или gRPC.

- Контекст и кэш ресурсов живут на сервере сеанса, поэтому клиенту не нужно повторно передавать одни и те же данные.

- Унифицированные логи и коды ошибок облегчают трассировку: на каждый инструмент формируется один span вместо нескольких для связки мелких эндпоинтов.

- Политики доступа привязываются к инструменту, а не к URL, что проще согласовать с логикой работы LLM-агента и позволяет реализовать подтверждение опасных действий через diff.

4. Инфраструктурный слой

- AI Gateway принимает MCP-трафик, применяет лимиты частоты, валидирует аргументы, ведёт аудит вызовов и передаёт легитимные запросы в MCP-серверы.

- Safeguards включают квоты на количество вызовов, троттлинг повторяющихся ошибок, sandbox-проверки на prompt-инъекции и контроль размера контекста.

5. Системный дизайн с MCP

- Архитектура получает новый компонент: AI-агент с MCP-клиентом устанавливает 1:1 соединения с несколькими MCP-серверами, каждый из которых предоставляет доступ к конкретному ресурсу или сервису.

- Открывать через MCP следует лишь критически важные функции (поиск знаний, ограниченные транзакции), оставив остальные операции на REST/gRPC.

- Двухслойный подход позволяет внешним и ручным интеграциям продолжать использовать классические API, а внутренним AI-ассистентам — стандартизированный MCP-интерфейс.

- Часть оркестрации передаётся в логику LLM, но высокоуровневые правила и ограничения остаются в коде MCP-серверов; разработчику необходимо настроить tracing инструментальных вызовов, лимит времени сессии и fallback-механику на случай ошибок агента.

6. Архитектурные рекомендации

- Низкоуровневые CRUD-методы следует группировать в крупные инструменты, чтобы агенту было проще решать бизнес-задачи без длинных цепочек вызовов.

- Политики доступа нужно формулировать на уровне инструмента и роли пользователя, чтобы ограничить LLM в выполнении опасных операций.

- MCP-трейсы стоит интегрировать в существующий observability-стек, настроив алерты на аномальные паттерны вызовов и превышение квот.