Вы подключили GitHub MCP и ещё несколько серверов. Кажется удобно. Но до первого сообщения модель уже потратила больше 100 килотокенов на определения инструментов. Это скрытый налог - token tax - который почти никто не замечает, пока контекстное окно не переполняется.
Один только GitHub MCP потребляет около 46-55 тысяч токенов. Просто за факт подключения, ещё до единого вопроса. Добавьте Playwright (около 13 600 в моей конфигурации), omnisearch (около 14 100) - и вот уже 50-70% context window уходит в никуда на старте сессии.
В этой статье разбираем механизм проблемы, решение, которое появилось в январе 2026, и архитектурный выбор между MCP и Skills.
Масштаб проблемы
Разработчик Scott Spence задокументировал, что при стандартной рабочей конфигурации модель тратит более 66 000 токенов ещё до первого пользовательского сообщения. Joe Njenga зафиксировал аналогичную ситуацию: четыре MCP-сервера потребляли 51 000 токенов сразу при инициализации сессии.
Это не аномалии. Нормальное поведение архитектуры MCP.
Команда /doctor в Claude Code позволяет увидеть этот налог напрямую. Инструмент выдаёт предупреждение, когда MCP-инструменты занимают более 25 000 токенов. Я запускаю /doctor после каждого изменения конфигурации - и каждый раз удивляюсь, насколько велики цифры у разработчиков, которые добавляли серверы без учёта этой стоимости.
Почему это происходит - объясняет архитектура контекстного окна. MCP-инструменты занимают отдельный слой контекста, который загружается автоматически при подключении сервера, независимо от того, используются ли инструменты в текущей сессии. Подробнее о четырёхслойной архитектуре - в статье «Как устроен контекст внутри».
Я использую только один MCP-сервер - exa для веб-поиска. Не ограничение. Осознанный архитектурный выбор.
Механизм потребления
Когда вы подключаете MCP-сервер, Claude Code загружает в контекст определения всех его инструментов одновременно. Каждое определение включает имя, описание и полную JSON Schema параметров. Для GitHub MCP это 91 инструмент с полными схемами.
Главная проблема: эти определения остаются в контексте на протяжении всей сессии. Они не сжимаются через compaction - систему сжатия, которая работает с историей переписки. Tool definitions существуют в отдельном слое, и compaction их не затрагивает.
Skills работают принципиально иначе. Они загружаются только при явном вызове. Скрипт выполняется вне контекстного окна, промежуточные результаты обрабатываются в коде - не накапливаются в контексте. On-demand context injection в чистом виде.
По наблюдениям сообщества и опубликованным бенчмаркам Anthropic, MCP потребляет на порядок - а в некоторых сценариях на два порядка - больше токенов, чем эквивалентные Skills-операции. Именно поэтому я выбираю Skills для частых операций - git, файловые манипуляции, стандартные workflow - и резервирую MCP для того, что Skills не может делать.
Tool Search: lazy loading для MCP
В январе 2026 Anthropic выпустила MCP Tool Search - механизм, который меняет архитектуру потребления токенов.
Вместо загрузки всех определений сразу Tool Search реализует lazy loading: в контексте хранится только поисковый механизм с минимальным следом. Когда модели нужен конкретный инструмент, она выполняет поиск по имени и описанию - и только тогда нужные определения загружаются в контекст.
Результаты существенные. Того же Joe Njenga, чьи показатели проблемы составляли 51 000 токенов, Tool Search вернул к 8 500 - минус 83%. Разработчик Can Dedeoglu задокументировал снижение до 95%+ при аналогичных конфигурациях с GitHub MCP. Это не оптимизация - смена архитектурного паттерна.
Simon Willison из проекта Datasette публично высказался о том, что загрязнение контекста было главной причиной, по которой он избегал MCP. Tool Search снял это препятствие.
Как включить. Tool Search активируется автоматически, когда MCP-инструменты превышают 10% контекстного окна. Можно также включить явно через параметр enable_tool_search в конфигурации. Проверить эффективность - командой /doctor.
После выпуска Tool Search главное техническое ограничение на множественные MCP-серверы исчезло. Но это не повод подключать всё подряд - это свобода осознанного выбора. Понимание context engineering как парадигмы остаётся важным: Tool Search снижает налог, но не отменяет необходимость проектировать контекст осознанно.
Skills vs MCP: архитектурное сравнение
С появлением Tool Search выбор между Skills и MCP стал практическим, а не вынужденным. Ключевые параметры:
| Аспект | MCP | Skills |
|---|---|---|
| Загрузка определений | Все сразу в контекст | Только при вызове |
| Выполнение | Tool call - в контексте | Скрипт - вне контекста |
| Промежуточные результаты | Накапливаются в контексте | Обрабатываются в коде |
| Масштабируемость | Деградирует при сотнях инструментов | Отличная |
Tool Search переводит MCP в режим, близкий к Skills по потреблению токенов при загрузке - но выполнение tool calls всё равно остаётся в контексте. Ryan Smith разобрал этот нюанс детально: Tool Search решает проблему инициализации, но не накопление результатов в длинных сессиях.
Anthropic описал паттерн Code Execution Approach для масштабных workflow: вместо прямых tool calls агент пишет код для вызова инструментов. Промежуточные результаты обрабатываются в коде, не в контексте - что снижает контекстный след операций с многими шагами.
Паттерн выглядит так:
Задача: получить данные по API GitHub
Без Code Execution: серия tool calls, результаты в контексте
С Code Execution: агент пишет скрипт → исполняет → возвращает итог
Контекст остаётся чистым. Особенно важно для долгих research-сессий, где без этого подхода накапливаемые результаты требуют постоянного compaction.
Гибридный паттерн: когда что использовать
Выбор между MCP и Skills - это вопрос context engineering, не технических ограничений.
Используйте Skills когда:
- Операция выполняется часто (более 5 раз за сессию)
- Результат нужно обработать в коде вне контекста
- Контекстное окно критично (длинные сессии, сложные задачи)
Используйте MCP когда:
- Нужна синхронная интеграция с внешней системой
- Инструменты используются редко
- Tool Search активен и удобство важнее
Моя рабочая стратегия: начинать с минимума серверов, отслеживать потребление через /doctor, частые операции переносить в Skills. На практике я перенёс git commits, file searches, стандартные трансформации в Skills - это операции, которые выполняю 10+ раз за сессию. Неиспользуемые серверы отключать через claude mcp remove [server-name].
Связь со структурой CLAUDE.md и модульной памятью проекта здесь прямая: навык, который переезжает из CLAUDE.md в отдельный skill-файл, получает то же преимущество lazy loading, что и MCP с Tool Search - только без самого MCP.
Мой стек: один MCP-сервер (exa) для веб-поиска - то, что Skills не делает нативно - и Skills для всего остального. Минимальная конфигурация, полный функционал, без постоянного контекстного налога.
Практические сценарии
Developer с большим числом MCP-серверов. Подключены GitHub, Playwright, браузерная автоматизация, несколько вспомогательных серверов - это легко 70-85 тысяч токенов на инструменты при старте. С Tool Search потребление падает автоматически. Следующий шаг - аудит: какие инструменты используются реально? Частые операции (git commit, file search, стандартные трансформации) переезжают в Skills. MCP остаётся только для редких, уникальных интеграций.
Долгая research-сессия. Я столкнулся с этим при работе над статьями серии о context engineering: web scraping через MCP накапливал результаты tool calls в контексте, сессия деградировала. Решение через Code Execution Approach: агент пишет скрипт для scraping вместо серии tool calls, результаты обрабатываются вне контекста. MCP остаётся для резервных поисков. Сессия при этом сохраняет чистоту контекста на порядок дольше.
Context Engineering-перспектива
MCP Tool Search - это реализация нескольких принципов из Six Pillars Framework одновременно:
- Visibility:
/doctorи/contextделают скрытый token tax видимым - Prioritization: Tool Search реализует lazy loading - в контекст попадает только то, что нужно сейчас
- Compression: Tool Search сжимает слой tool definitions так же, как compaction сжимает историю разговора
На уровне архитектуры - четыре слоя контекстного окна, где MCP-инструменты занимают четвёртый. Tool Search переводит этот слой из режима «всегда загружен» в режим «динамически загружаемый». Архитектурный сдвиг, а не просто оптимизация. Подробнее о структуре слоёв - в статье «Как устроен контекст внутри».
Итог: аудит вашей конфигурации
Три шага для немедленного улучшения:
- Запустите
/doctor- посмотрите, сколько токенов потребляют ваши MCP-серверы прямо сейчас - Проверьте, какие серверы реально используются - неактивные отключить через
claude mcp remove - Перенесите частые операции в Skills - операции, которые выполняются многократно за сессию, дешевле как Skills
Tool Search исправил критическую архитектурную проблему MCP. Но это инструмент, а не отмена необходимости думать о контексте. Context engineering - это управление ограниченным ресурсом, и сознательный выбор между удобством и эффективностью остаётся за разработчиком.
Архитектура контекста перестаёт быть теорией, когда видишь числа в /doctor.