Я удалил 6 из 10 MCP в Claude Code. Стало лучше

Я удалил 6 из 10 MCP в Claude Code. Стало лучше

Месяц назад подключил 10 MCP-серверов к Claude Code: GitHub, Postgres, Slack, Notion - всё подряд. Контекст уехал на 60% ещё до первого вопроса.

В апреле я был уверен: чем больше MCP подключу, тем умнее станет Claude. Прочитал статью «топ-15 MCP-серверов для разработчика», поставил всё подряд - GitHub, Filesystem, Postgres, Slack, Notion, Sentry, Playwright, Linear, Stripe и ещё пару. Звучало как нашествие супер-сил.

Через неделю стало очевидно: Claude не стал умнее, он стал медленнее. Описания всех инструментов висели в контексте постоянно, занимали около 60% окна ещё ДО первого вопроса. Когда я писал «найди issue с лейблом bug», Claude иногда дёргал Filesystem вместо GitHub - имена tools пересекались, он терялся. А в одну ночь я чуть не уронил прод-БД смыслокода через Postgres-MCP, потому что забыл флаг --readonly.

После этой ночи я снёс 6 серверов из 10. Оставил 4. Поставил один shell-скрипт поверх Postgres. Включил Tool Search. Claude перестал тупить, контекст вернулся в норму, скорость работы стала примерно в два раза выше.

Расскажу как замерил перегруз через claude mcp list, какие 4 сервера оставил для бизнес-проекта, и как 12 строк на bash закрыли DROP TABLE через MCP. Цифры реальные, проверял на смыслокоде в апреле-мае.

Что такое MCP-cabinet и как замерить перегруз контекста

Я называю это «MCP-cabinet» - шкаф со старыми проводами, который ты собрал «на всякий случай» и забыл выбросить. Каждый MCP-сервер выгружает свой набор инструментов в контекст Claude. Один сервер - это в среднем 5-10 tools плюс описания resources и prompts. Десять серверов - это 50-100 инструментов, которые висят там, даже если ты ими сегодня не пользуешься.

Замерить просто, командой в терминале:

claude mcp list

В ответе будет список всех подключённых серверов и их scope (local, project, user). Чтобы увидеть инструменты конкретного сервера, открой сессию Claude Code и набери внутри:

/mcp

Увидишь полный список tools, их статусы и сколько активны прямо сейчас. Если их больше 40 - ты в зоне риска. Scott Spence замерил: Tool Search-режим в Claude Code режет расход контекста с 14 214 до 5 663 токенов на сессию. Это около 60% экономии. Замер взят на одной и той же задаче, разница только в режиме инструментов.

Главная мысль, которую я долго не мог принять: большинство проблем с Claude Code решается удалением лишнего сервера, а не добавлением нового. Каждый сервер платит контекстом за право висеть в твоей сессии. Если ты не пользовался им три дня - снеси и подключи обратно через две минуты, когда понадобится.

4 MCP-сервера которые я оставил после чистки

После недели наблюдений я понял, какие 4 связки реально работают каждый день, а какие лежат мёртвым грузом. Вот стек, на котором сижу сейчас.

Filesystem (stdio, scope local). Даёт Claude доступ к файлам вне текущего проекта. Я использую для архивов транскрипций эфиров и папки с дизайн-макетами. Подключение:

claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/me/projects /Users/me/Documents/transcripts

Указывай только конкретные папки, не корень диска. Это первая дыра в безопасности - если дашь корень, Claude теоретически может прочитать .ssh, ~/.aws и любые токены.

Postgres через DBHub (stdio, read-only). Подключение к прод-БД смыслокода для аналитики - какие участники зависли, по каким эфирам меньше комментариев. Только чтение. Команда такая:

claude mcp add postgres -- npx -y @bytebase/dbhub --dsn "postgresql://reader:****@db.smyslokod.ru:5432/main?sslmode=require" --readonly

Два правила, которые я для себя зафиксировал и нарушать не буду: отдельный пользователь БД с правами только на чтение и обезличивание персональных данных через VIEW. Email клиента не должен попадать в логи Anthropic - это нарушение 152-ФЗ.

GitHub MCP (HTTP через OAuth). Открывает Claude доступ к issues и pull request'ам. Подключение через HTTP, авторизация в три клика OAuth:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

Использую для «прочитай открытые issues, сгруппируй по компонентам, предложи в каком порядке закрывать» - Claude собирает приоритизированный список за минуту вместо моих 30 минут ручного триажа.

Playwright (stdio). Даёт Claude браузер. Открыть, кликнуть, заполнить, сделать скриншот. Незаменим для UI-проверки после публикации - «открой главную, проверь что баннер показывается, сделай скриншот мобильной версии».

claude mcp add playwright -- npx -y @playwright/mcp@latest

Что я убрал и почему:

  • Slack-MCP. Сводку лучше формирует обычный cron-скрипт, MCP здесь только лишняя нагрузка контекста.
  • Notion-MCP. Методология лежит в репозитории, не в Notion. Был подключён по инерции.
  • Sentry-MCP. Я не на проекте с большим потоком ошибок, смотрю Sentry раз в день вручную - MCP давал больше шума, чем пользы.
  • Linear-MCP, Stripe-MCP. Не использую эти сервисы. Подключал потому что они были в обзоре.
  • Дополнительный Filesystem на ~/Downloads. Дублировал основной.

