MCP vs Function Calling: чем отличается вызов инструментов AI Agent? Полное сравнение JSON Schema, API и Tool Calling

По документации Gemini API о Function Calling модель получает описание функции, возвращает её имя и аргументы, но исполняет функцию само приложение. Из этого следует главный вывод: MCP и Function Calling находятся на разных уровнях и обычно не являются взаимоисключающими вариантами. Function Calling помогает модели сформулировать намерение вызвать инструмент, а MCP стандартизирует обнаружение и подключение приложения к внешним инструментам. Для одного приложения с небольшим числом функций достаточно прямого вызова; при нескольких клиентах, общих инструментах или удалённом сервере имеет смысл добавить MCP.

Эта статья предназначена для трёх групп:

• разработчиков одного Agent, которым важно не превратить простой интеграционный слой в избыточную платформу;
• команд, поддерживающих несколько моделей и форматов Function Calling;
• руководителей миграции на MCP, которым нужно определить границы сервера, адаптера, разрешений и бизнес-API.

Слои архитектуры

Термин «вызов инструмента» часто объединяет несколько разных операций. Из-за этого Function Calling ошибочно воспринимают как протокол подключения к сервисам, а MCP — как новую способность модели. На практике цепочка выглядит иначе:

1. модель получает список доступных инструментов;
2. модель возвращает структурированный запрос — название функции и аргументы;
3. приложение проверяет этот запрос;
4. исполнитель обращается к API, базе данных, файловой системе или другому сервису;
5. результат возвращается модели для следующего шага.

Function Calling отвечает преимущественно за второй пункт и формат обмена между моделью и приложением. Модель предлагает вызов, но не получает автоматически доступ к базе данных, файловой системе или удалённому серверу. Исполнение, повторные попытки, обработка ошибок и контроль побочных эффектов остаются ответственностью приложения. В официальном руководстве OpenAI по Function Calling этот же принцип описан через цикл: приложение передаёт инструменты, получает вызов, исполняет код и отправляет результат обратно модели.

MCP работает рядом с третьим и четвёртым пунктами. Его архитектура разделяет host, client и server: host управляет приложением и разрешениями, client поддерживает соединение с конкретным сервером, а server предоставляет tools, resources и prompts. Обмен сообщениями основан на JSON-RPC 2.0, а возможности сторон согласуются при инициализации соединения. Архитектура MCP и роли host, client и server описывает именно эту границу.

Что делает JSON Schema

JSON Schema — это не исполнитель и не средство авторизации. Это контракт формы данных. В описании инструмента схема может определить:

• обязательные и необязательные поля;
• типы строк, чисел, массивов и объектов;
• допустимые значения через перечисления;
• вложенную структуру параметров;
• ограничения, которые можно проверить до исполнения.

Одна и та же схема может участвовать в нескольких местах, но её роль меняется. В Function Calling она сообщает модели, какие аргументы допустимы. В MCP она входит в описание инструмента, которое сервер публикует клиенту. В бизнес-API она может использоваться как дополнительная валидация входного запроса.

Официальная спецификация JSON Schema разделяет базовые правила описания структуры и правила валидации. Для архитектуры Agent это означает, что схема должна рассматриваться как отдельный контракт, а не как случайный фрагмент объекта SDK конкретной модели.

Однако корректный JSON не означает безопасную операцию. Запрос delete_project с правильным полем project_id может быть формально валидным, но всё равно запрещённым для конкретного пользователя. Поэтому JSON Schema отвечает на вопрос «имеют ли данные нужную форму», а не на вопросы «можно ли это делать», «кто это подтвердил» и «не устарел ли объект».

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

Сценарии применения

Один Agent и небольшой набор функций

Если приложение содержит один Agent, несколько локальных инструментов и один контролируемый backend, прямой Function Calling обычно является рациональным выбором. Приложение передаёт модели описания функций, принимает структурированный вызов, валидирует его и запускает собственный обработчик.

Такой путь сокращает количество движущихся частей:

• не требуется отдельный MCP-сервер;
• не нужно управлять жизненным циклом соединения;
• проще трассировать полный путь от ответа модели до API;
• права можно проверять в одном orchestration-слое;
• тесты быстрее привязать к конкретному приложению.

Это не означает, что внутренний интерфейс можно писать без расчёта на будущее. Даже в маленьком проекте стоит отделить модель инструмента от формата конкретного провайдера. Внутренняя команда событий может выглядеть так:

