Что вообще добавляет MCP к обычному чату с кодом
Model Context Protocol — это способ подключить языковую модель к внешним инструментам и данным через структурированные вызовы, а не через попытку впихнуть весь контекст в один текстовый промпт. Идея разумная: вместо того чтобы модель гадала по обрывкам файлов, она может явно запросить нужную операцию — прочитать файл, выполнить поиск, получить структуру проекта. Проблема в том, что большинство реализаций останавливается на этом минимуме. «Прочитать файл» и «найти по ключевому слову» — это функции, которые не сильно превосходят обычный копипаст кода в чат.
Автор разбора 28-инструментального MCP-сервера Spiderbrain формулирует вопрос точнее: не «сколько инструментов доступно», а «какие инструменты вообще нужны агенту для работы именно с кодовой базой». Это смещение важно, потому что контекстное окно модели и понимание архитектуры проекта — разные вещи. Модель может «видеть» тысячи строк кода и при этом не иметь ни малейшего представления, какие модули от каких зависят, какой файл почти никто не импортирует, но при этом его изменение сломает половину системы, и какие решения команда уже приняла и почему.
Три типа контекста, а не три десятка функций
В разборе Spiderbrain 28 инструментов сгруппированы в три функциональных блока, и это разделение полезнее самого числа:
- Инструменты кодовой базы (17) — структурные запросы, на которые плоское контекстное окно ответить не может: какой у изменения «blast radius» (радиус поражения — какие модули пострадают), где скрытые узкие места, как код группируется в смысловые кластеры, а не по папкам.
- Инструменты памяти (9) — доступ к «дереву памяти» проекта: накопленным решениям и ограничениям, которые сохраняются между сессиями, а не исчезают при каждом новом чате.
- Инструменты blueprint (2) — чтение и предложенная правка визуальной схемы архитектуры, причём правка требует подтверждения человеком.
Соседний блог того же проекта проговаривает это чуть иначе: структурный граф отвечает на вопрос «что от чего зависит и что сломается», дерево памяти хранит «почему мы так решили», а blueprint даёт явное, а не текстовое, представление системы — прозаический промпт описывает архитектуру, канвас её показывает. Это три разных типа информации, и путать их — значит терять смысл всей затеи. Инструмент, который отвечает на вопрос «что зависит от этого файла», бесполезен там, где агенту нужно вспомнить, почему полгода назад команда отказалась от определённого паттерна.
Когда какой инструмент действительно нужен
Ключевая мысль источника в том, что дергать все 28 инструментов на каждом шаге — это шум, а не контекст. Разработчик приводит практическую таблицу привязки: не к типу данных, а к моменту рабочего процесса — «новый проект», «перед правкой», «начало сессии», «рефакторинг», «онбординг». Это моменты, которые агент или человек реально проживают, в отличие от абстрактных «получить узел», «получить ребро» — операций базы данных, переодетых в костюм инструмента.
Если собрать эти моменты в одну картину, получается примерно такая карта соответствий:
| Рабочий момент | Что нужно агенту | Тип инструмента |
|---|---|---|
| Старт нового проекта / онбординг | Общая карта архитектуры, кластеры, ключевые узлы | Структурный граф (кодовые инструменты) |
| Перед правкой файла | Кто вызывает этот код, что сломается при изменении | Blast radius / impact-анализ |
| Начало новой сессии | Что уже решено, какие ограничения действуют | Память проекта |
| Рефакторинг | Границы модулей, скрытые связи, «слепые пятна» | Community detection, структурный анализ |
| Обсуждение архитектурного решения | Явная схема системы, а не пересказ прозой | Blueprint / canvas |
Таблица не доказывает, что именно эти 28 инструментов оптимальны — она показывает логику, которая должна стоять за любым набором. Инструмент без привязки к моменту — это функция, которая либо простаивает, либо вызывается вслепую. Протокол MCP сознательно не диктует, как именно клиент должен взаимодействовать с инструментами: они модельно-управляемы, но сам стандарт не навязывает единый паттерн вызова. Это развязывает руки разработчикам серверов — и одновременно перекладывает на них всю ответственность за то, будет ли выбор инструмента осмысленным или хаотичным.
Сходный паттерн у соседей, разные акценты
Spiderbrain не единственный, кто ставит на структурный граф вместо плоского чтения файлов. Проект codebase-memory-mcp индексирует кодовую базу в постоянный граф знаний и заявляет резкое сокращение количества токенов и вызовов инструментов по сравнению с построчным просмотром файлов, ссылаясь на собственный препринт с оценкой на 31 репозитории. Другой проект, code-review-graph, строит граф через tree-sitter специально под задачи ревью и публикует методологию бенчмарков открыто — вплоть до признания, что часто цитируемое ускорение в 528 раз является максимумом на одном лучшем репозитории, а медианное значение по шести проектам куда скромнее — около 82 раз.
Это важное уточнение. Оба проекта подтверждают саму архитектурную идею: агенту выгоднее работать с графом зависимостей и точечными запросами, чем перечитывать весь код заново на каждый вопрос. Но конкретные цифры — миллисекундные запросы, «99% меньше токенов», «2.1× меньше вызовов инструментов» — получены в конкретных условиях тестирования, с конкретной методологией и на конкретном наборе репозиториев. Переносить их на любой проект без проверки — это как поверить рекламе автомобиля «0 до 100 за три секунды» и ожидать того же результата на грунтовой дороге с прицепом.
Здесь и проходит граница между тем, что можно спокойно принять как объяснение механики, и тем, что стоит воспринимать как заявление разработчиков, требующее отдельной проверки:
| Тип утверждения | Пример | Как относиться |
|---|---|---|
| Описание механики / архитектуры | Граф зависимостей вычисляет blast radius изменения | Можно использовать как объяснение принципа |
| Протокольные факты | Инструменты в MCP модельно-управляемы, интерфейс не задан жёстко | Достаточно надёжно, это спецификация |
| Локальные benchmark-цифры с методологией | Медианное сокращение токенов ~82× на 6 репозиториях | Годится как иллюстрация, не как универсальный факт |
| Промо-метрики без независимой проверки | «Миллисекундные запросы», «99% меньше токенов» на одном продукте | Пересказывать только с оговоркой на источник |
| Заявления о превосходстве над альтернативами | «Наш подход лучше всех» | Требует отдельного независимого сравнения, которого пока нет |
Как на самом деле оценивать такой MCP-сервер
Из всего этого вытекает довольно приземлённый критерий. Хороший MCP-слой для работы с кодом не тот, у которого больше команд в списке, а тот, который умеет вовремя достать нужный тип контекста: структуру перед правкой, память в начале сессии, явную схему при споре об архитектуре. Инструмент, который никогда не вызывается не в тему, полезнее десятка инструментов, вызываемых наугад.
Это не означает, что подход Spiderbrain или его соседей доказанно превосходит альтернативы — независимых сравнений разных MCP-серверов для кодового ассистента, судя по доступным материалам, пока не существует, а собственные бенчмарки продуктов измеряют разные вещи разными методами. И не означает, что один и тот же набор инструментов одинаково пригодится маленькому стартап-репозиторию и монолиту с сотнями сервисов — момент онбординга в них выглядит совсем по-разному.
Но принцип, который стоит забрать из этого разбора, устойчивее любой конкретной реализации: проектировать инструменты MCP имеет смысл вокруг рабочих ситуаций, а не вокруг структуры данных. Число 28 — это деталь конкретного продукта. Логика «какой контекст нужен именно сейчас» — это то, что действительно решает, станет ли AI-ассистент полезнее или просто получит более длинное меню, которым никто толком не пользуется.
