SonarQube MCP Server

Der SonarQube MCP Server bringt die Ergebnisse Ihrer statischen Codeanalyse in den KI-Assistenten. Wer mit SonarQube arbeitet, kennt den Wechsel zwischen Editor und Weboberfläche: Die Pipeline schlägt an einem Quality Gate fehl, man öffnet das Dashboard, sucht die betroffenen Issues und überträgt sie von Hand in den Chat. Mit dem Server kann der Assistent diese Daten selbst abfragen, den Zustand eines Projekts oder Pull Requests prüfen und Probleme gezielt beheben. Der Server wird von SonarSource selbst gepflegt; das Repository nennt ihn den offiziellen SonarQube MCP Server für Codequalität und Sicherheit in KI-Agenten.

Was ist der SonarQube MCP Server?

Der Server implementiert das Model Context Protocol (MCP), einen offenen Standard, über den KI-Anwendungen Werkzeuge ansprechen. Er läuft lokal, standardmäßig über stdio, und lässt sich laut README auch über Streamable HTTP oder HTTPS betreiben. Im HTTP-Betrieb ist er zustandslos: Jede Anfrage muss ein Bearer-Token mitschicken. Verbunden wird er mit SonarQube Cloud (auch der US-Instanz), mit SonarQube Server ab Version 2025.1 oder mit der Community Build ab 25.1; ältere Versionen weist er beim Start ab. Das Repository SonarSource/sonarqube-mcp-server ist nicht archiviert und wurde zuletzt im Oktober 2026 aktualisiert.

Welche Werkzeuge der Server bereitstellt

Die README gliedert die Werkzeuge in Toolsets, die sich über SONARQUBE_TOOLSETS ein- und ausschalten lassen. Standardmäßig aktiv sind unter anderem Analyse, Issues, Projekte, Quality Gates, Regeln, Duplikate, Metriken, Security Hotspots, Abhängigkeitsrisiken und Testabdeckung. Konkret kann der Assistent mit search_sonar_issues_in_projects offene Issues suchen, mit get_project_quality_gate_status den Stand des Quality Gates abfragen, mit show_rule eine Regel erklären lassen und mit get_component_measures Kennzahlen lesen. Dazu kommen search_security_hotspots, search_files_by_coverage und get_file_coverage_details für Testabdeckung, search_duplicated_files sowie list_pull_requests und list_branches. Mit analyze_file_list lassen sich Dateien lokal analysieren. Optional gibt es Toolsets für Systeminformationen (nur Server), Webhooks, Portfolios und, nur in der Cloud, eine Bewertung der Agenten-Tauglichkeit eines Projekts. Schreibend wirken etwa change_sonar_issue_status und change_security_hotspot_status.

Einrichtung

Empfohlen ist laut README das Container-Image sonarsource/sonarqube-mcp von Docker Hub; alternativ läuft ein eigenständiges JAR mit Java 21 oder neuer. Pflicht ist die Variable SONARQUBE_TOKEN; für SonarQube Server nimmt man ein Benutzer-Token. Für Server setzen Sie außerdem SONARQUBE_URL, für die Cloud optional SONARQUBE_ORG. Mit SONARQUBE_READ_ONLY lässt sich der Server auf lesende Zugriffe beschränken. Anleitungen gibt es für Claude Code, Codex CLI, Cursor, GitHub Copilot, VS Code, Windsurf, Zed und weitere Clients.

Sicherheit und Datenschutz

Analyseergebnisse enthalten Quelltextausschnitte, Dateipfade und Hinweise auf Schwachstellen. Alles, was der Assistent abruft, gelangt in den Kontext des Sprachmodells und damit zum Modellanbieter Ihres Clients. Vergeben Sie Tokens mit möglichst engen Rechten, aktivieren Sie bei reiner Auswertung den Nur-Lesen-Modus und prüfen Sie Statusänderungen an Issues, bevor Sie sie freigeben. Der Server sendet laut README Telemetrie, die keinen Quellcode und keine IP-Adresse enthalten soll und sich per Umgebungsvariable abschalten lässt.

Lizenz und Kosten

Der Server steht unter der SONAR Source-Available License v1.0. Das ist keine von der OSI anerkannte Open-Source-Lizenz, der Quellcode ist aber einsehbar; lesen Sie die Lizenz vor einem Einsatz im Unternehmen. Der Server selbst ist laut Anbieter kostenlos. Für die angebundenen Dienste nennt SonarSource auf der Preisseite einen kostenlosen Einstieg in SonarQube Cloud für private Projekte bis zu einer Größenordnung, kostenpflichtige Team- und Enterprise-Tarife sowie bei SonarQube Server die kostenlose Community Build neben kostenpflichtigen Editionen. Einzelne Werkzeuge, etwa die Abhängigkeitsrisiken, setzen eine höhere Edition voraus. Aktuelle Beträge stehen auf der offiziellen Preisseite.

