SonarQube MCP: Agent prüft Code-Changes vor dem Pull Request

Pexon Consulting | 10 Min. Lesezeit | 10.06.2026

TL;DR

SonarQube MCP Agent ist 2026 das fehlende Puzzlestück zwischen produktiven Coding-Agents (Claude Code, Cursor, OpenAI Codex) und enterprise-tauglicher Code-Qualität: Statt SonarQube-Findings erst nach dem CI-Run zu sehen, prüft der Agent seine eigenen Changes live gegen die SonarQube-Regeln und korrigiert Probleme, bevor der Pull Request rausgeht. Pexon Consulting baut MCP-Server für SonarQube als Standard-Komponente in Engineering-Setups — 4-6 Wochen Sprint mit messbarem Effekt auf die PR-Review-Velocity.

Warum SonarQube und Agent zusammengehören

Wir sehen das aktuell in fast jedem Engineering-Erstgespräch: Das Team nutzt seit zwei Jahren SonarQube als Quality-Gate in der CI-Pipeline. Findings werden im Pull-Request-Review angezeigt, der Dev korrigiert, Cycle dauert 2-3 Iterationen. Gleichzeitig nutzt das Team seit sechs Monaten Claude Code oder Cursor für die Entwicklung. Diese zwei Tool-Welten reden nicht miteinander.

Der naive Workflow: Agent schreibt Code, Dev pusht, CI läuft 8-25 Minuten, SonarQube findet drei oder vier Probleme, Dev (oder erneut der Agent) korrigiert, push, neuer CI-Run, weiteres SonarQube-Finding. Pro Pull Request typisch 2-4 dieser Zyklen. Das ist Zeit-Verschwendung — die Probleme wären beim Schreiben schon vermeidbar gewesen, wenn der Agent SonarQube-Regeln kennen würde.

Die saubere Antwort heißt SonarQube MCP-Server: Der Agent bekommt einen direkten Read-Zugriff auf SonarQube — Regeln, Findings, Quality-Gates, Hotspots — und kann diese in Real-Time während des Schreibens nutzen. Plus optional Schreib-Zugriff für False-Positive-Marking oder Quality-Profile-Updates. Damit wandert die Quality-Prüfung von „nach dem Commit“ zu „vor dem Commit“.

Architektur: SonarQube MCP-Server

Wir bauen das mit FastMCP als Standard. Architektur in drei Komponenten.

Komponente 1: MCP-Server-Wrapper um die SonarQube REST-API. Die SonarQube REST-API ist gut dokumentiert, aber als direkter Tool-Use für einen Agent zu verbose und zu sehr auf UI-Use-Cases zugeschnitten. Unser Wrapper kürzt das auf die agent-relevanten Operationen.

from fastmcp import FastMCP
import httpx

mcp = FastMCP("sonarqube-server")
SONAR_BASE = "https://sonar.intern.example.com/api"
SONAR_TOKEN = os.getenv("SONAR_TOKEN")

@mcp.tool
def get_project_rules(
    project_key: str,
    language: str | None = None,
) -> list[dict]:
    """
    Liefert die aktivierten SonarQube-Regeln für ein Projekt.
    Inklusive Schweregrad, Typ (BUG/VULNERABILITY/CODE_SMELL) und Beschreibung.
    """
    profile = _get_quality_profile(project_key, language)
    response = httpx.get(
        f"{SONAR_BASE}/rules/search",
        params={"qprofile": profile, "activation": "true", "ps": 500},
        auth=(SONAR_TOKEN, ""),
    )
    return [_summarize_rule(r) for r in response.json()["rules"]]

@mcp.tool
def get_file_findings(
    project_key: str,
    file_path: str,
) -> list[dict]:
    """
    Liefert SonarQube-Findings für eine spezifische Datei.
    Inklusive Zeilen-Nummer, Regel-ID, Schweregrad, Vorschlag.
    """
    response = httpx.get(
        f"{SONAR_BASE}/issues/search",
        params={
            "componentKeys": f"{project_key}:{file_path}",
            "resolved": "false",
            "ps": 100,
        },
        auth=(SONAR_TOKEN, ""),
    )
    return [_summarize_issue(i) for i in response.json()["issues"]]

@mcp.tool
def check_quality_gate(project_key: str) -> dict:
    """
    Liefert den aktuellen Quality-Gate-Status eines Projekts.
    PASS oder FAIL plus Detail-Conditions.
    """
    response = httpx.get(
        f"{SONAR_BASE}/qualitygates/project_status",
        params={"projectKey": project_key},
        auth=(SONAR_TOKEN, ""),
    )
    return response.json()["projectStatus"]

Komponente 2: Pre-Commit-Hook plus Skill-Definition. Im .claude/skills/sonar-review.md definieren wir einen Standard-Skill, den der Agent vor jedem Commit ausführt: Lese die geänderten Dateien, hole die Quality-Profile-Regeln, prüfe die Changes gegen die häufigsten Anti-Pattern, schlage Korrekturen vor wenn nötig.

Komponente 3: Continuous-Quality-Check während Live-Sessions. Der Agent prüft alle 5-10 Edits live, was die SonarQube-Findings sein würden. Wenn ein neues kritisches Finding entstanden ist, weist er den Dev darauf hin, bevor das Problem in den Commit wandert.

Was der Agent konkret während des Coding macht

Drei Workflows aus unseren Pilotprojekten:

Workflow 1: Pre-Commit Quality Check. Vor jedem git commit läuft ein Skill, der die geänderten Dateien gegen SonarQube prüft. Beispiel-Output:

