Sonarqube MCP Server

What sonarqube-mcp-server does

sonarqube-mcp-server exposes SonarQube code quality and security operations through the Model Context Protocol. It supports both SonarQube Server and SonarQube Cloud, allowing an MCP-compatible client to send source files for analysis or query quality data from an existing SonarQube project.

The server covers two related workflows. For direct source review, an agent can submit complete file content, optionally identify a project-relative path, specify the language, and filter returned findings to a matching snippet. For repository-level work, it can analyze files in the current working directory through a running SonarQube for IDE instance and control that instance’s automatic analysis behavior.

How it works

The standard setup launches the published sonarsource/sonarqube-mcp container with Docker or another OCI-compatible runtime. MCP requests are exchanged over the container’s standard input and output. Authentication and the target SonarQube deployment are configured with environment variables rather than passed as tool arguments.

Cloud connections use a SonarQube token and organization key. Server connections use a user token and SonarQube URL. SonarQube Cloud US can be selected by setting the URL to https://sonarqube.us.

File analysis can receive source text directly when the workspace is not mounted. When the workspace is mounted at /app/mcp-workspace, a project-relative file path can identify the file instead. Analysis inputs also distinguish production code from test code through MAIN and TEST scopes.

Setup and configuration

The project provides an interactive configuration generator for supported AI agent clients. Manual configuration uses the sonarsource/sonarqube-mcp container image. Using --pull=always tracks the image tag selected for the deployment; a pinned tag can instead be used for reproducible container configuration.

Keep SONARQUBE_TOKEN out of shell history and source control. Set credentials through environment variables or substitute them into configuration files without committing the secret. The relevant connection settings are:

• SONARQUBE_TOKEN: SonarQube Cloud token or SonarQube Server user token.
• SONARQUBE_ORG: SonarQube Cloud organization key.
• SONARQUBE_URL: SonarQube Server URL, or the SonarQube Cloud US endpoint.
• SONARQUBE_PROJECT_KEY: Default project key for operations that use a project; tool-level values can override it where supported.

Documented client setup paths include Cursor, Claude Code, Codex CLI, Gemini CLI, Antigravity, and GitHub Copilot CLI. The Gemini CLI extension is installed from the sonarqube-agent-plugins repository.

Tools and capabilities

• Analyze complete source files with SonarQube analyzers and optionally filter findings to a supplied snippet.
• Analyze lists of absolute file paths through SonarQube for IDE.
• Enable or disable automatic SonarQube for IDE analysis.
• Run Vortex analysis for an individual file using a branch’s latest analysis context.
• Find project files with coverage at or below a chosen threshold, including pull-request filtering and pagination.
• Retrieve line-level coverage details, including uncovered lines and partially covered branches.
• Search dependency risks associated with releases in analyzed projects, applications, or portfolios.
• List accessible SonarQube Cloud enterprises and change issue statuses to accepted, false positive, or reopened, with an optional comment.

Limitations and notes

The direct snippet-analysis operation requires complete file content for accurate analysis; a snippet can be used as a result filter only when it matches content in that file. Coverage detail lookup uses a SonarQube file key and can be limited to a line range. Pull-request coverage searches require a valid pull-request key, which can be discovered with list_pull_requests.