Можно использовать оба сразу?

Да, и многие приложения так и делают. Function calling - для внутренних инструментов, которые пользователь никогда не видит (авторизация, внутренние выборки). MCP - для инструментов, к которым пользователь захочет дотянуться из других клиентов. Оба прекрасно живут в одной сессии Claude.

MCP медленнее function calling?

Чуть-чуть. Function calling работает внутри процесса; MCP - это JSON-RPC поверх stdio или HTTP-SSE. Дополнительная задержка - единицы миллисекунд для stdio и 50-100 мс для HTTP. Для процессов, упирающихся в работу языковой модели, эта стоимость незаметна - модель всё равно отвечает 2-30 секунд.

Работает ли MCP с моделями не от Anthropic?

Работает. MCP не привязан к модели - протоколу всё равно, какую языковую модель вы используете. Goose, Continue и совместимая прослойка от OpenAI спокойно гонят MCP-серверы против моделей не от Claude. Anthropic выпустил MCP первым, потому что вложился рано; сам протокол открытый.

Стоит ли переводить уже работающее function-calling-приложение на MCP?

Только если хотите, чтобы инструменты стали доступны и вне приложения - конвейеру непрерывной интеграции, Claude Desktop, агенту коллеги. Если инструменты навсегда останутся только внутри приложения - function calling вас устраивает.

Все статьи

MCPMCPfunction callingинженерия

MCP против function calling: когда переходить, а когда не стоит

Function calling - это приём внутри одного приложения: инструменты объявляются прямо в разговоре через SDK с языковой моделью. MCP (Model Context Protocol) - это межприложенческий приём: инструменты живут отдельным сервисом по JSON-RPC, и любой совместимый клиент (Claude Desktop, Claude Code, SDK-приложения, агенты) сам их находит и вызывает.

inite26 апр. 2026 г.2 мин чтения

Берите function calling, если у вас одно приложение на SDK, инструменты простые и вы держите в руках и клиента, и сервер. Берите MCP, если хотите, чтобы один и тот же набор инструментов работал в Claude Desktop, Claude Code, у агентов и в непрерывной интеграции без переписывания интеграции; если у инструментов есть побочные эффекты, которые проще держать в одном месте; или если вы делаете продукт, который пользователи будут подключать к собственному клиенту языковой модели. Дерево решения на 90% сводится к числу клиентов: один клиент - function calling, два и больше - MCP.

Ключевые факты

Function calling появился в API OpenAI в июне 2023 года; Anthropic добавил его в мае 2024.
MCP вышел в общую доступность в Claude Desktop в ноябре 2024 года.
Готовые MCP-серверы есть для файловой системы, GitHub, Slack, Postgres и ещё 50+ интерфейсов на апрель 2026 года.
Перенос приложения с SDK на MCP - в среднем 80-200 строк кода на пять инструментов (по реальным портированиям, которые мы замеряли).

Function calling и MCP решают одну и ту же корневую задачу - дать языковой модели вызывать ваш код - но в разном масштабе. Выбор не того стоит вам недели; выбор правильного - в основном вопрос подсчёта клиентов.

Простое правило

Один клиент языковой модели → function calling. Два и больше → MCP.

Это 90% решения. Остальные 10% - пограничные случаи.

Где function calling всё ещё выигрывает

Три сценария:

Сборка одного SDK-приложения. Вы выпускаете чат-бот внутри Next.js-приложения. Инструменты лежат рядом с обработчиками маршрутов. Пользователь с языковой моделью напрямую не разговаривает - он работает с вашим интерфейсом. MCP добавит возни без отдачи.
Инструменты с требованием к задержке в доли миллисекунды. Function calling работает внутри процесса. MCP добавляет накладные расходы JSON-RPC - обычно незаметные, но если вы оптимизируете хвостовую задержку на потоковой выдаче токенов, внутрипроцессный вызов выигрывает.
Инструменты, плотно сцеплённые с вашей авторизацией и сессией. Если инструменту нужна авторизованная сессия пользователя, MCP делает передачу авторизации неудобной. Function calling остаётся внутри контекста запроса.

