Нужен ли вашему LLM-приложению MCP? MCP vs CLI vs function calling

В обсуждениях разработчиков всё чаще звучит вопрос: LLM-фича должна читать базу или запускать команду деплоя — нужно ли сразу писать MCP-сервер? Иногда да. Но чаще честный ответ такой: пока нет.

MCP, Model Context Protocol, полезен тем, что даёт AI-приложениям стандартный способ находить инструменты, ресурсы и prompts. Но стандарт не обязан быть первой абстракцией для каждого случая.

Начинайте с поверхности интеграции

Function calling, CLI и MCP решают одну задачу: дать модели безопасные структурированные возможности. Разница в том, где живёт контракт.

При native function calling контракт находится внутри приложения. Вы описываете схемы, получаете tool calls, выполняете серверный код и возвращаете результат. Это прямой, хорошо отлаживаемый и часто самый быстрый путь в продакшен.

При CLI-слое контракт — исполняемая команда. Тесты, type checks, миграции, инфраструктурные планы и поиск по репозиторию уже имеют форму команд. Правильная архитектура — не открытый shell, а узкий broker с allowlist, timeout, валидацией, лимитами вывода и логами.

При MCP контракт становится протоколом между клиентом и сервером. Это оправдано, когда одна и та же возможность должна жить дольше одного SDK, одного host-приложения или одной команды.

Когда достаточно function calling

Для первой версии продуктовой функции function calling обычно лучший старт. Аутентификация, логи, rate limits, multi-tenancy и incident response остаются внутри границы приложения, которую вы уже обслуживаете.

Если инструменты специфичны для продукта — поиск заказов, подготовка возврата, резюме истории аккаунта — MCP может добавить сложность без улучшения опыта пользователя.

Проблема появляется позже, когда несколько команд реализуют один и тот же инструмент в нескольких host-приложениях. Тогда MCP становится привлекательным.

Когда CLI лучше

Для coding agents и инфраструктурных workflow CLI часто самая честная поверхность. Она воспроизводится локально, наследует соглашения проекта, выдаёт понятные людям логи и завершается exit code.

Если workflow уже command-native, сначала оберните CLI. Возвращайте модели структурированное резюме, а сырые логи сохраняйте для людей.

Когда MCP стоит сложности

MCP стоит применять, когда одна возможность нужна в нескольких AI-средах: поиск по knowledge base, контекст репозитория, design system, метаданные БД или audit logs. Одна команда может владеть сервером, а многие приложения — использовать его.

См. также наши паттерны MCP в продакшене и стратегию MCP для SaaS.

MCP не отменяет операционные задачи: authentication, authorization, secrets, rate limits, telemetry, versioning схем и безопасные ошибки всё ещё нужны.

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

Один клиент и продуктовая логика: function calling. Уже существующий человеко-читаемый command workflow: CLI broker. Несколько AI-клиентов, распределённая ownership и стабильные инструменты: MCP.

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