MCP и API: в чём разница

Коротко#

API (программный интерфейс) — договор между программами: адреса, методы, форматы данных. Под каждый API программист пишет свой код.

MCP — общий способ, которым ИИ-приложение находит возможности сервиса и вызывает их. Сервер сам отдаёт список инструментов с описаниями и схемами параметров, модель читает этот список и решает, что вызвать. Внутри MCP-сервер чаще всего обращается к тому же API.

Если у сервиса есть API, MCP-сервер к нему — это обёртка, которая переводит возможности API на язык, понятный модели: короткие описания, понятные параметры, ошибки, которые модель может прочитать и исправить.

Сравнение#

Таблица: MCP и обычный API | | Обычный API | MCP | |---|---|---| | Для кого | Программист, который пишет интеграцию | ИИ-приложение и модель внутри него | | Описание возможностей | Документация, OpenAPI: читает человек или генератор кода | Сервер отдаёт список инструментов со схемами в ответ на tools/list | | Интеграция | Своя для каждой пары «приложение — сервис» | Один клиент работает с любым сервером | | Формат | У каждого свой: REST, GraphQL, gRPC | Один: JSON-RPC 2.0 по stdio или Streamable HTTP | | Кто решает, что вызвать | Код, написанный программистом | Модель, с согласия пользователя | | Обнаружение | Документация и каталоги API | Запрос server/discover, реестр MCP, каталог серверов | | Авторизация | Своя у каждого: ключи, OAuth, подписи | Для удалённых серверов — OAuth 2.1 по спецификации | | Состояние | Зависит от API | Протокол без состояния с ревизии 2026-07-28 |

Задача «M × N»#

Без общего протокола три ИИ-приложения и три сервиса требуют девяти интеграций: каждое приложение подключают к каждому сервису отдельно. С MCP хватает шести подключений: у каждого приложения свой клиент, у каждого сервиса свой сервер. Новый сервис сразу доступен всем приложениям, новое приложение — всем сервисам.

Без общего протокола каждое приложение подключают к каждому сервису отдельно. С MCP у приложения один клиент, у сервиса один сервер.

Эту же идею MCP взял у Language Server Protocol, который однажды избавил редакторы кода от отдельной поддержки каждого языка программирования. Подробнее — в разделе «Архитектура».

Как MCP-сервер использует API#

Возьмём интернет-магазин с обычным API заказов. Программист вызывает его так:

Запрос к API магазина

GET /api/v2/orders/10452?fields=status,eta HTTP/1.1
Authorization: Bearer <ключ>

MCP-сервер магазина оборачивает этот вызов в инструмент с описанием для модели:

Инструмент в ответе tools/list (вымышленный сервер)

{
  "name": "get_order_status",
  "description": "Статус заказа и ожидаемая дата доставки по номеру заказа",
  "inputSchema": {
    "type": "object",
    "properties": { "order_id": { "type": "string", "description": "Номер заказа, например 10452" } },
    "required": ["order_id"]
  }
}

Что сервер добавляет к API:

описание для модели: зачем инструмент и когда его вызывать;
отбор: модели открывают только нужные действия, а не все методы API;
сборку: один инструмент может сделать несколько запросов к API и вернуть готовый ответ;
понятные ошибки: «заказ не найден, проверьте номер» вместо кода 404;
ограничения: лимиты строк, только чтение, проверку прав каждого вызова.

Когда хватит API, а когда нужен MCP#

Хватит обычного API:

интеграцию пишет программист, и сценарий заранее известен;
сервис подключают к одной программе, ИИ в ней не участвует.

Нужен MCP-сервер:

сервисом должны пользоваться ИИ-ассистенты и агенты, в том числе чужие: клиентов, партнёров, сотрудников;
одни и те же возможности нужны в нескольких приложениях: Claude, Cursor, VS Code, корпоративном агенте;
модель должна сама выбирать действие по описанию, а не идти по жёсткому сценарию.

Частые вопросы#

Можно ли получить MCP-сервер из OpenAPI автоматически?

Да, генераторы существуют. Но сервер, где каждый метод API стал инструментом, перегружает модель: десятки похожих инструментов с техническими названиями. Лучше проектировать инструменты вокруг задач пользователя: «найти товар», «проверить статус заказа». Как это сделать — в руководстве «Свой MCP-сервер».

Заменит ли MCP REST и другие API?

Нет. MCP работает поверх существующих API и не нужен там, где программы обмениваются данными без участия модели.

Чем MCP отличается от вызова функций (function calling)?

Вызов функций — возможность интерфейса модели: приложение передаёт модели список функций в одном запросе. MCP отвечает на вопрос, откуда приложение берёт эти функции: оно получает их от MCP-серверов и передаёт модели. Без MCP описание функций приходится писать в каждом приложении заново.

Как проверить, что MCP-сервер соответствует спецификации?

Бесплатной проверкой сервера: она читает ответы сервера по ревизии 2026-07-28 и не вызывает его инструменты.