{
  "tool_name": "create_ticket",
  "arguments": {
    "project_id": "SUPPORT",
    "title": "Ошибка авторизации"
  },
  "schema_version": "2"
}

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

Несколько моделей и внутренний адаптер

При переключении между моделями проблема возникает не только в названии поля. Провайдеры могут различаться в способе объявления tools, представлении аргументов, выборе режима вызова, параллельных вызовах, возврате результата и обработке ошибок. Различия между форматами Function Calling особенно заметны в потоке сообщений: одна платформа может возвращать отдельный объект вызова, другая — блок в массиве контента, третья — собственный идентификатор операции.

Для такой команды нужен внутренний адаптер, но не обязательно MCP. Разумная граница выглядит следующим образом:

• модельный слой преобразует внутренние определения в формат конкретного API;
• orchestration-слой нормализует имя, аргументы, идентификатор вызова и статус;
• исполнитель принимает только внутреннее событие;
• бизнес-API получает уже проверенную команду;
• наблюдаемость записывает модель, версию схемы, решение о разрешении и итог операции.

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

Несколько клиентов и общий каталог инструментов

MCP начинает приносить заметную пользу, когда один набор инструментов должен использоваться разными клиентами: веб-Agent, IDE, desktop-приложением, CLI или внутренним операторским интерфейсом. Без протокола каждый клиент повторяет:

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

MCP выносит соединение и публикацию возможностей в отдельный сервер. Согласно официальному описанию MCP-серверов и примитивов, сервер может публиковать tools, resources и prompts: tools являются исполняемыми функциями, resources дают контекст, а prompts представляют заранее подготовленные шаблоны. Это позволяет клиентам обнаруживать capabilities через единый механизм, не встраивая отдельную интеграцию для каждого сервиса.

Но общий сервер добавляет ответственность. Команде нужно вести каталог инструментов, совместимость версий, журнал вызовов и правила отключения. Доступность инструмента для клиента не должна автоматически означать право на его выполнение.

Удалённые инструменты и macOS-зависимости

Удалённый MCP Server полезен, когда инструмент требует окружения, которого нет у основного backend: macOS-утилит, Xcode, симулятора, локального ключевого хранилища, GUI-приложения или специфического набора файлов. В этом случае сервер можно разместить на контролируемом удалённом Mac, а клиент Agent оставить в основном приложении.

Такое размещение — инженерное решение, а не требование протокола. MCP не превращает macOS в обязательную часть архитектуры и не предоставляет автоматически:

• аутентификацию пользователя;
• сетевое шифрование;
• изоляцию процессов;
• лимиты CPU, памяти и диска;
• очереди задач;
• резервное восстановление;
• аудит бизнес-операций.

Для удалённого сервера дополнительно проверяются транспорт, тайм-ауты, повторные запросы, идемпотентность, health checks и порядок удаления временных файлов. При постоянной доступности Mac-среды также нужно учитывать стоимость администрирования, обновлений и восстановления после зависшего процесса. Если команде нужен именно изолированный macOS-узел для тестирования или временного Agent, аренда удалённого Mac может быть практичнее, чем немедленная покупка отдельного компьютера. Это имеет смысл только при наличии реальной потребности в macOS-инструментах, а не ради самого названия MCP.

Опасные операции и границы доверия

Вызов read_customer, build_project и delete_environment нельзя защищать одинаково. Для чтения достаточно проверить область данных и идентификатор пользователя; для удаления необходимы подтверждение, политика доступа, журнал и защита от повторного запуска.

Безопасная схема должна содержать как минимум три уровня:

1. Уровень модели. Ограничивается перечень доступных инструментов, описывается назначение функции, запрещаются явно опасные комбинации и задаётся режим выбора.
2. Уровень MCP или исполнителя. Проверяются соединение, identity, tenant, разрешения, лимиты, происхождение запроса и возможность конкретного клиента вызвать tool.
3. Уровень бизнес-API. Выполняется окончательная авторизация, проверяется состояние объекта, идемпотентность и необходимость подтверждения.

MCP-документация по инструментам и их схемам отдельно указывает, что tool может иметь inputSchema, необязательный outputSchema и аннотации поведения. Эти поля помогают клиенту понять структуру операции, но не превращают описание сервера в доказательство его безопасности. Сервер может принять синтаксически корректный запрос и всё равно обязан отклонить его, если отсутствуют полномочия, истёк контекст согласия или объект уже изменён другой операцией.

