Когда AI-агенту нужно не только генерировать текст, но и читать данные, вызывать внутренние API, работать с файлами или запускать бизнес-действия, полезно отделить модель от интеграционного слоя. MCP server может выступать таким контрактом: он публикует доступные инструменты и ресурсы в структурированном виде, а agent runtime решает, когда и с какими аргументами их вызывать.
Когда MCP действительно полезен
Нужно подключить один набор tools к нескольким агентам или моделям.
Интеграции должны иметь стабильные схемы и единые правила авторизации.
Внешние данные и действия хочется изолировать от prompt/model layer.
Нужна независимая версия и аудит интеграционного контракта.
Agent runtime должен уметь перечислять доступные capabilities динамически.
Базовая архитектура
Разделяйте agent runtime, MCP client, MCP server и целевые backend-системы. Агент принимает решение высокого уровня, client переводит его в вызов протокола, server валидирует вход, проверяет права и только затем обращается к базе, SaaS API или внутреннему сервису. Такой контур уменьшает связанность и упрощает замену модели без переписывания каждой интеграции.
Tools, resources и prompts
Tools используйте для действий и вычислений с явной JSON-схемой аргументов.
Resources подходят для чтения контекста и данных без маскировки их под side-effecting action.
Prompts и шаблоны не должны подменять backend authorization.
Название capability должно описывать бизнес-операцию, а не внутреннюю реализацию.
Схемы делайте узкими: модель должна выбирать из разрешённых полей, а не передавать произвольный payload.
Transport и жизненный цикл соединения
Для локальных инструментов удобен процессный transport, для удалённого сервера — сетевой. Независимо от транспорта, обрабатывайте reconnect, timeout, cancellation и version mismatch явно. Не считайте долгоживущее соединение гарантированным: agent runtime должен корректно восстановить список capabilities и повторить только безопасные операции.
Авторизация и права
Не передавайте MCP server постоянный суперпользовательский токен, если достаточно user-scoped credentials.
Проверяйте tenant, role, scope и конкретный ресурс на стороне сервера при каждом чувствительном вызове.
Разделяйте read-only и write tools.
Для опасных действий добавляйте policy gate или human approval до выполнения.
Не доверяйте аргументам, сформированным моделью: они проходят ту же валидацию, что и внешний API-запрос.
Идемпотентность и retries
Сетевой повтор не должен автоматически повторять бизнес-действие. Для оплаты, создания заказа, отправки сообщения и других side effects используйте idempotency key и сохраняйте terminal result. Read-only tools можно повторять свободнее, но write operations должны отличать transport retry от нового пользовательского намерения.
Ошибки и контракты
Возвращайте типизированные ошибки: validation, auth, not_found, conflict, rate_limit, dependency_failure.
Не отправляйте модели stack trace, секреты и внутренние SQL/API детали.
Версионируйте несовместимые изменения схемы.
Добавляйте machine-readable code и короткое безопасное описание ошибки.
Ограничивайте размер response payload и используйте pagination для больших наборов данных.
Observability
Связывайте agent run, MCP request и downstream call одним correlation/trace ID.
Измеряйте latency и error rate по каждому tool.
Отдельно считайте authorization denials, validation failures и dependency timeouts.
Логируйте имя capability и технические метаданные, но не секреты и чувствительный пользовательский контент.
Для дорогих tools полезно измерять стоимость и частоту вызовов на run/user/tenant.
Безопасность против prompt injection
MCP сам по себе не устраняет prompt injection. Текст из документа, сайта или внешнего API нельзя трактовать как новое право на выполнение действий. Policy и permissions должны задаваться вне модели: server обязан проверять, может ли текущий пользователь выполнить конкретную операцию, даже если модель уверенно попросила её вызвать.
MCP или обычный REST/gRPC client
Если интеграция используется одним backend-сервисом и набор операций фиксирован, обычный REST/gRPC client может быть проще. MCP полезнее, когда capabilities должны быть обнаруживаемыми, переиспользуемыми разными agent runtimes и описанными в едином tool/resource контракте. Не добавляйте протокольный слой только ради моды — он должен уменьшать интеграционную связанность.
Короткий production checklist
Каждый tool имеет узкую схему и понятный side-effect profile.
AuthN/authZ проверяются на MCP server, а не только в agent UI.
Write operations идемпотентны и безопасны при retry.
Timeout, cancellation и dependency errors обработаны явно.
Секреты не попадают в model context и логи.
MCP calls покрыты traces, metrics и audit events.