Принцип, который я для себя выписал на стикер у монитора: сервер живёт у меня в mcp list, только если я пользовался им последние 48 часов. Иначе - claude mcp remove. Подключу за 30 секунд, когда снова понадобится.

Один shell-скрипт который закрыл DROP TABLE через MCP

Расскажу историю, которая меня отрезвила. В апреле я подключил Postgres-MCP к прод-БД смыслокода без флага --readonly и без allowlist-хука. Решил, что буду осторожен. Это типичная ловушка: тебе кажется, что ты профессионал, а Claude же тебе подчиняется.

Промпт был мирный: «удали тестовых пользователей за май, у которых email содержит test». Claude составил SQL:

DELETE FROM users WHERE email ILIKE '%test%';

И отправил. К счастью, на базе был включён триггер логирования всех DELETE. Я увидел строку, проверил выборку - под %test% попадало 47 настоящих участников, у которых «test» было частью домена или ника. Без триггера я бы потерял полсотни активных пользователей.

После этой ночи я сделал две вещи: пересоздал отдельного пользователя БД с правами только на чтение (теперь claude mcp add postgres -- ... --readonly) и поставил allowlist-хук. Хук перехватывает ЛЮБОЙ вызов MCP-инструмента до его выполнения и решает - пропустить или заблокировать. Конфиг кладётся в .claude/settings.json:

{ "hooks": { "PreToolUse": [ { "matcher": "mcp__postgres__.*", "hooks": [ { "type": "command", "command": ".claude/hooks/allowlist-mcp.sh" } ] } ] } }

Сам скрипт allowlist-mcp.sh - 12 строк. Читает входной JSON со stdin, проверяет SQL-запрос на разрушительные операции, отдаёт решение тем же JSON:

#!/bin/bash INPUT=$(cat) TOOL=$(echo "$INPUT" | jq -r '.tool_name') QUERY=$(echo "$INPUT" | jq -r '.tool_input.query // empty') if [[ "$QUERY" =~ ^[[:space:]]*(DROP|TRUNCATE|DELETE|ALTER|UPDATE) ]]; then echo '{"decision":"block","reason":"Разрушительные SQL-запросы заблокированы. Если уверен - дёрни через psql напрямую."}' exit 0 fi echo '{"decision":"approve"}'

Скрипт срабатывает на любые запросы, начинающиеся с DROP, TRUNCATE, DELETE, ALTER, UPDATE. Claude получает block и пишет в чат: «запрос заблокирован хуком, нужно подтверждение». Я смотрю, что он собирался сделать, и если правда нужно - запускаю руками через psql.

Что ещё стоит навесить на этот же шаблон:

  • Чтение .env через Filesystem MCP - блок.
  • Отправка сообщений в #general Slack без явного подтверждения - блок.
  • Любые операции с пометкой «write» на сервисах с критичной нагрузкой - блок.

Этот hook закрыл одну дыру. У меня про полную систему PreToolUse / PostToolUse / Stop лежит настройка PreToolUse-хука в Claude Code - 7 готовых рецептов под аудит, формат и автоматический коммит.

Когда MCP не нужен - иерархия по токенам

Самый большой ментальный сдвиг для меня был такой: MCP - это самый дорогой по токенам способ дать Claude внешнюю силу. Иногда оправдан, чаще нет.

Иерархия по расходу, от самого дешёвого к самому дорогому:

  1. CLI через Bash-tool. Почти бесплатно. Claude дёргает gh issue list, psql -c "SELECT ...", curl https://api..., pdftotext doc.pdf - и получает ответ как обычный пользователь терминала. Описания этих команд не висят в контексте - они вызываются по запросу.
  2. Skill. Дёшево. Готовый файл с инструкцией и шаблонами промптов в .claude/skills/. Загружается только когда триггерится по имени. Один файл = один сценарий: «собрать релиз-ноут», «написать письмо после стрима», «прогнать сценарий через чек-лист».
  3. Subagent. Средне. Отдельная сессия с собственным окном контекста для длинной задачи. Хорош когда нужно параллельно гонять две задачи в разные мозги.
  4. MCP-сервер. Дорого. Инструменты висят в контексте всю сессию, для HTTP-серверов ещё и OAuth-сессия. Полная цена платится каждый раз, когда ты запускаешь Claude Code.

Контр-интуитивный практический вывод: для парсинга PDF, работы с git, открытия архивов, обращения к open-source утилитам бери CLI, а не MCP. Я однажды пробовал «PDF-MCP» (один из ранних community-серверов) - снёс через два дня. pdftotext input.pdf - работает в 10 раз быстрее по токенам и не висит в контексте, когда не нужен.