Сравнение маршрутов

Выбор лучше делать не по количеству функций, а по числу клиентов, границам владения и требованиям к управлению. Одна сложная функция может остаться обычным внутренним вызовом, а несколько простых функций уже потребуют общего сервера, если их используют несколько независимых приложений.

Решение по условиям

• Если число клиентов равно одному, инструменты локальны, а команда контролирует весь pipeline — начинать с Function Calling.
• Если меняются модели, но не меняются владельцы инструментов — добавить внутренний адаптер и версионирование JSON Schema.
• Если один каталог требуется Agent, IDE и CLI — рассматривать MCP Server.
• Если сервер будет удалённым — сначала спроектировать identity, аудит, тайм-ауты и отказоустойчивость, а уже затем выбирать транспорт.
• Если действие изменяет данные или запускает затратную операцию — не считать ни Function Calling, ни MCP заменой подтверждения и бизнес-авторизации.

Такой подход не объявляет универсального победителя. MCP не является «более мощной моделью» и не повышает рассуждение Agent сам по себе. Он уменьшает дублирование на границе подключения и публикации инструментов. Function Calling, напротив, остаётся механизмом взаимодействия модели с приложением, даже когда список функций поступил через MCP.

Практическая миграция

Команде, у которой уже есть Function Calling-код, не следует начинать с полного переписывания. Безопаснее двигаться по следующим шагам.

1. Зафиксировать текущий контракт

Соберите перечень инструментов, аргументов, результатов, ошибок и побочных эффектов. Для каждого вызова запишите, является ли он чтением, изменением или удалением данных. Отдельно отметьте функции, которым требуются macOS, локальные файлы или физические устройства.

2. Отделить схему от провайдера

Перенесите описание аргументов во внутреннюю модель с версией. Не используйте объект SDK конкретной модели как доменный контракт. Для каждого инструмента определите:

• стабильное имя;
• schema_version;
• обязательные поля;
• допустимые значения;
• формат результата;
• классификацию риска;
• требования к подтверждению.

3. Нормализовать событие вызова

Создайте единый внутренний объект для вызова и результата. В нём должны быть tool_name, аргументы, идентификатор операции, субъект, tenant, версия схемы и дедлайн. Это позволит менять модели и API без переписывания бизнес-исполнителей. Описание tools и результаты tool use также следует учитывать в трассировке и расчёте контекста, поскольку они становятся частью обмена с моделью. Официальное руководство Anthropic по tool use.

4. Реализовать прямой и MCP-вариант одного инструмента

Возьмите один безопасный read-only инструмент и реализуйте два минимальных пути: прямой Function Calling и публикацию того же инструмента через MCP. Сравнивайте не только количество строк, но и границы ответственности:

• где загружается схема;
• где проверяется identity;
• где формируется ошибка;
• где появляется подтверждение;
• кто пишет аудит;
• что произойдёт при повторном запросе;
• как ведёт себя система при недоступном сервере.

Именно такой повторяемый тест лучше маркетингового сравнения. После изменения версии MCP или интерфейса модели его следует запускать заново.

5. Добавить MCP Server только для повторно используемой границы

Не выносите внутрь MCP каждую внутреннюю функцию. Сервер должен представлять самостоятельную capability: работу с репозиторием, macOS-сборкой, системой заявок или внутренним поиском. Слишком мелкие tools увеличивают каталог, усложняют разрешения и дают модели больше вариантов для ошибочного выбора.

6. Ввести защиту записи

Для операций записи задайте allowlist, проверку полномочий, лимиты, idempotency key и явное подтверждение. Если Agent запускает сборку на Mac или меняет конфигурацию проекта, сервер должен иметь отдельную учётную запись и ограниченный рабочий каталог. Разрешение на вызов инструмента не должно давать процессу полный доступ к машине.

7. Проверить отказоустойчивость

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

Технические расходы, которые часто пропускают

Первый расход — сопровождение каталога. При прямом Function Calling описание инструментов хранится рядом с приложением. При MCP появляется отдельный жизненный цикл: публикация, discovery, совместимость клиентов, обновление сервера и контроль доступности.

