Широко цитируемая оценка в 42 000–55 000 токенов для GitHub MCP оказалась одновременно завышенной и направленной не туда. Замер через родной токенизатор Claude (count_tokens) даёт другие цифры: дефолтный набор из 43 инструментов занимает 10 928 токенов, полный из 82 — 20 404 токена. Расхождение объясняется тем, что исходная оценка считала 93 инструмента, включала инструкции сервера и обёртку клиента, а метод измерения не был указан. Это не ошибка, а другой охват — но без этой оговорки цифра вводит в заблуждение.
Контекстное окно современных LLM — ограниченный ресурс, который агент расходует одновременно на несколько статей: системные инструкции, историю диалога, описания инструментов (схемы) и их ответы. MCP (Model Context Protocol) — протокол, разработанный Anthropic, который стандартизирует способ подключения внешних инструментов к языковой модели. Каждый MCP-сервер передаёт модели список своих инструментов через вызов tools/list, и эти описания присутствуют в каждом запросе к API — модель должна их видеть, чтобы знать, что можно вызвать.
| MCP-сервер | Инструментов | Токенов (схема) | % окна 200K |
|---|---|---|---|
| Playwright | 23 | 4 633 | 2,3% |
| GitHub — дефолтный toolset | 43 | 10 928 | 5,5% |
| GitHub — все toolset'ы | 82 | 20 404 | 10,2% |
| Azure | 65 | 18 983 | 9,5% |
Главный вывод замеров — не в абсолютных числах схем, а в сравнении двух типов расхода. Схемы — это разовый налог: их загружают один раз при старте сессии, и дальше они просто лежат в контексте. Ответы инструментов — рекуррентный налог: каждый вызов добавляет новый блок, и он остаётся в окне до конца сессии. Один вызов browser_snapshot у Playwright MCP — снимок accessibility-дерева одной страницы GitHub — занимает 38 831 токен, то есть 19,4% двухсоттысячного окна за один ход. Это примерно в 8 раз больше, чем вся схема Playwright (4 633 токена). При нескольких последовательных вызовах контекст заполняется быстро вне зависимости от того, насколько компактны схемы.
Один вызов browser_snapshot у Playwright MCP возвращает 38 831 токен — в 8 раз больше всей схемы Playwright.
Отсюда следует практический вывод для разработчиков агентов: ленивая загрузка инструментов и механизмы search_tools, которые обычно предлагают как способ сэкономить контекст, работают только с разовой стоимостью схем. Рекуррентный расход они не затрагивают. Реальный рычаг оптимизации — на стороне ответов: пагинация, усечение, суммаризация результатов до того, как они попадают в окно.
Для воспроизводимости замеров важен выбор токенизатора. Сравнение офлайн-оценщика o200k (используется в библиотеке tiktoken) с официальным count_tokens показало систематическое расхождение: схемы занижаются на 16–43%, а большой ответ-снимок, наоборот, завышается примерно на 7%. Для числа, на которое потом ориентируются при проектировании агента, такая погрешность существенна.
Автор материала опубликовал инструмент ContextTax — однофайловый CLI под лицензией MIT для macOS, Linux и Windows. Он подключается к живому MCP-серверу из конфига, считает стоимость схем через count_tokens и принимает произвольный ответ инструмента через пайп. Есть офлайн-режим с o200k-оценкой, который явно помечает результат как приближённый. Репозиторий доступен на GitHub по адресу github.com/PavelTkachenk0/ContextTax.