MCP-сервер или API: сколько стоит один запрос к GoCD
Недавно мы решили создать собственный MCP-сервер для GoCD. Причина была вполне практической: MCP постепенно становится привычным интерфейсом для подключения LLM-агентов к инфраструктуре, но готового решения для GoCD, подходящего под наши требования, не существовало.
Проект уже больше месяца используется в работе и продолжает развиваться. За это время версия выросла до 1.2.0. Однако после первого энтузиазма, связанного с запуском собственного open source-инструмента, возник закономерный вопрос: действительно ли MCP нужен, если у GoCD уже есть полноценный REST API?
MCP против нативного API
У GoCD хорошо документирован REST API. Теоретически достаточно передать агенту описание методов, предоставить `curl`, токен доступа и базовые инструкции - и он сможет выполнять большинство операций самостоятельно. В этом случае GoCD интеграция строится без отдельного промежуточного слоя.
MCP-сервер требует гораздо больше вложений. Его необходимо спроектировать, реализовать, протестировать, описать, опубликовать, а затем поддерживать при каждом изменении API. Если итоговый результат не отличается, подобная разработка превращается лишь в ещё один инструмент ради самого инструмента.
С другой стороны, практический опыт показывает, что агент через специализированные инструменты часто действует быстрее и точнее. Но субъективные впечатления разработчика нельзя считать надёжным доказательством. Поэтому мы решили сравнить подходы экспериментально - заранее определить план, изолировать условия и измерить не только успешность выполнения, но и фактическую стоимость.
Подробное описание архитектуры и результатов эксперимента с MCP-сервером GoCD доступно в материале о сравнении MCP и API: сравнение MCP-сервера и GoCD API.
Что именно проверялось
Целью исследования не было выяснить, способен ли LLM-агент решить поставленную задачу через API или MCP. Очевидно, что при наличии достаточной документации он, скорее всего, справится в обоих сценариях. Нас интересовал другой вопрос: какой вариант обходится дешевле - по времени, числу действий и затратам на токены.
Тесты должны были напоминать обычную эксплуатацию, а не набор искусственных примеров. При этом мы сознательно отказались от редких или экзотических операций.
В эксперимент включили семь задач:
- запуск пайплайна с последующим отчётом о результате;
- построение цепочки с передачей значения между этапами;
- создание, запуск, подтверждение, отчёт и удаление пайплайна;
- анализ причины падения;
- перезапуск отдельной стадии;
- изменение конфигурации с использованием оптимистичной блокировки;
- поиск нужного выполнения за пределами первой страницы истории.
За рамками остались функции, которых текущий MCP-сервер не поддерживает в принципе, например управление elastic-профилями или удаление агентов. Это вопрос полноты реализации, а не сравнения механизмов. Также не рассматривались сценарии безопасности, в которых агент обязан отказаться от выполнения операции. Безопасность требует отдельного масштабного исследования.
Экономический смысл эксперимента прост: разницу в стоимости одного запроса нужно сопоставить с затратами на разработку и сопровождение сервера. У каждой команды своё количество обращений к GoCD, поэтому универсального ответа "MCP всегда выгоднее" или "API всегда достаточно" быть не может. Задача исследования - предоставить исходные данные для такого расчёта.
Условия эксперимента
Сравнивались два варианта.
Вариант A - MCP. Использовался `gocd-mcp` версии 1.2.0 с полным набором из 23 инструментов. Агент получал короткий skill:
> GoCD управляется через инструменты gocd-mcp; изучай описания инструментов - в них указаны правила подтверждения запусков и работа с ETag.
Вариант B - API. Агенту предоставлялся механический дайджест официальной документации GoCD API версии 25.4.0. В него вошли HTTP-методы, эндпоинты, версии заголовка `Accept`, форматы тел, правила использования `ETag` и `If-Match`, а также заголовок `X-GoCD-Confirm`.
Кроме того, были указаны базовый URL GoCD и имя переменной окружения, в которой должен находиться токен. Для работы с API агент использовал обычные shell-инструменты - `curl` и `jq`.
Токен находился только в конфигурации MCP-клиента для варианта A. В окружении shell его не было, поэтому MCP-агент не мог незаметно обратиться к GoCD напрямую. Для варианта B токен хранился в переменной `GOCD_PAT`, а MCP-инструменты были недоступны. Таким образом, оба режима оставались изолированными и не могли подменить друг друга.
Документация для API не писалась вручную. Её собрали из исходных материалов, чтобы исключить подсказки, подготовленные специально под тестовые задания. В дайджесте отсутствовали нюансы, которые обнаружились во время разработки сервера: особенности ответа `202 Accepted`, курсорная пагинация и необходимость предварительной проверки имени перед использованием ETag. Это было сделано намеренно. Если API-агент показывал худший результат, требовалось понять, проиграл ли он из-за самого подхода или из-за неполноты предоставленных знаний.
Тесты выполнялись на модели Claude Fable 5 через стандартный Claude Code CLI. Для каждой задачи создавалась новая сессия без контекста предыдущих попыток. Это позволяло оценивать не накопленный опыт агента, а его способность решать задачу в заданных условиях.
Что влияет на стоимость запроса
При прямой работе с API агент самостоятельно планирует последовательность действий. Это может приводить к лишним вызовам: сначала он получает список пайплайнов, затем уточняет идентификатор, отдельно проверяет состояние, повторно запрашивает историю или исправляет ошибку в заголовке. С точки зрения оплаты модели каждая такая операция увеличивает расход токенов.
MCP-сервер способен скрыть часть технических деталей. Один инструмент может объединять несколько низкоуровневых запросов, автоматически добавлять нужные заголовки, проверять статус операции и возвращать агенту более компактный результат. В этом случае сокращается не только количество HTTP-вызовов, но и объём рассуждений вокруг них.
Однако абстракция имеет обратную сторону. За готовыми инструментами нужно следить: обновлять схему, поддерживать совместимость с новыми версиями GoCD, расширять покрытие и тестировать ошибки. Кроме того, неудачно спроектированный MCP-интерфейс способен ограничить агента сильнее, чем хорошо подготовленная документация к API.
Именно поэтому автоматизация GoCD не сводится к выбору самого модного протокола. Важно учитывать частоту операций, критичность ошибок, требования к аудиту, доступность команды разработки и стоимость сопровождения. Для нескольких редких административных запросов API может оказаться рациональнее. Для регулярного управления пайплайнами и сложных цепочек действий специализированный MCP-слой способен быстро окупить вложения.
Практический результат также зависит от качества инструментов. Хороший MCP-сервер должен не просто дублировать REST-методы, а давать агенту понятные операции с корректными ограничениями: требовать подтверждение опасных действий, аккуратно работать с блокировками, различать успешное принятие запроса и завершение операции, а также возвращать данные в удобной для анализа форме.
В итоге сравнение MCP и API - это не соревнование технологий, где один вариант безусловно побеждает другой. MCP сервер для DevOps становится оправданным тогда, когда снижает сложность повторяющихся сценариев и уменьшает число ошибок агента. Нативный API остаётся сильным выбором, если важны минимальные расходы, прозрачность запросов и отсутствие дополнительного слоя сопровождения. Финальное решение стоит принимать на основе реального профиля нагрузки, а не только популярности MCP.