Pre-commit SonarQube-Check für src/payment/processor.py:

Neue Findings die mit diesem Commit erscheinen würden:
  - L42 CRITICAL (Bug): "Methode kann NullPointerException werfen" 
    Vorschlag: Null-Check vor Aufruf von customer.account_id einfügen
  - L67 MAJOR (Code Smell): "Methode hat 4 Verschachtelungs-Ebenen"
    Vorschlag: Extract Method für die innere if-Schleife
  - L89 BLOCKER (Vulnerability): "SQL-Concatenation statt prepared Statement"
    Vorschlag: Parameter-Binding verwenden

Quality-Gate würde FAIL.
Soll ich die Korrekturen direkt vorschlagen?

Der Dev entscheidet, lässt Korrekturen einbauen oder commitet trotzdem. Bei einem Pilotkunden haben wir die Annahme-Rate auf 87% gemessen — bei den meisten Findings nimmt der Dev den Vorschlag.

Workflow 2: PR-Review-Vorbereitung. Vor dem Push eines Pull Requests läuft eine umfassendere Prüfung: Alle Änderungen seit letztem git fetch origin, vollständige SonarQube-Simulation, Schreiben eines PR-Kommentars, der die Findings und ihre Behandlung dokumentiert. Damit kommt im Reviewer-Tab nicht „23 SonarQube-Findings warten auf dich“, sondern „12 Findings ursprünglich, 11 davon im PR adressiert, 1 begründet als False-Positive markiert“.

Workflow 3: Legacy-Codebasis-Migration. Bei Code-Basen mit hohem SonarQube-Tech-Debt nutzen wir den Agent als systematischen Cleanup-Helfer. Er bekommt ein wöchentliches Cleanup-Ziel („nimm dir 30 CRITICAL-Findings vor“), arbeitet sich durch die Liste, schlägt Korrekturen vor, dokumentiert begründete False-Positive-Marks. Bei einem Engineering-Team haben wir damit 1.400 SonarQube-Findings in vier Wochen abgebaut — manuell wäre das ein 12-Wochen-Projekt gewesen.

Praxis-Effekt aus einem Pilotkunden

Konkrete Hausnummern aus einem Pilot 2025/2026. Mittelständischer SaaS-Anbieter, 38 Engineers, 8-12 Pull Requests pro Tag, SonarQube als Quality-Gate seit drei Jahren produktiv.

Der Cleanup-Effekt ist interessant: Statt mehr Technical Debt zu produzieren als zu bauen, hat der Agent durch konstante Vorab-Prüfung plus die wöchentlichen Cleanup-Sprints den Technical-Debt-Stand sogar leicht reduziert. Das ist die strukturelle Veränderung, die ein klassisches Tools-Setup nicht erreicht.

Häufig gestellte Fragen

Funktioniert das mit SonarQube Community Edition oder nur Developer/Enterprise?

Mit allen drei Editionen. Die SonarQube-REST-API ist in Community Edition voll verfügbar, was wir vom Server brauchen ist Lese-Zugriff auf Regeln, Findings, Quality Gates. Für Schreib-Operationen (False-Positive-Marking, Quality-Profile-Update) brauchst du je nach Funktion höhere Editionen — die meisten Use-Cases laufen Lese-only.

Wie integriert sich das mit Claude Code, Cursor oder OpenAI Codex?

Alle drei sprechen MCP-Standard. Claude Code hat First-Class-Support — der MCP-Server wird einmalig in der Konfiguration registriert und steht in jeder Session zur Verfügung. Cursor unterstützt MCP seit Version 0.45 produktiv. Bei OpenAI Codex CLI funktioniert es über die MCP-Connector-Konfiguration.

Was passiert mit SonarQube-spezifischen False-Positives, die der Agent als „Findings“ sieht?

Wir bauen einen Schritt im Skill ein, der bestehende False-Positive-Markierungen in SonarQube respektiert. Plus: Der Agent kann mit Custom-Tool im MCP-Server False-Positives setzen — mit dokumentierter Begründung. Das ist begrenzt auf die zwei oder drei Engineers, die die Berechtigung haben, sonst entsteht False-Positive-Inflation.

Wie performant ist das? Kann der Agent live in jeder Session prüfen?

Single-Tool-Call gegen SonarQube REST-API liefert typisch in 200-800ms. Bei jedem Commit oder Major-Edit ist das problemlos. Bei sub-second-Pre-Commit-Hooks bauen wir Caching ein — Regeln werden alle 60 Minuten neu gezogen, Findings live geprüft. Damit bleibt die Pre-Commit-Latenz unter 1-2 Sekunden bei typischen Datei-Mengen.

Können wir das auch ohne Pexon-Sprint selbst bauen?

Ja, der MCP-Server-Code ist nicht hochkomplex. Wir liefern in unseren Sprints ein produktives FastMCP-Setup plus Skill-Definitionen plus Integration mit eurem Engineering-Workflow — das ist der eigentliche Aufwand. Der Code allein ist in 1-2 Wochen baubar, das Engineering-Workflow-Setup ist die andere Hälfte.

Nächster Schritt

Wenn euer Engineering-Team Claude Code oder ein anderes Coding-Agent-Tool nutzt und SonarQube produktiv betreibt: Wir machen einen 45-Minuten-Call mit dir und idealerweise einem Engineering-Lead. Du beschreibst SonarQube-Setup und Coding-Agent-Stack, wir skizzieren den MCP-Server-Sprint mit Festpreis.

Verwandte Themen