MCP vs API: границы протокола, архитектура и критерии выбора

API — это контракт конкретной системы: какие операции доступны, какие данные передать и какой ответ получить. MCP — стандартный слой подключения AI-приложения к инструментам и контексту. Он описывает, как клиент обнаруживает tools, resources и prompts, согласует возможности и вызывает их через единый протокол.

Поэтому выбор «MCP или API» часто ложный. Production MCP-сервер обычно вызывает существующий REST, GraphQL, gRPC или SDK. API остаётся системным контрактом, а MCP добавляет AI-ориентированное discovery, схемы инструментов, жизненный цикл соединения и переносимость между совместимыми клиентами.

MCP использует клиент-серверную архитектуру и сообщения JSON-RPC. Host AI создаёт клиент для каждого MCP-сервера, запрашивает его возможности и получает список доступных инструментов. Сервер может предоставить tools для действий, resources для контекста и prompts как повторно используемые шаблоны.

Стандартные transports решают разные задачи: stdio подходит для локального процесса, а Streamable HTTP — для удалённого многопользовательского сервера. Transport не заменяет бизнес-авторизацию: после аутентификации пользователя сервер всё равно проверяет, может ли тот читать конкретную сделку или выполнять операцию.

Прямой API лучше для детерминированных интеграций system-to-system, больших потоков данных, транзакций со строгим порядком и сервисов без динамического discovery. Синхронизация заказов между CRM и ERP не должна зависеть от того, выбрала ли модель правильный инструмент.

API также даёт более простую наблюдаемость и меньше слоёв. Если есть один клиент и три фиксированные операции, отдельный MCP-сервер может повысить стоимость поддержки без пользы. MCP окупается, когда одни и те же безопасные инструменты должны использовать несколько AI-приложений.

MCP упорядочивает интеграцию агента с несколькими системами. Вместо отдельного адаптера CRM, репозитория и базы данных в каждом host вы публикуете инструменты со схемами и описаниями. Совместимый клиент обнаруживает их и передаёт модели без специального кода для каждой пары клиент–сервер.

Главная ценность появляется в управлении: единые имена, версии, лимиты, согласия, аудит и наборы инструментов для разных ролей. Это работает только с небольшими однозначными tools. Универсальный execute_sql или call_any_api переносит весь риск в prompt и не должен быть production-интерфейсом по умолчанию.

Самый безопасный шаблон — MCP как тонкий слой над существующими доменными сервисами. Tool get_deal_summary вызывает контролируемый endpoint CRM, а create_follow_up_task принимает ограниченную схему и проверяет роль пользователя. Сервер не обходит доменную логику и не подключается к базе с правами администратора.

Для каждой операции задайте read-only или mutating, необходимость подтверждения, timeout, idempotency key и политику логирования. Отдельно измеряйте ошибки транспорта, выполнения tool и неверного выбора инструмента моделью. Так проблема интеграции отделяется от проблемы AI-оркестрации.