Какую проблему на самом деле решает MCP: от N × M интеграций к N + M

Вопрос за шумихой

Команда, которая выпускает поддержку MCP (сервер с 16 инструментами плюс клиент, подключающийся к другим MCP-серверам), рано или поздно услышит самое острое возражение изнутри: если MCP просто вызывает API и возвращает данные, зачем он вообще нужен? REST API уже есть.

Вопрос справедливый, и большинство объяснений MCP спотыкаются, потому что начинают с протокола, а не с проблемы. Так что начнём с проблемы.

Для какой проблемы существует MCP

Представьте руководителя, который спрашивает ИИ-ассистента: какие заявки на закупку ждут моего согласования? Ответ есть в системе закупок, и перед ней, скорее всего, стоит REST API. Чего же не хватает? Есть четыре типичных пути, и у каждого свой подвох:

1. Скопировать записи в окно чата. Сработает один раз, вручную, и копия тут же начнёт устаревать.
2. Встроить чат-бота прямо в приложение закупок. Уже лучше, но теперь ИИ заперт в этом приложении, а интеграцию вам поддерживать вечно.
3. Вставить документацию API и надеяться, что модель выберет нужный эндпоинт. Это может работать, но легко ломается.
4. Написать отдельную интеграцию для каждого ассистента, которым пользуются в компании.

Последний путь быстро превращается в хаос. Компании с 10 внутренними системами и 5 ассистентами может понадобиться до 10 × 5 = 50 отдельных интеграций, и у каждой свой код авторизации, свои странности и своё сопровождение. MCP создавали именно для того, чтобы убрать это умножение.

От N × M к N + M

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

Without MCP: every pair needs its own integration

System A ──── AI Client 1
System A ──── AI Client 2
System B ──── AI Client 1
System B ──── AI Client 2N × M integrations

С MCP каждая сторона создаётся один раз:

With MCP: build once on each side

System A ──┐             ┌── AI Client 1
System B ──┼──── MCP ────┼── AI Client 2
System C ──┘             └── AI Client 3N + M implementations

Для десяти систем и пяти ассистентов число реализаций падает с 50 до 15. Если одной строкой: MCP позволяет ассистенту узнать, что умеет система, и вызвать это по одному общему соглашению.

Чтобы всё встало на места, нужны три идеи.

1. Внутри MCP-сервера нет никакого ИИ

Это, пожалуй, самое частое заблуждение. Люди представляют себе такую цепочку:

User → AI → MCP Server → API → AI → Answer

где на другой стороне рассуждает вторая модель. Ничего подобного нет. Сервер — обычный код, который никогда не вызывает LLM. На практике всё ближе к такому:

User
 ↓
LLM            decides which tool it needs
 ↓
MCP Client     sends the call
 ↓
MCP Server     executes it
 ↓
Your API / business logic
 ↓
Structured data
 ↓
LLM            interprets the result
 ↓
Answer

Сервер — это руки, а модель — мозг.

2. «У нас уже есть REST API»

Да, и API никогда и не был тем, чего не хватало. Возьмём приложение закупок с таким эндпоинтом:

GET /api/v1/rtps?view=inbox&page=0

Человек прочитает документацию и поймёт. Модели же приходится прямо во время работы разбираться, что означает этот эндпоинт, когда он применим и какие параметры передавать, а связующий код, который бы ей это объяснил, никто не написал.

MCP добавляет обнаружение. Клиент может спросить сервер, что тот умеет, и получить список возможностей:

list_my_approvals
get_purchase_request
search_suppliers
get_purchase_order
create_rfq

У каждой записи есть описание и схема входных данных. Первый инструмент доходит до модели примерно в таком виде:

{
  "name": "list_my_approvals",
  "description": "List purchase requests waiting for the current user's approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page": { "type": "integer", "description": "Zero-based page number" }
    }
  }
}

Поставьте рядом GET /api/v1/rtps?view=inbox&page=0 и list_my_approvals. URL называет маршрут, а имя инструмента описывает возможность словами, о которых модель может рассуждать. Этот разрыв MCP и закрывает.

(Серверы могут предлагать ещё ресурсы и переиспользуемые промпты, но обычно начинают с инструментов, и речь здесь о них.)

3. Самое интересное — композиция

Здесь MCP становится чем-то бо́льшим, чем обёртка вокруг API. Подключите к одному ассистенту три сервера:

• Сервер мониторинга с get_system_health и get_recent_incidents
• Сервер знаний с get_document, search_documents и find_certificate
• Сервер закупок с инструментами get_purchase_order, get_purchase_request и list_my_approvals

Теперь задайте ассистенту составной вопрос: перечисли ожидающие заявки на закупку и отметь те, к которым нет подтверждающих сертификатов. Модель вызывает инструменты закупок, запрашивает у сервера знаний сертификаты по каждой заявке, сводит результаты и отвечает один раз. Ни один сервер не знает о других, и это нормально.

То есть интеграцию выполняет сама модель. Сравните с одним раздутым чат-ботом, жёстко привязанным ко всем бэкендам. Здесь новая система появляется как ещё один сервер, а ассистент остаётся нетронутым.

Модель как слой интеграции

Традиционная интеграция выглядит так:

System A
   ↕
Integration Layer
   ↕
System B

С агентным ИИ картина становится такой:

               AI Model
             /    |    \
            /     |     \
     MCP Server  MCP Server  MCP Server
          |          |          |
      Procurement  Knowledge  Monitoring

Модель сама решает, какая возможность ей нужна, а это принципиально отличается от построения одного слоя интеграции, который понимает все системы.

Параллель с LSP

Разработчики уже встречали такую схему — в Language Server Protocol. Раньше каждый редактор писал собственное автодополнение, переход к определению и подсветку ошибок для каждого языка — тот же клубок N × M. С LSP язык предоставляет эти функции один раз, в виде языкового сервера, и их получает любой редактор, который говорит на этом протоколе. MCP открыто заимствует у LSP.

Вряд ли кто-то спрашивает, зачем Java нужен LSP, если у неё есть компилятор. Компилятор никогда и не был целью. Точно так же ваш API описывает, что умеет система, а MCP — как ИИ-клиент узнаёт об этих возможностях и вызывает их.

Так что сравнение не «REST против MCP». Это REST внизу и MCP поверх него для совместимости с ИИ.

Что MCP не решает

Эту часть шумиха обычно пропускает.

Модель не становится умнее благодаря MCP. Описания инструментов работают как промпты, так что небрежное описание даёт небрежные вызовы.

Безопасность за вас тоже никто не обеспечит. Опубликовать search_suppliers почти не рискованно — он только ищет, а вот публикуя approve_purchase_order, вы отдаёте финансовый контроль. Заложите аутентификацию, авторизацию, минимальные привилегии, журналы аудита и явное подтверждение перед любым изменением состояния.

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

Нужен ли вам MCP вообще?

Наличие API — неправильный критерий. Правильный — выбирает ли модель, какую возможность вызвать, из ИИ-клиента, который вы не контролируете.

Если нет — обойдитесь без MCP: обычные вызовы API или function calling в вашем фреймворке проще. Если да — совместимость становится вашей проблемой, и решать её можно кастомными плагинами, проприетарными протоколами и интеграциями под каждого клиента либо переходом на стандарт. Всё решение сводится к этому.

Что показывает сервер с 16 инструментами

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

В этом и выигрыш. API содержит то, что можно сделать; MCP — то, как ассистент узнаёт о возможном и выполняет это. Если держать это различие в голове, MCP выглядит уже не модным словом, а обычной инфраструктурной «сантехникой».