Где выигрывает MCP

Пять сценариев в порядке возрастания выгоды от MCP:

Один и тот же инструмент нужен из разных клиентов. Claude Desktop, Claude Code, SDK, скрипт непрерывной интеграции, агент коллеги - все ходят к одному MCP-серверу. Написали один раз, подключили везде.
Клиента языковой модели выбирает пользователь. Вы выпускаете продукт (как ideaudit). У пользователей либо Claude Desktop, либо Claude Code, либо другой совместимый клиент. MCP - это как достать всех разом.
Нужна централизованная запись вызовов инструментов. MCP-серверы пишут каждый вызов в одно место. Function calling рассыпает журналы по каждому приложению-потребителю.
У инструментов есть побочные эффекты на общую инфраструктуру. Записи в базу, лимиты вызовов API, счётчики тарификации. Завести их в MCP-сервере - значит иметь одно горло вместо N.
Хочется готовых инструментов. Файловая система, GitHub, Slack, Postgres - в экосистеме MCP уже десятки. Function calling значит переписывать каждую интеграцию под каждое приложение.

Шаблон переноса

Если у вас уже есть SDK-приложение и хочется выставить его инструменты ещё и в Claude Desktop:

Вынесите определения инструментов из вызова SDK в отдельный модуль.
Оберните этот модуль в MCP-сервер (на TypeScript или Python - шаблонный код около 50 строк).
Оставьте SDK-приложение, которое вызывает тот же модуль локально для своих внутренних инструментов.
Зарегистрируйте MCP-сервер в конфиге Claude Desktop.

Тот же код теперь обслуживает обоих клиентов. Стоимость переноса по реальным портам, которые мы замеряли: 80-200 строк кода на пять инструментов.

Что выбрал ideaudit

MCP, насквозь. Причина: у пользователей есть Claude Desktop, Claude Code и SDK-приложения. Нам нужен был один сервер, одна модель авторизации, один ограничитель вызовов. Function calling в каждом клиенте означал бы три реализации одних и тех же 103 инструментов и молитву, чтобы они оставались в синхроне.

curl -fsSL https://inite.studio/install.sh | sh

Те же 103 инструментов одинаковы независимо от того, разговариваете вы с ideaudit из Claude Desktop, Claude Code или SDK. Вот вся выгода MCP в одном предложении.

FAQ

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

Можно использовать оба сразу?
Да, и многие приложения так и делают. Function calling - для внутренних инструментов, которые пользователь никогда не видит (авторизация, внутренние выборки). MCP - для инструментов, к которым пользователь захочет дотянуться из других клиентов. Оба прекрасно живут в одной сессии Claude.
MCP медленнее function calling?
Чуть-чуть. Function calling работает внутри процесса; MCP - это JSON-RPC поверх stdio или HTTP-SSE. Дополнительная задержка - единицы миллисекунд для stdio и 50-100 мс для HTTP. Для процессов, упирающихся в работу языковой модели, эта стоимость незаметна - модель всё равно отвечает 2-30 секунд.
Работает ли MCP с моделями не от Anthropic?
Работает. MCP не привязан к модели - протоколу всё равно, какую языковую модель вы используете. Goose, Continue и совместимая прослойка от OpenAI спокойно гонят MCP-серверы против моделей не от Claude. Anthropic выпустил MCP первым, потому что вложился рано; сам протокол открытый.
Стоит ли переводить уже работающее function-calling-приложение на MCP?
Только если хотите, чтобы инструменты стали доступны и вне приложения - конвейеру непрерывной интеграции, Claude Desktop, агенту коллеги. Если инструменты навсегда останутся только внутри приложения - function calling вас устраивает.