cpp-analysis-mcp

MCP-сервер, который позволяет агентам ИИ, пишущим код, действительно тестировать код на C++, а не просто читать его.

Проблема

Некоторые ошибки в C++ невидимы в исходном коде. Выглядит нормально:

void deposit(int amt) {
    balance += amt;   // no lock
}

Запустите его из 100 потоков — и он потеряет обновления. Ошибка живёт во времени выполнения, а не в тексте, поэтому ИИ, который только читает файл, назовёт его чистым.

Инструменты, которые ловят такие ошибки, уже существуют и отлично работают. Это просто программы командной строки, к которым не подключён ни один ИИ-ассистент. Этот проект и есть то самое подключение.

Related MCP server: cpp-semantic-graph

Что он делает

Восемь инструментов, три вопроса:

Агент начинает с дешёвых проверок и переходит к более дорогим, только когда это необходимо. Восьмой инструмент, capabilities, сообщает, что реально может запустить эта машина.

Под капотом: ThreadSanitizer — для гонок данных, AddressSanitizer — для повреждения памяти, LeakSanitizer — для утечек, UBSan — для неопределённого поведения, clang-tidy и -Wthread-safety — на этапе компиляции, а perf — для профилирования.

Поддержка платформ

В Windows сервер сам находит дистрибутив WSL и направляет через него инструменты, предназначенные только для Linux. Вы по-прежнему передаёте обычные C:\ пути. Если что-то не может запуститься, сервер прямо говорит об этом и называет команду, которая это исправит.

Настройка

Вам понадобятся Python 3.11+, uv и компилятор C++ (clang или gcc).

git clone https://github.com/GusDawn123/cpp-analysis-mcp
cd cpp-analysis-mcp
uv sync

Затем зарегистрируйте его в своём агенте. Для Claude Code:

claude mcp add cpp-analysis -- uv run --directory <path-to-repo> cpp-analysis-mcp

Для любого другого MCP-клиента добавьте ту же команду в его конфигурационный файл:

{ "mcpServers": { "cpp-analysis": {
    "command": "uv",
    "args": ["run", "--directory", "<path-to-repo>", "cpp-analysis-mcp"]
}}}

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

Почему можно доверять пустому результату

Сервер никогда не верит инструменту на слово. При запуске он внедряет настоящую ошибку (гонку данных, утечку, переполнение) и требует, чтобы каждый детектор её поймал. Детектор, который не реагирует на известную ошибку, помечается как недоступный, с указанием причины и команды установки, которая это исправляет.

Таким образом, пустой отчёт означает, что детектор, который, как доказано, работает здесь, ничего не увидел. Эта разница важна, потому что молча сломанный инструмент выглядит точно так же, как чистый код.

Архитектура

your AI agent (Claude Code, Cursor, anything that speaks MCP)
        |
    server.py        eight tools, no logic of its own
        |
    pipelines/       the recipes: check, sanitize, profile
        |
   +----------+-------------+
   |          |             |
 build/    process.py    parsers/
 compiles  runs tools    raw tool output in,
 the code  safely, with  clean findings out
   |       timeouts
   |
   +-- platforms/    what Linux, macOS, and Windows each need
   +-- toolchains/   what clang and gcc each need
   +-- wsl.py        Windows borrowing Linux for what it lacks

Правила слоёв обеспечиваются тестами, которые разбирают дерево исходников, поэтому они не могут устареть: server.py не содержит управляющей логики, только process.py может запускать дочерний процесс, парсеры никогда не обращаются к файлам, и ровно один модуль может определять, что это за машина.

Тесты

507 модульных тестов запускаются где угодно, компилятор не нужен. Интеграционные тесты компилируют и запускают фикстуры с внедрёнными ошибками, а эталонные результаты, полученные на Linux, macOS и Windows, не позволяют парсерам отклоняться от истины.

make test

Лицензия

MIT