Есть REST API. Он работает. Затем кто-то предлагает поставить рядом MCP server, потому что «теперь так подключают агентов». Я бы сначала спросил: какую проблему он решит, которой у нас ещё нет?

MCP полезен не как более современная замена HTTP. Это протокол взаимодействия AI-приложения с серверами, которые экспонируют tools, resources и другие возможности через общий контракт. Если агент должен динамически работать с набором инструментов от разных систем, стандартный слой действительно может убрать много разового glue code. MCP AI имеет смысл обсуждать именно на этой границе: что стандарт даёт поверх уже работающего API и за какую дополнительную сложность.

Если у нас один стабильный endpoint `POST /create-task`, новый протокол легко становится ещё одной вещью, которую нужно обновлять, защищать и мониторить. Тоже архитектура. Просто без пользы.

Direct API остаётся хорошим вариантом

Обычный API даёт максимально явный контракт. Клиент знает endpoint, схему запроса, auth и ожидаемый ответ. Для небольшого набора действий это предсказуемо и легко тестируется.

AI-часть можно вообще не подпускать к HTTP напрямую. Модель выбирает внутренний tool, а приложение валидирует параметры и вызывает API. Это уже нормальная agent architecture без MCP.

Если набор tools редко меняется и контролируется одной командой, я бы начинал отсюда. Меньше moving parts. Обычно это хороший знак.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28

MCP стандартизирует discovery и описание capabilities

Главное отличие появляется, когда клиенту нужно подключать несколько независимых серверов и узнавать их возможности через стандартный протокол. MCP определяет lifecycle и примитивы взаимодействия между host, client и server.

Вместо отдельного адаптера под каждый сервис приложение может работать с общим способом перечисления tools и их схем. Для экосистемы, где инструменты добавляются и меняются, это реальная экономия интеграционного кода.

Актуальная спецификация на момент этого материала — версия 2026-07-28. Это важно фиксировать: протокол развивается, поэтому production-интеграция должна знать, с какой версией и набором capabilities она совместима.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28 · Model Context Protocol — The 2026-07-28 Specification

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже
MCP AI: когда агенту нужен Model Context Protocol, а когда достаточно API · временная заглушка

Tool schema не отменяет бизнес-контракт

MCP может описать tool `create_refund` и его параметры. Он не решает за нас, когда возврат вообще разрешён. Это остаётся доменной policy.

Я бы держал ограничения суммы, роли, состояния заказа и идемпотентность за интерфейсом инструмента. Модель видит только допустимую команду. Сервер всё равно проверяет права и инварианты перед side effect.

Иначе мы просто стандартизировали способ вызвать опасную функцию. Удобнее. Безопаснее — не обязательно.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28 · OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

Auth и blast radius нужно проектировать отдельно

Если один MCP server экспонирует десятки tools под слишком широким credential, blast radius растёт. Prompt injection или ошибка планирования получают больше вариантов, чем требовалось задаче.

Я бы делил servers или credentials по доменам полномочий, выдавал минимальные scopes и проверял вызывающего на серверной стороне. Tool, который только читает статус заказа, не должен случайно наследовать право отмены.

OWASP для agentic systems отдельно поднимает проблемы excessive agency и небезопасного использования инструментов. MCP здесь не источник проблемы и не автоматическое решение. Это транспортный контракт, вокруг которого всё равно нужна security policy.

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

Наблюдаемость важнее красивого списка tools

В production мне нужно восстановить цепочку: какой user request породил tool call, какой server его принял, какая версия схемы использовалась, сколько занял вызов и какой side effect произошёл.

MCP-вызовы стоит включать в общий trace приложения. OpenTelemetry semantic conventions дают базовый язык для traces и attributes; конкретные поля MCP можно добавлять осторожно, не складывая secrets и полный payload без необходимости.

Если после инцидента видно только «agent called tool», диагностика ещё не закончена. Нужен конечный state внешней системы.

Проверяемые источники: OpenTelemetry — OpenTelemetry Semantic Conventions

Когда я бы выбрал MCP, а когда оставил API

MCP выглядит разумно, когда приложение подключает много независимых инструментов, capabilities меняются, нужны стандартные discovery и lifecycle, а команда готова поддерживать protocol layer. Особенно если один host должен работать с серверами разных владельцев.

Direct API или собственный tool wrapper проще, когда действий мало, домен закрытый и контракт стабилен. Никакой проблемы в этом нет. Архитектура не получает баллы за количество протоколов.

Можно начать с wrapper, а MCP добавить позже на границе экосистемы. Я бы не делал обратное только ради модного слова.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28 · Model Context Protocol — The 2026-07-28 Specification

Версию протокола фиксируйте так же, как версию API

MCP развивается быстро. Это значит, что client и server не должны молча предполагать одинаковый набор возможностей. Я бы фиксировал protocol version и проверял negotiated capabilities при соединении.

Если новая версия добавляет механизм, это не повод включать его автоматически. Production server проходит обычный compatibility test: старый client, новый client, reconnect, ошибка capability и ограниченный tool set.

Стандарт уменьшает число уникальных интеграций. Он не отменяет versioning. Было бы слишком удобно.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28 · Model Context Protocol — The 2026-07-28 Specification

Короткие вопросы перед production

MCP заменяет REST API?

Нет. MCP задаёт стандарт взаимодействия AI-приложения с MCP servers и их capabilities. Сам сервер вполне может внутри вызывать REST API, базу или другой backend.

Нужен ли MCP для одного AI-агента?

Не обязательно. Если набор tools небольшой и стабилен, обычные typed wrappers часто проще. MCP становится интереснее при растущей экосистеме серверов и динамическом discovery.

MCP делает вызовы инструментов безопасными?

Сам по себе нет. Нужны минимальные права, серверная валидация, domain policy, audit и ограничения side effects. Протокол стандартизирует взаимодействие, а не бизнес-разрешение.

Мой критерий простой: если MCP убирает несколько разных интеграционных контрактов и даёт один понятный lifecycle — хорошо. Если он оборачивает один стабильный API и больше ничего не меняет, я оставлю API. Скучно. Зато поддерживать меньше.

Смежные контуры, которые стоит прогнать отдельно для «MCP AI»: Как безопасно дать AI доступ к CRM и внутренним системам · n8n или собственный backend: что выбрать для AI-автоматизации · Как перенести AI-автоматизацию с прототипа в рабочую систему.