MCP в Claude Code: когда оставить инструмент, а когда выполнить команду

Что именно добавляет MCP в работу с Claude Code

По документации Claude Code, MCP-серверы дают доступ к внешним инструментам и данным. Для модели это не только результат очередного вызова. В сессии появляются названия инструментов, их назначение, входные схемы и ограничения. Чем шире сервер и чем больше инструментов доступно без фильтра, тем больше вариантов агенту приходится учитывать до первого вызова.

Это не означает, что у MCP есть фиксированная «цена в токенах». Она зависит от сервера, включённых инструментов, запроса, истории сессии и того, какие результаты вернул инструмент. Практически полезнее отслеживать три наблюдения:

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

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

Когда MCP оправдан, а когда достаточно команды

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

Проведите маленькое сравнение на одной задаче

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

1. Зафиксируйте условие. Запишите короткий prompt, рабочую директорию и ожидаемый результат. Например: «покажи изменённые файлы и предложи один следующий шаг без изменения репозитория».
2. Выполните задачу с текущим MCP-набором. Сохраните только безопасные наблюдения: число ходов, использованные инструменты, итог и время запроса. Не копируйте в заметку API Key, .env или полный чувствительный вывод.
3. Временно отключите один сервер в панели /mcp. Панель сохранит его конфигурацию и пометит сервер как disabled. Закройте текущую сессию, запустите новую и снова откройте /mcp: тестируемый сервер должен остаться в списке, но не подключаться. Повторите тот же prompt.
4. Сравните не только объём ответа. Проверьте, получил ли агент тот же необходимый факт и не заменил ли он полезный инструмент догадкой.
5. Снова включите сервер через /mcp, откройте новую сессию и проверьте его статус. Верните сервер в рабочий профиль, если без него задача стала требовать ручного копирования данных или потеряла важную проверку. Оставьте упрощённую конфигурацию, если результат сохранился, а лишних вызовов стало меньше.

Новая сессия важна: старая история уже содержит результаты инструментов и не даёт чистого сравнения. Такой тест не измеряет универсальную производительность Claude Code, зато помогает принять решение для вашего обычного сценария.

Один сопоставимый вариант команды

Не заменяйте MCP произвольной командой. Для локального статуса эквивалентом может быть короткий read-only вызов, который возвращает тот же факт, что и инструмент:

git status --short

В тесте запросите только список изменённых файлов и один следующий шаг без записи в репозиторий. В варианте с MCP и в варианте с командой сохраните одинаковые prompt и ожидаемый список файлов. Затем сначала сверяйте сам список, а уже потом число ходов, вызовов и Token. Если инструмент возвращал внешний факт, которого git status не содержит, это не эквивалентная замена: оставьте узкий read-only MCP либо документированную команду к той же системе.

Уменьшайте поверхность инструмента, а не только список серверов

У широкого MCP-сервера иногда есть много команд, хотя проекту регулярно нужны одна или две. Начните с их границы:

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

Это также упрощает разрешения. MCP может обращаться к внешним данным и действиям, поэтому его наличие не отменяет обычную проверку доступа, scope токена и результата вызова. Текстовый ответ модели не доказывает, что внешняя операция была выполнена корректно.

Где смотреть usage после теста

Для API-сценария Claude Code можно использовать собственный ключ BetterToken и сверять конфигурацию с актуальной документацией для Claude Code. BetterToken является отдельным API-доступом, а не подпиской Claude. API Key создаётся и хранится в аккаунте пользователя; его не нужно помещать в репозиторий, handoff или журнал эксперимента.

В Dashboard BetterToken доступны время запроса, модель, статус и расход input, output и cache token. Для каждого запуска запишите одну строку: model, дату и время, input, output, cache, показанный расход и число ходов. Запускайте оба варианта с одной моделью и одинаковым prompt, иначе разница смешивает несколько изменений.

Если Dashboard показывает готовый расход, сравните его напрямую: наблюдаемая разница = расход запуска с MCP − расход запуска без MCP. Если видны только Token, сначала откройте текущую страницу цен BetterToken, зафиксируйте дату, модель и правила cache, а затем применяйте расход = input/1 000 000 × Pinput + output/1 000 000 × Poutput + cache/1 000 000 × Pcache, только если цена страницы выделяет cache отдельно. Пустое или неясное поле не заменяйте нулём и не подставляйте старую цену.

Это расчёт для двух наблюдений, а не фиксированная «цена MCP»: на итог также влияют prompt, история сессии, модель, ответы инструментов и повторные чтения. Сохраните таблицу рядом с экспериментом без API Key, .env и полного чувствительного вывода.

Проверьте решение в правильном порядке

Перед тем как убрать MCP из рабочего профиля, идите по этому порядку:

1. Обязательный внешний факт. Убедитесь, что замена действительно получает нужный тикет, статус, запись API или документ, а не предполагает его.
2. Корректность и граница доступа. Сверьте ожидаемый результат и убедитесь, что тест остался read-only и не требует нового секрета или более широкого scope.
3. Сохранность проверки. Проверьте, что не исчезла валидация, которую раньше выполнял инструмент; текстовый ответ модели не является заменой внешней проверки.
4. Только затем измеряйте цену. Сравните число ходов, вызовов, input/output/cache Token и показанный расход на одинаковом prompt в новой сессии.

Если первые три пункта не пройдены, меньший расход не делает конфигурацию лучше: вы сравнили разные задачи или перенесли проверку человеку.

Признаки, что решение нужно пересмотреть

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

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

Источники

• MCP в Claude Code
• Документация BetterToken для Claude Code
• Сайт BetterToken