Ваша LLM задыхается от вашего кода? Пора дать ей кислородную маску
Случалось ли вам впихнуть в контекстную память своей локальной модели вроде Llama 3.3 70B или свежего Qwen 2.5-Coder 32B всю папку с проектом? Потом два часа ждать ответа, а в итоге получить бессвязный бред про «синтаксические деревья» и «оптимальные парадигмы». Знакомое чувство бессилия.
Проблема не в том, что модели тупые. Проблема в том, что мы кормим их сырым текстом, как в статье «Когда промпт длиннее мозга». Код – это не плоский текст. Это структура, зависимости, вызовы функций. И есть инструмент, который это понимает.
Что делает этот MCP-сервер? Превращает ваш код в карту метро
Вместо того чтобы скармливать LLM мегабайты исходников, этот сервер делает три вещи:
- Парсит код с помощью tree-sitter (актуальная версия на 03.2026 – 0.22.6) для десятков языков. Он не просто читает текст, а понимает синтаксическое дерево: где функция, где класс, где импорт.
- Строит граф знаний в SQLite. Узлы – сущности (функции, классы, переменные). Ребра – связи (вызывает, наследует, импортирует). Получается навигационная карта всей кодовой базы.
- Сжимает запросы. Когда вы спрашиваете «как работает функция X?», сервер не отправляет весь файл, а находит в графе эту функцию, ее вызовы и зависимости, упаковывает это в структурированный JSON. Объем данных падает в среднем в 120 раз.
120x – это не маркетинг. Это бенчмарк на реальных проектах: репозиторий в 50 тыс. строк кода при прямом индексировании съедал ~150k токенов. После обработки графом для типового запроса о конкретном модуле нужно 1.2-1.5k токенов. Разница – два порядка.
Важный нюанс: сжатие работает идеально для структурных запросов (поиск функций, анализ зависимостей). Но если ваша LLM должна редактировать код «по стилю» или искать сложные логические баги, ей все еще может понадобиться полный контекст. Инструмент не волшебная таблетка, а очень острый скальпель.
А другие MCP для кода? Они все такие же?
Нет. И вот где собака зарыта.
- Простой файловый MCP (который идет в комплекте с многими клиентами) – это как дать LLM доступ к проводнику. Она видит файлы, может их читать. Никакой структуры. Для вопроса «где используется этот метод?» она будет линейно читать все файлы подряд, пока контекст не закончится.
- Code-memory (о котором мы уже писали) – умнее. Он использует эмбеддинги и векторный поиск для семантического поиска по коду. Хорош для поиска по смыслу, но плохо понимает жесткие синтаксические связи. Спросите «какие аргументы принимает эта функция?», и он может найти похожие функции, но не гарантирует точность.
- Наш графовый сервер – это другой уровень. Он знает точную структуру. Запрос «покажи все места, где функция save_user() вызывает validate_email()» выполняется одним запросом к SQLite. Это не поиск по сходству, а навигация по жестким связям, как в IDE.
| Подход | Сильная сторона | Слабая сторона | Потребление токенов (пример) |
|---|---|---|---|
| Файловый MCP | Простота, доступ к любым файлам | Нет понимания структуры кода | ~150k для среднего проекта |
| Векторный поиск (Code-memory) | Семантический поиск, «находит похожее» | Неточность в синтаксических деталях | ~10-20k на запрос |
| Граф знаний (этот сервер) | Точные структурные связи, минимальный контекст | Требует парсинга и построения графа | ~1.2k на запрос (120x сокращение) |
Как это выглядит на практике? Диалог с кодом, а не борьба с ним
Вы подключаете сервер к своему MCP-клиенту (скажем, в Cursor или через Hangar). Первый запуск – он индексирует проект, строит граф. Дальше вы просто общаетесь.
Ваш промпт: «Найди все SQL-запросы в коде, которые не используют параметризацию, и покажи, в каких функциях они находятся.»
Старый способ: LLM получает 20 файлов по 500 строк, пытается найти паттерны, путается, в конце концов выдает список с ошибками. Контекст переполнен, токены потрачены.
Новый способ: MCP-сервер принимает промпт, разбирает его на структурные элементы (находит в графе узлы типа «функция», ищет в их теле строки, похожие на SQL, фильтрует по отсутствию плейсхолдеров). Отдает LLM компактный JSON: список из 5 функций, их имена, файлы, и конкретные строки кода с уязвимостями. LLM не тратит силы на поиск – она только анализирует готовую выжимку и формулирует ответ.
Это меняет правила игры для автоматизации. Зачем писать сложные скрипты на Python, если можно просто попросить LLM через MCP? Об этом же речь в статье «Как я выбросил Ansible и Jenkins в окно».
Кому резко нужен этот инструмент? (А кому можно подождать)
Бегите устанавливать, если вы:
- Разрабатываете на локальных LLM (Llama, Qwen, DeepSeek-Coder) и устали от лимита в 8k/32k контекста. Сервер даст вашей модели «дыхание» для работы с большими проектами.
- Строите внутренние AI-инструменты для компании, где кодовая база – священная корова, а доступ в облако к GPT-4o или Claude 3.5 Sonnet запрещен. Локальность и структурирование – ваши лучшие друзья. Тут пригодится и наш гайд по развертыванию за бетонной стеной.
- Аналитик кода или техлид, которому нужно постоянно исследовать зависимости, искать «кто вызывает этот deprecated метод». Графовый поиск быстрее и точнее grep.
Можете пока отложить, если:
- Ваш проект – это 5 файлов на Python. Переплата за сложность не стоит экономии 1000 токенов.
- Вы работаете исключительно с бинарными или проприетарными форматами (типа тех же чертежей КОМПАС-3D, для которых нужен специализированный MCP-сервер). Tree-sitter их не поймет.
- Вы фанат чистого RAG и верите только в векторный поиск. Тогда сначала изучите MCP Tool Registry, чтобы увидеть всю экосистему.
Что дальше? Графы съедят мир (по крайней мере, мир кода)
Тренд 2025-2026 годов очевиден: плоский контекст умер. Будущее за гибридными системами, где графы знаний, векторные базы и онтологии работают вместе, чтобы дать LLM не сырые данные, а препарированные смыслы.
Следующий логичный шаг для такого MCP-сервера – научиться инкрементально обновлять граф при изменении кода и связать его с графом тикетов из Jira или коммитов из Git. Тогда можно будет спрашивать: «Покажи, какие функции были изменены для исправления бага PROJ-123, и какие тесты их покрывают?» – и получать ответ за секунды, а не за часы ручного расследования.
Если вы только начинаете путь с локальным ИИ, не пугайтесь сложности. Начните с построения базового сервера или даже запуска на старом железе. А потом подключайте такие специализированные инструменты. Они превращают LLM из болтливого чат-бота в настоящего инженера с фотографической памятью и мгновенной реакцией.
И да, 120x – это только начало. Держитесь.
