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

Короткий ответ

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

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

Как устроен MCP

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

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

Где обычный API лучше

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

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

Где MCP даёт преимущество

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

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

Шаблон корпоративного внедрения

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

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

MCP или прямой API — что выбрать

Пример MCP tool поверх CRM API

{
  "name": "create_follow_up_task",
  "description": "Создаёт задачу дожима по сделке CRM",
  "inputSchema": {
    "type": "object",
    "required": ["dealId", "dueDate"],
    "properties": {
      "dealId": { "type": "string" },
      "dueDate": { "type": "string", "format": "date" },
      "note": { "type": "string", "maxLength": 500 }
    }
  },
  "annotations": { "mutating": true, "requiresApproval": false, "idempotencyKey": "dealId+dueDate" }
}

FAQ