Проблема с MCP в том, что это относительно новая область, и пока нет очевидных лидеров даже среди самых базовых инструментов. Например, для самых основных задач — запуска команд в терминале или управления браузером — есть репозитории от разных авторов, предлагающие MCP-серверы с разным набором возможностей. Но они в основном еще довольно сырые и с разным набором багов. При этом репозитории с самым большим количеством звезд далеко не всегда оказываются лучшими или стабильными.

Чем больше, тем хуже

С ростом числа подключенных MCP-серверов (и, соответственно, инструментов) увеличивается размер системного промпта, который отправляется на вход. Если, например, подключить миллион серверов с миллионом инструментов, а разработчики еще и оставят подробные описания к каждому, это начнет сильно влиять на поведение агента. Он будет путаться, расходовать больше токенов, быстрее съедать лимиты и в целом вести себя нестабильно.

Как говорится, если у тебя есть молоток, все вокруг кажется гвоздем. Так и здесь: если у Клода есть инструмент, он старается его использовать при любом удобном (и не очень) случае. Поэтому я пришел к выводу, что огромное количество серверов и инструментов «на все случаи жизни» скорее навредит, чем поможет.

Кроме того, мне кажется, что для большинства задач достаточно единственного доступа к терминалу, потому что через bash можно сделать практически все.

Я пробовал использовать @modelcontextprotocol/server-memory, чтобы агент мог делать заметки и сохранять какие-то знания в базу. Но не зашло — Клод начинал слишком сильно менять свое поведение и даже документировал вещи, которые не нужно было фиксировать. А когда я просил его «запомни вот это», он, похоже, терялся в доступных инструментах и просто записывал данные в файл. В итоге я его отключил. А память через запись в файл, кстати, нормально работает, поскольку текстовый файл удобнее редактировать.

Отсутствие гибкости в настройке

Что больше всего расстраивает в текущей реализации MCP в Клоде (или в самом протоколе) — отсутствие возможности отключать ненужные инструменты, которые предоставляет сервер.

Например, @modelcontextprotocol/server-filesystem включает кучу тулов, но большая их часть особо не нужна. Просматривать папки или читать файлы можно и простыми Bash-командами. Единственная причина, почему я все еще держу этот сервер, — он умеет нормально заменять текст в файлах. А с этим у агента через bash бывает беда.

Или вот еще пример: доступ к браузеру. В целом, его можно реализовать через Chrome DevTools Protocol, подключаясь по WebSocket’ам, но это довольно замороченно. Тут полезны высокоуровневые библиотеки типа Playwright или Puppeteer. Проблема в том, что мой любимый MCP-сервер для этой задачи не умеет читать логи из консоли. Поэтому мне приходится дополнительно использовать другой MCP для DevTools. Но он слишком жирный и инжектит в промпт кучу ненужных тулов, которые оттягивают на себя контекст.

Оба сервера используют один и тот же протокол, и было бы круто, если бы можно было выбирать, какие инструменты подключать, а какие нет. Но пока такой опции нет.

Минимализм

В итоге я оставил себе минимальный набор MCP для базовых задач: — работа с файловой системой (Для редактирования файлов и поиска по ним) — управление браузером (для дебага UI и тестов) — поиск в интернете (через Google Search API, быстрее и удобнее, чем через браузер) — доступ к терминалу (для всего остального)

Этого пока хватает для большинства задач по разработке и дебагу.

В идеале хотелось бы, чтобы вся эта система пришла к философии Unix:

“Do one thing and do it well.”