Für wen lohnt sich der SonarQube MCP Server?

Er lohnt sich für Teams, die SonarQube bereits einsetzen und KI-Assistenten Code schreiben oder korrigieren lassen: Der Assistent kann vor dem Commit prüfen, ob sein Vorschlag das Quality Gate besteht, und nach einem fehlgeschlagenen Lauf die konkreten Issues abarbeiten. Er hilft auch bei Reviews, weil sich Pull Requests mit Kennzahlen und Hotspots direkt im Gespräch bewerten lassen. Wer SonarQube nicht verwendet, hat keinen Nutzen davon. Gegenüber dem Kopieren aus dem Dashboard liegt der Vorteil darin, dass der Assistent gezielt nachfragen kann, etwa nach der Regelbegründung oder der Abdeckung einer bestimmten Datei.

Ein SonarQube-Cloud-Konto oder SonarQube Server ab 2025.1 (Community Build ab 25.1) mit Zugriffstoken, Docker oder Java 21 und ein MCP-Client wie Claude Code, Codex oder Cursor.

Der SonarQube MCP Server gibt Ihrem Assistenten Zugriff auf Issues, Quality Gates und Kennzahlen aus SonarQube. Dieser Ratgeber führt durch Token, Konfiguration und die ersten Aufrufe.

Schnellstart

Als stdio-Server per Container docker run --init --rm -i -e SONARQUBE_TOKEN sonarsource/sonarqube-mcp eintragen; für SonarQube Server zusätzlich SONARQUBE_URL setzen.

docker run --init --rm -i -e SONARQUBE_TOKEN sonarsource/sonarqube-mcp

Schritt 1: Voraussetzungen

Sie brauchen ein Konto bei SonarQube Cloud oder eine SonarQube-Server-Instanz ab Version 2025.1 (Community Build ab 25.1), Docker oder Java 21 und einen MCP-Client wie Claude Code, Codex oder Cursor.

Schritt 2: Token anlegen

Erzeugen Sie in SonarQube ein Zugriffstoken. Bei SonarQube Server ist es ein Benutzer-Token. Das Token bestimmt, was der Assistent sehen und ändern darf, vergeben Sie es deshalb für Ihren eigenen Benutzer mit den Rechten, die Sie wirklich brauchen.

Schritt 3: In den Client eintragen

In Claude Code legen Sie in der Datei .mcp.json einen Eintrag sonarqube vom Typ stdio mit dem Befehl docker und den Argumenten run, --init, --rm, -i, -e, SONARQUBE_TOKEN und sonarsource/sonarqube-mcp an und setzen unter env die Variable SONARQUBE_TOKEN. Für SonarQube Server geben Sie zusätzlich SONARQUBE_URL mit, für die Cloud optional SONARQUBE_ORG. In Cursor ist die JSON-Struktur gleich; starten Sie Cursor danach neu.

Erste Aufrufe

Bitten Sie den Assistenten, mit search_my_sonarqube_projects Ihre Projekte zu nennen und mit get_project_quality_gate_status den Stand des Quality Gates abzufragen. Lassen Sie sich dann offene Issues mit search_sonar_issues_in_projects auflisten, eine Regel mit show_rule erklären und die betroffene Stelle im Code korrigieren.

Schreibrechte bewusst nutzen

Setzen Sie bei reiner Auswertung SONARQUBE_READ_ONLY auf true. Werkzeuge wie change_sonar_issue_status verändern den Stand im Team; geben Sie solche Aufrufe nur nach eigener Prüfung frei und halten Sie das Token aus eingecheckten Dateien heraus.

SonarQube-Token über SONARQUBE_TOKEN (bei SonarQube Server ein Benutzer-Token); im HTTP-Betrieb ein Bearer-Token je Anfrage.

Lesen von Projekten, Issues, Hotspots, Quality Gates, Kennzahlen und Quelltext; Ändern von Issue- und Hotspot-Status sowie Anlegen von Webhooks, sofern das Token es erlaubt.

Der Server läuft lokal und ruft SonarQube Cloud oder Server ab. Abgerufene Analysedaten gelangen in den Kontext des KI-Clients und damit zum Modellanbieter. Telemetrie laut README ohne Quellcode und IP-Adresse, abschaltbar.

Ergebnisse enthalten Quelltext und Hinweise auf Schwachstellen; Statusänderungen an Issues und Hotspots verändern den Stand im Team; Tokens in Konfigurationsdateien können abfließen; die Lizenz ist keine OSI-Open-Source-Lizenz.