Второй расход — безопасность распределённого вызова. Function Calling сам по себе не решает вопросы сети, а MCP не выдаёт автоматически бизнес-права. В удалённой схеме добавляются authentication, authorization, audit, rate limit, тайм-ауты и защита от повторной доставки.

Третий расход — контекст. Имена, описания и JSON Schema инструментов отправляются модели или становятся частью доступного ей каталога. Поэтому длинные описания, дублирующие параметры и десятки почти одинаковых tools увеличивают сложность выбора и объём служебного обмена. Для финального ответа с жёсткой структурой следует отдельно рассматривать Structured Outputs, не смешивая их с промежуточным вызовом инструмента.

Опыт внедрения показывает: чаще всего ломается не сам вызов API, а несогласованность имён, версий схемы, кодов ошибок и правил повторного запуска. Поэтому тестировать нужно весь маршрут, а не только успешный JSON-ответ модели.

FAQ для архитекторов

MCP действительно заменяет Function Calling?
Нет. MCP и Function Calling решают разные задачи. Function Calling передаёт модели описание функции и позволяет получить структурированный запрос с именем и аргументами. MCP стандартизирует подключение приложения к внешним серверам, их обнаружение и публикацию инструментов. В архитектуре MCP может поставлять инструменты, а модель всё равно будет выбирать их через механизм Tool Calling конкретного API.

На каком уровне находятся MCP и Tool Calling?
Tool Calling находится на границе между моделью и вашим приложением: модель предлагает вызов, а приложение решает, выполнять ли его. MCP находится между host-приложением и внешним сервером инструментов. Он описывает соединение, обмен возможностями, каталог инструментов и вызов через протокол. Поэтому эти технологии нельзя корректно сравнивать как два взаимозаменяемых API.

Нужен ли MCP, если в системе только один Agent?
Обычно нет, если один Agent использует небольшой набор локальных функций и инструменты не должны подключаться к другим клиентам. Прямой Function Calling будет проще тестировать, отлаживать и защищать. MCP оправдан уже при наличии общего сервера, нескольких клиентов, удалённого размещения, независимого жизненного цикла инструментов или требования подключать новые Agent без копирования интеграционного кода.

Может ли MCP напрямую выполнить бизнес-API?
MCP-сервер может быть адаптером к бизнес-API и выполнять запросы к нему, но сам протокол не выдаёт бизнес-разрешение и не заменяет контроль доступа. Сервер должен проверить пользователя, контекст, параметры и допустимость операции. Финальная авторизация должна оставаться в бизнес-сервисе. Для записи, удаления и финансовых действий требуется отдельное подтверждение, даже если схема аргументов полностью корректна.

Как объединить MCP и Function Calling без лишнего слоя?
Наиболее устойчивый вариант — хранить внутреннее описание инструмента отдельно от формата конкретной модели, а MCP-сервер использовать как стандартный источник обнаружения и исполнения. На входе адаптер преобразует каталог MCP в формат tools нужного API, на выходе нормализует результат и ошибку. Авторизация, подтверждение и аудит выполняются до передачи команды бизнес-сервису.

Финальная проверка перед внедрением

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

• Function Calling без MCP — 5 баллов, если один клиент владеет инструментами и сервер не должен переиспользоваться.
• Внутренний адаптер — 5 баллов, если основной риск связан с несколькими моделями и разными форматами API.
• MCP — 5 баллов, если инструменты должны обнаруживаться и подключаться несколькими клиентами.
• Удалённый MCP Server — 5 баллов, если инструменту действительно требуется отдельная macOS-среда, а команда готова управлять доступом, сетью и журналами.

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

На практике текущая схема на Windows, Linux или обычном облачном сервере может быть дешевле для чистых HTTP-инструментов, но у неё появляются ограничения, когда Agent должен управлять Xcode, macOS-сборкой, симулятором или приложением, доступным только в Apple-окружении. Покупка отдельного Mac, в свою очередь, не всегда оправдана для короткого проекта: оборудование потребует постоянной оплаты, обновлений и физического администрирования. Если архитектурное решение действительно требует общего удалённого MCP Server с macOS-зависимостями, стоит рассмотреть аренду Mac для изолированной среды, а перед этим сверить ограничения, поддержку и условия эксплуатации в руководстве по поддержке Mac. Для временного тестирования и миграционного этапа такой вариант обычно легче вернуть или отключить, чем содержать постоянно включённый физический узел.