MCP оправдан в двух случаях:

  • Сервис закрытый и требует OAuth/токена (Slack, Notion, Sentry, Linear). CLI-утилиты тоже есть, но через MCP тоньше - доступ ограничивается scope'ами на стороне сервиса.
  • Нужен живой двусторонний диалог: Claude зашёл в Postgres, посмотрел схему, задал уточняющий запрос, дёрнул следующий. Через CLI это превратилось бы в 10 ручных команд с промежуточным копированием.

Всё остальное - skill или CLI.

Tool Search: режим когда инструментов 40+

Если у тебя 4-5 MCP-серверов и общее число tools перевалило за 40 - включи Tool Search до того, как начнёшь чистку. Возможно, чистить не придётся. Режим работает так: Claude видит только короткое описание каждого инструмента и подгружает полное определение в контекст, когда реально собирается его вызвать.

Включается одной ENV-переменной:

export ENABLE_TOOL_SEARCH=auto

Доступные режимы:

  • false - старое поведение, все инструменты постоянно в контексте.
  • true - поиск всегда включён, даже если у тебя 5 tools.
  • auto - Claude сам решает, когда подгружать определения (обычно после ~40 tools).
  • auto:N - тот же auto, но с явным порогом N инструментов, после которого режим включается.

Для критичных tools, которые Claude должен видеть всегда (например, bash или какие-то ключевые операции в твоём workflow), есть флаг alwaysLoad: true в .mcp.json рядом с описанием сервера. Тогда этот конкретный сервер не уходит в Search-режим, остаётся в постоянном контексте.

У меня сейчас сценарий простой: 4 MCP + Tool Search в auto-режиме. Замер Scott Spence (14 214 → 5 663 токенов = 60%) я воспроизвёл на своих сессиях - получил похожий порядок: 55-60% в зависимости от задачи.

Tool Search закрывает только один сценарий потери контекста - перегруз MCP-инструментами. Остальные сценарии (раздутый CLAUDE.md, длинные транскрипты в истории, дубли скриншотов в диалоге, незакрытые subagent-сессии) живут своей жизнью. Про них у меня отдельно расписаны 9 паттернов потери токенов в Claude Code - с конкретными командами замера и тем, какой паттерн режется чем.

6 антипаттернов на которых я горел сам

Короткий список того, на что я наступал сам или видел у вайб-кодеров на менторских сессиях в первый месяц с MCP. Сверху вниз - по убыванию частоты.

  1. MCP-cabinet. Подключил 10 серверов «на всякий случай». Лечится командой claude mcp list и снятием того, чем не пользовался 48 часов.
  2. Write-доступ к прод-БД. Один промпт «удали тестовых» - и потерял боевые записи. Лечится тремя вещами одновременно: read-only пользователь БД, флаг --readonly, hook на разрушительные SQL.
  3. PII без обезличивания. Подключил БД с email и телефонами клиентов напрямую - данные попадают в логи Anthropic. Это 152-ФЗ. Лечится промежуточным VIEW или API-роутом с маской вроде j***@gmail.com.
  4. MCP вместо skill. «Отчёт по продажам в формате X» - однотипная задача, решается skill'ом. MCP здесь лишний расход контекста.
  5. MCP вместо CLI. «PDF-MCP», «git-MCP», «curl-MCP» - всё это решается обычными CLI-утилитами. Claude вызывает команды в терминале не хуже человека.
  6. Не контролировать токеновый счёт. Серверы видны в mcp list, но не видно сколько каждый сжёг. После недели у тебя нет понимания «MCP занял 40% контекста». Лечится аудитом раз в неделю и правилом «48 часов».

Замер Scott Spence по Tool Search, на который я опирался, лежит в его блоге (scottspence.com/posts/optimising-mcp-server-context-usage-in-claude-code).

Что я бы сделал на твоём месте

Если ты сейчас читаешь это с мыслью «у меня же тоже 8 серверов подключено» - вот четыре шага в порядке убыточности проблемы:

  1. Прямо сейчас открой терминал и запусти claude mcp list. Если в списке больше 5 серверов - смело сноси те, которые не дёргал последние 48 часов. claude mcp remove <name> снимает за секунду, подключить обратно займёт минуту, когда правда понадобится.
  2. Если у тебя в списке есть Postgres или другая БД с write-доступом - останови всё и сделай три правки одновременно. Отдельный пользователь БД на чтение, флаг --readonly при подключении, hook на DROP|TRUNCATE|DELETE|ALTER|UPDATE. Хук - 12 строк, скопируешь из этой статьи.
  3. Включи Tool Search в режиме auto. Одна строка в ~/.zshrc. Эффект увидишь в первой же сессии: ответы быстрее, контекст не съедается описаниями всех серверов.
  4. Для всего что решается одной CLI-командой - оставайся в CLI. Не плоди MCP-серверы под git, PDF, curl, jq, grep. Claude вызывает Bash-tool бесплатно по токенам.

Я ждал, что MCP-серверы станут как электрические розетки: воткнул и забыл. На деле они оказались как кабели за телевизором - чем больше навешал, тем сложнее найти нужный, и тем больше шансов, что один из них случайно дёрнет шнур питания.

А у тебя в claude mcp list сколько серверов? Если больше пяти - убери половину на один день и сравни ощущения. Расскажи в комментах какой сервер первым отлетит и почему.

2 комментария