cpp-analysis-mcp

Ein MCP-Server, der es KI-Coding-Agenten ermöglicht, C++-Code tatsächlich zu testen, anstatt ihn nur zu lesen.

Das Problem

Manche C++-Bugs sind im Quellcode unsichtbar. Das sieht gut aus:

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

Starte es mit 100 Threads und es verliert Updates. Der Bug liegt im Timing, nicht im Text, also wird ein KI-System, das nur die Datei liest, es als sauber bezeichnen.

Die Werkzeuge, die diese Bugs finden, existieren bereits und sind exzellent. Sie sind nur Kommandozeilenprogramme, mit denen kein KI-Assistent verbunden ist. Dieses Projekt ist diese Verbindung.

Related MCP server: cpp-semantic-graph

Was es tut

Acht Werkzeuge, drei Fragen:

Der Agent beginnt günstig und eskaliert nur, wenn es nötig ist. Das achte Werkzeug, capabilities, meldet, was diese Maschine wirklich ausführen kann.

Unter der Haube: ThreadSanitizer für Datenrennen, AddressSanitizer für Speicherkorruption, LeakSanitizer für Lecks, UBSan für undefiniertes Verhalten, clang-tidy und -Wthread-safety zur Compile-Zeit und perf für Profiling.

Plattformunterstützung

Unter Windows findet der Server selbstständig eine WSL-Distribution und leitet die Linux-only-Werkzeuge darüber. Du kannst weiterhin normale C:-Pfade verwenden. Wenn etwas nicht ausgeführt werden kann, sagt der Server das klar und nennt den Befehl, der es beheben würde.

Einrichtung

Du benötigst Python 3.11+, uv und einen C++-Compiler (clang oder gcc).

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

Dann registriere es bei deinem Agenten. Für Claude Code:

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

Für jeden anderen MCP-Client füge denselben Befehl zu dessen Konfigurationsdatei hinzu:

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

Der erste Start dauert eine Minute. Der Server kompiliert und führt für jede Analyse ein winziges fehlerhaftes Programm aus, um zu beweisen, dass das Werkzeug auf deiner Maschine wirklich funktioniert, und cached dann die Ergebnisse.

Warum du einem leeren Ergebnis vertrauen kannst

Der Server verlässt sich nie auf das Wort eines Werkzeugs. Beim Start pflanzt er einen echten Bug (ein Datenrennen, ein Leck, einen Überlauf) und verlangt, dass jeder Detektor ihn findet. Ein Detektor, der bei einem bekannten Bug still bleibt, wird als nicht verfügbar gemeldet, mit dem Grund und dem Installationsbefehl, der es behebt.

Ein leerer Bericht bedeutet also, dass ein Detektor, der nachweislich hier funktioniert, nichts gesehen hat. Dieser Unterschied ist wichtig, denn ein still kaputtes Werkzeug sieht genauso aus wie sauberer Code.

Architektur

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

Die Schichtregeln werden durch Tests durchgesetzt, die den Quellbaum parsen, damit sie nicht verrotten können: server.py enthält keine Kontrollflusslogik, nur process.py darf einen Subprozess starten, Parser berühren nie eine Datei, und genau ein Modul darf fragen, was diese Maschine ist.

Tests

507 Unit-Tests laufen überall, ohne Compiler. Integrationstests kompilieren und führen Fixtures mit eingepflanzten Bugs aus, und Golden Outputs, die auf Linux, macOS und Windows erfasst wurden, halten jeden Parser ehrlich.

make test

Lizenz

MIT