# MCP и API

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

Ревизия MCP 2026-07-28 · проверено 13.10.2026 · https://mcpprotocol.ru/mcp-i-api/

## Коротко

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

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

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

## Сравнение

**MCP и обычный API**
| | Обычный API | MCP |
|---|---|---|
| Для кого | Программист, который пишет интеграцию | ИИ-приложение и модель внутри него |
| Описание возможностей | Документация, OpenAPI: читает человек или генератор кода | Сервер отдаёт список [инструментов](https://mcpprotocol.ru/glossary/#tool) со схемами в ответ на `tools/list` |
| Интеграция | Своя для каждой пары «приложение — сервис» | Один клиент работает с любым сервером |
| Формат | У каждого свой: REST, GraphQL, gRPC | Один: [JSON-RPC 2.0](https://mcpprotocol.ru/glossary/#json-rpc) по stdio или Streamable HTTP |
| Кто решает, что вызвать | Код, написанный программистом | Модель, с согласия пользователя |
| Обнаружение | Документация и каталоги API | Запрос `server/discover`, [реестр MCP](https://mcpprotocol.ru/registry/), [каталог серверов](https://mcpprotocol.ru/katalog/) |
| Авторизация | Своя у каждого: ключи, OAuth, подписи | Для удалённых серверов — [OAuth 2.1](https://mcpprotocol.ru/authorization/) по спецификации |
| Состояние | Зависит от API | Протокол без состояния с ревизии 2026-07-28 |

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

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

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

Эту же идею MCP взял у Language Server Protocol, который однажды избавил редакторы кода от отдельной поддержки каждого языка программирования. Подробнее — в разделе [«Архитектура»](https://mcpprotocol.ru/architecture/).

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

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

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

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

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

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

```json
{
  "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-сервер»](https://mcpdocs.ru/svoy-server/).

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

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

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

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

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

Бесплатной [проверкой сервера](https://mcpprotocol.ru/mcp-check/): она читает ответы сервера по ревизии 2026-07-28 и не вызывает его инструменты.