MCP-серверы съедают контекст до первого промпта: скрытая цена «толстого» набора tools у агента

Редакция 12 ноября 2026 г.

Три расклада: жирный MCP, узкий micro-MCP или обход без схем в контексте. Для соло в редакторе с агентом решающий фактор — сколько токенов уходит на каталог tools до кода и трассировки. Наращивать MCP «на всякий случай» бьёт по рассуждению LLM и по счёту API, даже когда диалог пуст.

Почему хост тащит все schemas на каждый ход агента

MCP tools не работают «в фоне», пока вы печатаете промпт. На каждый запрос к модели хост кладёт в system context полные JSON Schema всех зарегистрированных tools: так устроены Anthropic Tool Use и OpenAI Function Calling. Автор поста на Dev.to называет это schema bloat: типичный third-party MCP по GitHub или облаку раздувается до десятков tools с длинными description, вложенным inputSchema и примерами в полях. Одна только схема вроде search_project_issues_advanced в его примере оценивается примерно в 180–220 токенов.

В иллюстративной смете автора четыре кластера MCP (GitHub, issue/docs, БД и observability, browser/FS/git) суммарно дают порядка 25 000 токенов до первого пользовательского вопроса. Это модельная раскладка, не замер в рантайме, но логика для агентного цикла жёсткая: многошаговый loop умножает давление схем; даже если prompt caching сглаживает долларовую строку, шум в внимании модели остаётся.

Три сбоя reasoning, которые не лечатся «ещё одним MCP»

Когда tools перекрываются по смыслу (read_file, get_file_contents и десятки соседей), растут tool selection hallucinations: неверный выбор, путаница параметров, retry после validation. Параллельно токены на ненужные описания конкурируют с кодом и правилами в контексте (attention dilution, эффект «lost in the middle»). Третий слой, «болтливые» tools: монолитный ответ API может залить контекст сырым JSON; в примере автора порядка 15 000 токенов метаданных вместо короткого статуса.

Для vibe-coding сценария это не абстрактная оптимизация. Агент с семью MCP (GitHub, Jira, Postgres, Sentry, Slack, Docker, filesystem) на двухсловном промпте «Run tests» уже платит тяжёлый вход: 28 400 input tokens при пустой истории и без прикреплённых файлов, то есть около 15% активного context window, и всё это до первого символа ответа модели. Это self-reported эпизод из поста, не независимый бенчмарк.

Сравнение «всё подключить» и узкого набора (данные автора)

Автор прогнал профиль «connect everything» против stripped-down workflow на 50 отладочных сессиях и свёл результат в таблицу. Это self-reported сравнение, не industry standard, но направление внятное:

Метрика	Монолитный MCP (52 tools)	Узкие micro-tools (4 tools)
Baseline schema overhead (ход 1)	24 600 tokens	640 tokens
След 10-шагового agent loop	246 000 tokens	6 400 tokens
Точность выбора tool с первой попытки	78%	99%
Средний TTFT	3,4 с	1,1 с

В том же тексте описан TypeScript-аудитор audit-tools.ts: оценка footprint сериализованных схем (~3,6 символа на токен для JSON), поля estimatedTokensPerTurn и сравнение 45 enterprise tools против одного micro-tool. Запуск: node --experimental-strip-types audit-tools.ts (Node 22.6+) или node audit-tools.ts (Node 23.6+).

Вывод автора сформулирован жёстко: мощность агента не в числе подключённых MCP, а в том, сколько «чистого» контекста остаётся под reasoning.

Micro-tools, узкая поверхность и pre-flight в IDE

Практический контраргумент в источнике: вместо отказа от MCP разумнее сузить поверхность:

Focused CLI: пример scripts/pr-summary.ts (~40 строк), gh pr view с узким --json, в stdout только title, state, краткое тело и список файлов с +/- строками.
«Narrow waist» MCP: один–два read-only tools вместо CRUD-роя; короткие descriptions; truncate на границе handler, а не 50 KB payload в модель.
Матрица выбора: monolith MCP (в таблице автора upfront 5k–25k tokens схем), micro-MCP на 1–3 tools (300–800 tokens), zero-bloat TypeScript CLI или on-demand skills без схем до вызова shell.

Публичного репозитория с готовыми скриптами автор не даёт, только встроенные листинги и локальные имена файлов. Перенос на ваш стек потребует своей обёртки, но паттерн прозрачен: shell и узкий JSON дешевле для контекста, чем полный каталог облачного MCP.

Чеклист из поста без новых метрик, применим к любому AI coding agent (в тексте generic «editor», без привязки к конкретному бренду):

Отключить глобальные MCP, оставить session/project scope.
Держать активный набор tools в коридоре 15–20, не десятки «на будущее».
Вырубить write/destructive endpoints, если задача read/debug.
Заменить «chatty» MCP на лёгкий TS CLI там, где хватает одной команды.

Закрывающий вопрос автора к читателю: сколько MCP tools реально активно в редакторе; для соло это хороший триггер аудита, прежде чем снова жать «Run tests» и удивляться счёту API.

Источники

Johnnylemonny (necoz), «Your MCP Servers Are Silently Draining Your Context Window: The Hidden Cost of Tool-Heavy AI Agents», Dev.to, 12 ноября 2026: Dev.to (доступ 2026-11-12, UTC).