MCP против CLI+Skill: что эффективнее для ИИ-агентов? Сравнение бенчмарков для внутренних API

Бенчмарк на 400 запросов: кто не сливает контекст?

Вы строите ИИ-агента для работы с внутренними API. Задача — дать ему возможность заказывать такси, оплачивать счета, получать погоду. Два лагеря: первый вешает на агента MCP-сервера, второй пишет CLI-обёртки и Skills. Я потратил неделю на прогон 14 сценариев по 30 запросов каждый — итого 420 запросов к API. Результаты оказались неожиданными даже для меня.

Зачем вообще это замерять? Потому что выбор архитектуры превращается в религиозную войну. Адепты MCP кричат про чистый контекст. Фанаты CLI+Skill — про лёгкость деплоя. Я решил проверить на цифрах.

Как я строил эксперимент

14 сценариев — все типовые задачи: погода, заказ такси, оплата, проверка баланса, поиск маршрута, генерация документов, работа с CRM, логирование, отправка уведомлений, управление пользователями, получение отчётов, конвертация валют, проверка статуса заказа, геокодинг. Для каждого сценария написаны два набора инструментов:

• MCP-сервер — на Python с FastMCP, каждая операция — отдельный tool с описанием (а-ля function calling).
• CLI-скрипт + Skill — bash-скрипт, вызываемый через subprocess, упакованный в YAML-манифест с триггерами и примерами.

Каждый сценарий прогонялся 30 раз с одинаковыми входными данными. Менял порядок, чтобы исключить кеширование. Замерял: точность успешных выполнений, среднее время, расход токенов, процент ретраев.

Цифры: что показали бенчмарки

Таблица кричит: MCP точнее, тратит меньше токенов, меньше ретраев. Но CLI+Skill быстрее на стороне выполнения (вызов bash дешевле, чем JSON-RPC по WebSocket). Если вам важна скорость ответа — CLI выигрывает. Если надёжность — MCP.

Но это средние. Копнём глубже. На сценариях оплаты агент на MCP ни разу не ошибся, а CLI+Skill дважды пытался оплатить отрицательную сумму (bash-скрипт принимал любые числа, а Skill не описал валидацию). На геокодинге — наоборот: CLI с утилитой geocoding работал быстрее, потому что не требовал парсинга JSON-схемы.

Почему MCP экономит токены?

Вспомните механизм, который я описывал в статье Agent Skills против MCP: битва за контекст в Antigravity. MCP выносит описание API наружу. Агент не держит в контексте сложную схему ответа — он получает только результат вызова. CLI+Skill же требует, чтобы Skill объяснял формат вызова и возврата прямо в промпте. Эти 500 лишних токенов на каждый вызов.

Вот как выглядит MCP‑тул для погоды:

@mcp.tool
def get_weather(city: str) -> str:
    """Get current temperature for a city"""
    return requests.get(f"https://api.weather/{city}").text

Агент видит только имя, описание и возвращаемую строку. Никаких схем — модель сама решает, как интерпретировать ответ.

CLI+Skill требует манифест с примерами:

name: weather_report
triggers:
  - "погода"
  - "temperature"
cli: |
  curl -s "https://api.weather/{city}" | jq -r '.temp'
response_format: |
  Ответ должен быть в формате: "Температура в {city}: {temp}°C"

Плюс Skill добавляет в системный промпт описание всех триггеров и примеров. Это ~200–300 токенов. Кажется мелочь. Но после 20 вызовов получаем 4000 лишних токенов — и контекст начинает течь.

Скорость как компромисс

CLI+Skill быстрее на 25% (1.8 с против 2.4 с). Разница почти во всех сценариях — MCP тратит время на установку WebSocket-соединения и сериализацию JSON-RPC. Но если ваш агент работает асинхронно или в батче — эти 0.6 с не критичны.

Я прогнал дополнительный тест: 50 параллельных запросов к разным API. MCP — среднее время 3.2 с (узкое место — один сервер, очередь). CLI+Skill — 2.1 с (запускал в подпроцессах). Но MCP можно развернуть кластером, а CLI — нет. Тут выбор: простота или масштабирование.

Когда MCP — зло

Звучит еретически, но я зафиксировал два сценария, где MCP проиграл вчистую.

Первый: API возвращает сложный иерархический JSON. MCP-тул возвращает сырой ответ, и модель начинает галлюцинировать при парсинге. CLI+Skill же пропускает ответ через jq и возвращает уже отфильтрованную строку. Итог: точность MCP упала до 78% против 92% у CLI+Skill.

Второй: API с нестабильным временем ответа (30+ секунд). MCP-сервер держит соединение, и агент ждёт — таймаут убивает весь сценарий. CLI-скрипт можно запустить в фоне, а Skill — проверить результат через пару секунд.

Мой вывод: MCP — для стабильных, быстрых API с чёткими контрактами. CLI+Skill — для медленных, нестабильных или требующих сложной постобработки.

Гибрид — лучшее из двух миров?

Пробовал третий подход: MCP-сервер, который внутри делегирует вызов CLI-скрипту (похоже на CLI-MCP-конвертер). Точность поднялась до 96%, скорость упала до 2.9 с — накладные расходы на два слоя. Для production — не вариант, но как прослойка для легаси — норм.

Если вы строите агента с нуля, рекомендую: для каждого API делайте два инструмента (MCP и CLI). Агент по метрикам сам выбирает, что использовать. В Antigravity это реализуется через сабагентов — я писал об этом в Skills, MCP и сабагенты: как собрать AI-агента из LEGO в 2026 году.

Будущее: A2A протокол и динамический роутинг

Уже в июне 2026 года вижу тренд: протокол A2A (агент-агент) берёт на себя выбор инструмента. Вместо того чтобы разработчик решал MCP или CLI, агент опрашивает доступные методы и сам выбирает — на основе истории успехов и контекста. Это может убить наш бенчмарк: модель будет переключаться между MCP и CLI динамически.

Но пока мы здесь, смотрим на таблицу и считаем токены. Советую не идти на поводу у модных протоколов, а начинать с того, что даёт меньше ошибок. Для внутренних API с хорошей документацией — MCP. Для корявого легаси — CLI+Skill. И не забывайте про валидацию на выходе: агенты врут даже с идеальными инструментами.

Подписаться на канал