--- title: "MCP и скрытый «токен-налог» серверов" description: "Каждый подключённый MCP-сервер — невидимый налог на контекст. GitHub MCP = 46K токенов. Разбираем механизм, решение через Tool Search и архитектурный выбор между MCP и Skills." url: "https://ifonin.ru/blog/mcp-skrytyy-token-nalog-serverov/" date: 2026-03-04 tags: ["claude-code","context-engineering","mcp","skills","token-optimization"] --- # MCP и скрытый «токен-налог» серверов Вы подключили GitHub MCP и ещё несколько серверов. Кажется удобно. Но до первого сообщения модель уже потратила больше 100 килотокенов на определения инструментов. Это скрытый налог - token tax - который почти никто не замечает, пока контекстное окно не переполняется. Один только GitHub MCP потребляет около 46-55 тысяч токенов. Просто за факт подключения, ещё до единого вопроса. Добавьте Playwright (около 13 600 в моей конфигурации), omnisearch (около 14 100) - и вот уже 50-70% context window уходит в никуда на старте сессии. В этой статье разбираем механизм проблемы, решение, которое появилось в январе 2026, и архитектурный выбор между MCP и Skills. --- ## Масштаб проблемы Разработчик Scott Spence [задокументировал](https://scottspence.com/posts/optimising-mcp-server-context-usage-in-claude-code), что при стандартной рабочей конфигурации модель тратит более 66 000 токенов ещё до первого пользовательского сообщения. Joe Njenga [зафиксировал аналогичную ситуацию](https://medium.com/@joe.njenga/claude-code-just-cut-mcp-context-bloat-by-46-9-51k-tokens-down-to-8-5k-with-new-tool-search-ddf9e905f734): четыре MCP-сервера потребляли 51 000 токенов сразу при инициализации сессии. Это не аномалии. Нормальное поведение архитектуры MCP. Команда `/doctor` в Claude Code позволяет увидеть этот налог напрямую. Инструмент выдаёт предупреждение, когда MCP-инструменты занимают более 25 000 токенов. Я запускаю `/doctor` после каждого изменения конфигурации - и каждый раз удивляюсь, насколько велики цифры у разработчиков, которые добавляли серверы без учёта этой стоимости. Почему это происходит - объясняет архитектура контекстного окна. MCP-инструменты занимают отдельный слой контекста, который загружается автоматически при подключении сервера, независимо от того, используются ли инструменты в текущей сессии. Подробнее о четырёхслойной архитектуре - в статье [«Как устроен контекст внутри»](/blog/kak-ustroen-kontekst-vnutri/). Я использую только один MCP-сервер - exa для веб-поиска. Не ограничение. Осознанный архитектурный выбор. --- ## Механизм потребления Когда вы подключаете MCP-сервер, Claude Code загружает в контекст определения всех его инструментов одновременно. Каждое определение включает имя, описание и полную JSON Schema параметров. Для GitHub MCP это 91 инструмент с полными схемами. Главная проблема: эти определения остаются в контексте на протяжении всей сессии. Они не сжимаются через [compaction](/blog/compaction-tryokhsloynaya-sistema-szhati/) - систему сжатия, которая работает с историей переписки. Tool definitions существуют в отдельном слое, и compaction их не затрагивает. **Skills работают принципиально иначе.** Они загружаются только при явном вызове. Скрипт выполняется вне контекстного окна, промежуточные результаты обрабатываются в коде - не накапливаются в контексте. On-demand context injection в чистом виде. По наблюдениям сообщества и опубликованным [бенчмаркам Anthropic](https://www.anthropic.com/engineering/code-execution-with-mcp), 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 [задокументировал](https://www.candede.com/articles/claude-tool-search) снижение до 95%+ при аналогичных конфигурациях с GitHub MCP. Это не оптимизация - смена архитектурного паттерна. Simon Willison из проекта Datasette [публично высказался](https://www.atcyrus.com/stories/mcp-tool-search-claude-code-context-pollution-guide) о том, что загрязнение контекста было главной причиной, по которой он избегал MCP. Tool Search снял это препятствие. **Как включить.** Tool Search активируется автоматически, когда MCP-инструменты превышают 10% контекстного окна. Можно также включить явно через параметр `enable_tool_search` в конфигурации. Проверить эффективность - командой `/doctor`. После выпуска Tool Search главное техническое ограничение на множественные MCP-серверы исчезло. Но это не повод подключать всё подряд - это свобода осознанного выбора. Понимание [context engineering как парадигмы](/blog/context-engineering-novaya-paradigma/) остаётся важным: Tool Search снижает налог, но не отменяет необходимость проектировать контекст осознанно. --- ## Skills vs MCP: архитектурное сравнение С появлением Tool Search выбор между Skills и MCP стал практическим, а не вынужденным. Ключевые параметры: | Аспект | MCP | Skills | |--------|-----|--------| | Загрузка определений | Все сразу в контекст | Только при вызове | | Выполнение | Tool call - в контексте | Скрипт - вне контекста | | Промежуточные результаты | Накапливаются в контексте | Обрабатываются в коде | | Масштабируемость | Деградирует при сотнях инструментов | Отличная | Tool Search переводит MCP в режим, близкий к Skills по потреблению токенов при загрузке - но выполнение tool calls всё равно остаётся в контексте. Ryan Smith [разобрал этот нюанс детально](https://smithhorngroup.substack.com/p/the-hidden-token-tax-of-mcp-servers): Tool Search решает проблему инициализации, но не накопление результатов в длинных сессиях. Anthropic описал паттерн Code Execution Approach для масштабных workflow: вместо прямых tool calls агент пишет код для вызова инструментов. Промежуточные результаты обрабатываются в коде, не в контексте - что снижает контекстный след операций с многими шагами. Паттерн выглядит так: ``` Задача: получить данные по API GitHub Без Code Execution: серия tool calls, результаты в контексте С Code Execution: агент пишет скрипт → исполняет → возвращает итог ``` Контекст остаётся чистым. Особенно важно для долгих research-сессий, где без этого подхода накапливаемые результаты требуют постоянного [compaction](/blog/compaction-tryokhsloynaya-sistema-szhati/). --- ## Гибридный паттерн: когда что использовать Выбор между MCP и Skills - это вопрос context engineering, не технических ограничений. **Используйте Skills когда:** - Операция выполняется часто (более 5 раз за сессию) - Результат нужно обработать в коде вне контекста - Контекстное окно критично (длинные сессии, сложные задачи) **Используйте MCP когда:** - Нужна синхронная интеграция с внешней системой - Инструменты используются редко - Tool Search активен и удобство важнее Моя рабочая стратегия: начинать с минимума серверов, отслеживать потребление через `/doctor`, частые операции переносить в Skills. На практике я перенёс git commits, file searches, стандартные трансформации в Skills - это операции, которые выполняю 10+ раз за сессию. Неиспользуемые серверы отключать через `claude mcp remove [server-name]`. Связь со структурой [CLAUDE.md и модульной памятью проекта](/blog/claudemd-persistentnaya-pamyat-proekta/) здесь прямая: навык, который переезжает из 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](/blog/context-engineering-novaya-paradigma/) одновременно: - **Visibility:** `/doctor` и `/context` делают скрытый token tax видимым - **Prioritization:** Tool Search реализует lazy loading - в контекст попадает только то, что нужно сейчас - **Compression:** Tool Search сжимает слой tool definitions так же, как compaction сжимает историю разговора На уровне архитектуры - четыре слоя контекстного окна, где MCP-инструменты занимают четвёртый. Tool Search переводит этот слой из режима «всегда загружен» в режим «динамически загружаемый». Архитектурный сдвиг, а не просто оптимизация. Подробнее о структуре слоёв - в статье [«Как устроен контекст внутри»](/blog/kak-ustroen-kontekst-vnutri/). --- ## Итог: аудит вашей конфигурации Три шага для немедленного улучшения: 1. **Запустите `/doctor`** - посмотрите, сколько токенов потребляют ваши MCP-серверы прямо сейчас 2. **Проверьте, какие серверы реально используются** - неактивные отключить через `claude mcp remove` 3. **Перенесите частые операции в Skills** - операции, которые выполняются многократно за сессию, дешевле как Skills Tool Search исправил критическую архитектурную проблему MCP. Но это инструмент, а не отмена необходимости думать о контексте. Context engineering - это управление ограниченным ресурсом, и сознательный выбор между удобством и эффективностью остаётся за разработчиком. Архитектура контекста перестаёт быть теорией, когда видишь числа в `/doctor`.