«Зачем мне MCP, если у сервиса уже есть API?» — этот вопрос мы чаще всего слышим от разработчиков, которые впервые заглядывают в наш каталог. Вопрос справедливый, и ответ на него короткий: MCP не нужен вместо API. Он нужен поверх API — для одного конкретного типа вызывающей стороны.
Эта сторона — AI-модель. Как только вы увидите, что нужно модели и не нужно обычной программе, разница между MCP и API перестанет быть размытой. В этом руководстве мы разберём её на конкретном примере, с таблицей сравнения и случаями, когда от MCP стоит отказаться совсем.
Основные выводы
- MCP не заменяет API. Большинство MCP server — это тонкий слой поверх уже существующего API.
- Разница в том, кто вызывает: API обслуживает код, написанный разработчиком, а MCP — модель, которая находит инструменты во время работы.
- Function calling — это половина, обращённая к модели; MCP стандартизирует то, как инструменты описываются, находятся и становятся доступны в разных приложениях.
- Используйте API напрямую, когда решение принимает не модель; function calling — для одной функции в одном приложении; MCP — когда инструмент нужен многим приложениям или агентам.
Ответ в одном абзаце
API — будь то REST, GraphQL или gRPC — это способ, которым одна программа просит другую что-то сделать. Он предполагает, что вызывающая сторона уже знает, к какому эндпоинту обращаться, что отправлять и как проходить аутентификацию, потому что этот код написал разработчик. MCP — это протокол, который позволяет AI-приложениям обнаруживать инструменты во время выполнения и вызывать их от имени модели. MCP server публикует список инструментов с описаниями на простом языке и схемами входных данных, модель выбирает один из них, а сервер выполняет фактические вызовы API. Большинство MCP server, которые вы найдёте на HostedMCP, устроены именно так: тонкий слой поверх API, который уже существовал.
Конкретный пример: возвраты в Stripe
Допустим, вы хотите, чтобы AI-ассистент выполнял задачу «верни последний платёж этого клиента».
Если использовать только API, кому-то придётся написать эту интеграцию для ассистента. Нужно определить схему функции, которую понимает модель, с именами и описаниями. Нужно обрабатывать API-ключ. Нужно найти клиента, получить список платежей, выбрать последний, создать возврат и превратить коды ошибок Stripe в то, с чем модель сможет работать. А потом всё это поставляется внутри одного приложения. Когда команде поддержки нужно то же самое в Claude, а разработчикам — в Cursor, эта работа повторяется заново, в другом формате и в другой кодовой базе.
С MCP этот связующий код переезжает в один сервер. Он объявляет инструменты вроде list_charges и create_refund с описаниями, написанными для модели. Он хранит ключ или OAuth-токен. Любой MCP-клиент — Claude, Cursor, ChatGPT, VS Code — может подключиться к нему и получить то же поведение. API Stripe при этом ничуть не изменился. Изменилось то, кому приходится писать части, специфичные для AI, и сколько раз.
Сравнение
| Традиционный API | MCP | |
|---|---|---|
| Кто вызывает | Код, написанный разработчиком | AI-модель через хост-приложение |
| Как вызывающая сторона узнаёт, что доступно | Читает документацию на этапе сборки | Спрашивает у сервера во время выполнения (tools/list) |
| Для кого пишутся описания | Для разработчиков | Для моделей: что делает инструмент и когда его использовать |
| Формат сообщений | Разный: REST, GraphQL, gRPC | JSON-RPC 2.0 для любого сервера |
| Аутентификация | API-ключи, OAuth, что выбрал сервис | Переменные окружения для локальных серверов, OAuth 2.1 для удалённых |
| Объём действий | Всё, что предоставляет API | Только те инструменты, которые сервер решил предложить |
| Одна интеграция работает в | Одном приложении | Любом MCP-клиенте |
| Типичная задержка | Один сетевой переход | Один дополнительный переход через сервер |
Две строки заслуживают большего внимания, чем им обычно достаётся.
Обнаружение — вот в чём настоящее отличие. Программа, вызывающая API, никогда не спрашивает во время выполнения «что ты умеешь?» — разработчик уже это знал. А модели нужно спрашивать каждую сессию, и ответ ей нужен в словах, о которых она может рассуждать. Поэтому описание инструмента MCP читается как совет («Используйте это, чтобы найти открытые pull request, затрагивающие указанный путь»), а не как справочная документация.
Объём — это функция безопасности. API-ключ для сервиса обычно даёт доступ ко всему, что этому ключу разрешено. MCP server сам решает, какие действия вообще существуют. Аналитический сервер только для чтения может просто не включать инструмент delete. Такой же гарантии нельзя добиться, сказав модели «пожалуйста, ничего не удаляй».
MCP и function calling
Function calling, или tool use, как его называют некоторые вендоры, — это возможность API модели: вы перечисляете функции в запросе, и модель может ответить «вызови эту функцию с такими аргументами». Его часто путают с MCP, потому что MCP в итоге его использует.
Вот как они сочетаются. Ваше хост-приложение, скажем Claude Code, подключается к MCP server и собирает их инструменты. Отправляя запрос модели, оно передаёт эти инструменты как определения функций. Когда модель просит вызвать один из них, хост направляет вызов нужному MCP server и возвращает результат обратно. То есть function calling — это половина, обращённая к модели, а MCP — стандарт для всего по другую сторону: как инструменты описываются, обнаруживаются, авторизуются и вызываются, у разных вендоров.
Если вы делаете одну функцию в одном приложении с одной моделью, обычный function calling требует меньше работы и вполне подходит. MCP оправдывает себя, когда один и тот же инструмент должен работать во многих приложениях или когда вы хотите, чтобы пользователи приходили со своим AI-клиентом.
| Function calling | MCP | |
|---|---|---|
| Что это | Возможность одного API модели | Протокол между AI-приложениями и серверами инструментов |
| Где определяются инструменты | В запросе вашего приложения к модели | В отдельном сервере, к которому может подключиться любой клиент |
| Работает в | Приложении, которое вы написали | Любом MCP-клиенте |
| Обнаружение | Вы передаёте список при каждом запросе | Клиент спрашивает сервер во время выполнения |
| Лучше всего для | Одной функции, одного приложения, одной модели | Инструментов, общих для приложений, агентов и вендоров |
Когда API — правильный выбор
Пропускайте MCP, если модель не участвует. Веб-фронтенд, мобильное приложение, ночная синхронизация или интеграция с партнёром должны обращаться к вашему API напрямую. Слой MCP здесь ничего не даёт и добавляет лишний хоп.
Пропускайте его, когда нужен точный контроль над каждым вызовом. Списания платежей, массовые удаления — всё, где вы хотите видеть написанный человеком код с тестами и аудитом, — должно жить в обычном коде, который вызывает API, даже если этот код вам помогал писать ИИ.
И пропускайте его, когда модели нужны только данные, которые у вас уже под рукой. Если ваше приложение получает запись клиента и вставляет её в промпт, это не инструмент, а контекст, и сервер для него не нужен.
| Ситуация | Что использовать |
|---|---|
| Веб- или мобильный фронтенд вызывает ваш бэкенд | API |
| Ночная синхронизация или интеграция с партнёром | API |
| Платежи, массовые удаления или что-либо требующее аудита | API, из протестированного кода |
| У приложения уже есть данные, и оно вставляет их в промпт | Ни то, ни другое; это контекст, а не инструмент |
| Одна AI-функция внутри одного приложения, которое вы контролируете | Function calling |
| Модель должна решать, что искать или делать | MCP |
| Ваши клиенты используют Claude, Cursor и ChatGPT | MCP, в идеале hosted-сервер |
| Нескольким внутренним агентам нужна одна и та же система | Один общий MCP server |
Когда MCP — правильный выбор
Берите MCP, когда решение о том, что делать, должен принимать модель. Агентам, которые ищут информацию, заводят тикеты, запрашивают базы данных или проверяют деплой, нужны инструменты, и MCP — стандартный способ их дать.
Это также верный выбор, когда вы хотите, чтобы ваш продукт работал в чужих AI-инструментах. Если ваши клиенты используют Claude, Cursor и ChatGPT, один MCP server охватывает их все. Именно поэтому компании вроде GitHub, Linear, Notion и Stripe публикуют собственные серверы. На HostedMCP можно просматривать официальные серверы по продуктам и видеть, какие из них хостятся, а какие запускаются локально.
И это помогает, когда вы запускаете несколько агентов внутри компании. Один MCP server на систему, общий для всех агентов, гораздо проще защищать и обновлять, чем код инструментов, скопированный в каждого агента.
Безопасность тоже устроена иначе
У API и MCP server разные угрозы — в основном потому, что в цепочке участвует модель.
В случае с API вызывающая сторона — это ваш код, и он делает то, что вы написали. В случае с MCP вызывающая сторона — это модель, которая читает недоверенный текст: веб-страницы, письма, комментарии в issue. Аккуратно составленный комментарий в issue может попытаться убедить модель вызвать инструмент, который ей вызывать не следует. Это prompt injection, и именно поэтому хорошие хосты спрашивают подтверждение перед запуском инструментов, изменяющих данные, а серверы должны предоставлять минимальный полезный набор инструментов.
Спецификация MCP также занимает жёсткую позицию по токенам. Согласно её security best practices, сервер не должен принимать токены, которые были выданы не ему, и не должен передавать пользовательский токен другому сервису. У этого антипаттерна есть название — token passthrough, и это одно из первых, что стоит проверить в коде сервера, прежде чем ему доверять. Для удалённых серверов авторизация следует OAuth 2.1, а в редакции 2026-07-28 регистрация клиента переходит на Client ID Metadata Documents. Подробнее — в нашем руководстве по безопасности MCP.
Внимание
Считайте любой аргумент, который получает инструмент MCP, недоверенным вводом. Модель, выбравшая его, могла прочитать веб-страницу или комментарий в issue, написанный, чтобы ею управлять.
Производительность и стоимость
Иногда говорят, что MCP работает медленно. Локальный сервер добавляет вызов процесса на той же машине, а удалённый — один круговой обмен по HTTP. И то и другое незаметно по сравнению с секундами, которые модель тратит на написание ответа.
На самом деле важна стоимость контекста. Каждый инструмент, который загружает хост, приходит с описанием и схемой, которые модель должна прочитать, а каждый результат инструмента попадает в разговор. Сервер с восемьюдесятью многословными инструментами может занять заметную часть контекстного окна ещё до того, как вы что-то спросили. Поэтому на HostedMCP мы показываем полный список инструментов на странице каждого сервера: вы видите, насколько сервер большой, ещё до установки, и можете выбрать поменьше, если узконаправленный сервер справляется с задачей.
Как превратить API в хороший MCP server
Соблазнительный короткий путь — сгенерировать по одному инструменту на каждый эндпоинт из файла OpenAPI. Есть инструменты, которые делают именно это, и для быстрого прототипа они полезны. Но хороший сервер из них получается редко. Откройте пару листингов с несколькими сотнями почти одинаковых инструментов, и вы увидите проблему: модель вынуждена прочитать каждый из них, а большинство соответствует эндпоинтам, о которых никто не стал бы спрашивать в разговоре.
Модель мыслит не эндпоинтами, а задачами. «Найди клиента, который писал про счёт 1042, и покажи его последние три списания» — это одна задача, охватывающая несколько эндпоинтов. Хороший сервер предлагает инструменты на этом уровне: find_customer, который принимает email, номер счёта или имя, и recent_charges, который возвращает короткую читаемую сводку вместо сырого JSON с сорока полями.
| Инструмент в форме эндпоинта | Инструмент в форме задачи |
|---|---|
GET /customers?email= |
find_customer, который принимает email, номер счёта или имя |
GET /charges?customer= с 40 полями в ответе |
recent_charges, возвращающий короткую читаемую сводку |
| По одному инструменту на эндпоинт, сотни всего | Несколько инструментов под то, о чём спрашивают люди |
| Описания, скопированные из справочной документации | Описания, которые говорят, когда использовать инструмент |
Несколько привычек дают большую разницу.
-
Пишите описания для модели. Говорите, для чего инструмент и когда его использовать, а не только что он возвращает. «Используйте это перед созданием возврата, чтобы убедиться, что списание принадлежит клиенту» ценнее для модели, чем список полей.
-
Возвращайте меньше. Обрезайте ответы до полей, на которые человек действительно посмотрит, и делайте пагинацию с понятным курсором. Каждое лишнее поле стоит контекста и даёт модели больше поводов ошибиться.
-
Делайте опасные инструменты очевидными. Называйте их прямо, например
delete_project, и используйте подсказки read-only и destructive, которые предусматривает спецификация, чтобы хосты могли запрашивать подтверждение. А ещё лучше — не включайте деструктивные действия в первую версию. -
Валидируйте всё. Аргументы приходят от модели, которая прочитала недоверенный текст. Проверяйте типы, диапазоны и принадлежность на сервере так же, как для любого публичного эндпоинта.
Так что же стоит создавать?
Если у вас ещё нет API, сначала сделайте API. Он понадобится вашему приложению, скриптам и партнёрам в любом случае, а MCP server без надёжного API в основе обычно превращается во второй API, только хуже.
Если API у вас уже есть и вы хотите, чтобы им пользовались AI-инструменты, поставьте перед ним MCP server. Начните с нескольких инструментов, которые закрывают реальные запросы пользователей, пишите описания для модели, а не для разработчика, и по возможности предлагайте его и как локальный пакет, и как hosted endpoint. В нашем руководстве по созданию MCP server это разобрано на TypeScript и Python с актуальными SDK.
Если вам нужна всего одна AI-функция внутри одного приложения, которое вы контролируете, function calling сегодня вполне достаточно, а позже вы сможете превратить эти функции в MCP server, не меняя API под ними.
Что делать дальше
Чтобы увидеть, как это выглядит на практике, откройте несколько серверов, которые оборачивают известные API, например GitHub server или любой из Postgres servers, и сравните их списки инструментов с документацией соответствующего API. Вы заметите, как много они намеренно опускают. Если вы только знакомитесь с протоколом, начните с материала что такое MCP, а если хотите просто попробовать один сервер, в наших руководствах по клиентам приведена точная конфигурация для вашего редактора.