Sonar MCP Server

Sonar MCP Server

A local MCP server providing read-only access to a SonarQube Community Build (26.4+) instance via its web-api. It lets AI agents (Claude Code, Cursor, VS Code Copilot, etc.) fetch a project's issue list, the files and locations where they occur, rule descriptions, source-code snippets around issues, and Security Hotspots.

Typical scenario: "find and fix Sonar issues in such-and-such project" — the LLM calls listIssues, optionally getRule and getIssueSnippets, and edits files locally.

Why this server

There is an official SonarSource MCP server, but it targets SonarQube 10+ (and SonarCloud) and assumes a cloud-style deployment. This server is built for self-hosted SonarQube Community Build 26.4+ installations that expose the classic /api/ web-api. It supports both Standard Experience and MQR mode, handling per-software-quality impacts when the instance runs in MQR mode.

It is also intentionally narrower in scope:

• Read-only by design. The server never creates, updates, or deletes anything in SonarQube — no marking issues as false-positive, no editing comments, no admin endpoints. The token's write permissions in SonarQube are irrelevant because the server never calls those endpoints.
• Curated tool set. Instead of mirroring the SonarQube API surface, the server exposes a small, focused set of tools (13 in total) chosen for a single workflow: *let an AI agent read Sonar's findings and fix the code based on them*. Listing components, issues and hotspots, drilling into a single finding, fetching the rule explanation, and pulling the source-code snippet around the location — and that's it. Anything outside this "diagnose -> fix the code locally" loop is deliberately left out to keep the tool list small and the agent's choices unambiguous.

In short: a focused, read-only bridge from a self-hosted SonarQube Community Build to an AI coding agent.

Quick start

1. Install JDK 25+.
2. Download sonar-mcp-server.jar from the latest release, or build it yourself: ./gradlew bootJar (see Build). A Docker image is published as well.
3. Get your SonarQube URL and user token (see Configuration).
4. Add the JAR to your client's MCP configuration (see Connecting to an AI client).

For Claude Code that is one command:

claude mcp add --scope user -e SONAR_URL=https://sonar.example.com -e SONAR_TOKEN=your_token -- sonar java -jar /path/to/sonar-mcp-server.jar

Architecture

The server only supports the stdio transport.

┌─────────────┐     stdio      ┌──────────────────┐    web-api     ┌──────────┐

│ AI agent │ <------------> │ sonar-mcp- │ -------------> │ SonarQube│ │ (Claude Code│ stdin/stdout │ server (Java) │ HTTP + Bearer │ CB 26.4+│ │ Cursor...) │ │ │ auth (token) │ │ └─────────────┘ └──────────────────┘ └──────────┘

The AI client spawns the server as a child process; communication uses the MCP protocol over stdin/stdout. The server does not open any HTTP port and accepts no incoming connections.

Tools

The server exports 13 read-only MCP tools.

Projects

Issues

Rules

Security Hotspots

All tools are read-only — no data in SonarQube is modified.

Working with branches and pull requests

Sonar analyses a *branch* and a *pull request* as two distinct, mutually exclusive scopes. The Sonar web-api accepts either branch= or pullRequest= on a single request, never both.

• `branch` — long-lived branches (main, develop, feature/...). Resolved as: explicit branch argument → SONAR_DEFAULT_BRANCH → none (Sonar uses the project's main branch).
• `pullRequest` — the Sonar PR key, usually the PR/MR number. Independent from branch analyses; PR analyses often contain the most relevant findings for in-flight work. Pull request keys never fall back to a server-level default — pass them explicitly.

Passing both branch and pullRequest to the same tool call is an error. Use listProjectBranches / listProjectPullRequests to discover available refs.

Branch scoping is load-bearing. Each Sonar branch is a separate analysis: open-issue counts on main and on a feature branch can differ a lot, because the feature branch may have new fixes (or new code) that have not been merged. If the agent silently omits branch=, it reads from main (or SONAR_DEFAULT_BRANCH) and may miss work already done on a feature branch — or worse, fix the same problem twice. When the user's local git is on feature/..., agents should call listProjectBranches first, find the matching Sonar branch, and pass it explicitly to every issue / summary / breakdown call.

As a server-side safety net, listIssues, getProjectIssuesSummary, and getProjectIssuesBreakdown attach a branchAdvisory field to their response when (1) neither branch nor pullRequest was passed AND (2) the project has other branches analysed in Sonar. The advisory carries the effective (main) branch name and the list of non-main branches sorted by most recent analysisDate. The field is absent otherwise.

Stack

• Java 25, Spring Boot 4.0.0, Spring AI MCP 2.0.0 (stdio transport)
• Jackson 3 (tools.jackson) for JSON
• Gradle 9.3.1 with version catalog (gradle/libs.versions.toml)

Build

# Point to a JDK 25+ if it's not the default:

export JAVA_HOME="$HOME/.jdks/jdk-25.0.2"

./gradlew build

On Windows: .\gradlew.bat build.

Output: build/libs/sonar-mcp-server.jar

Configuration

The server needs a SonarQube URL and token; the rest is optional.

| SONAR_MCP_PAGINATION_DEFAULT_LIMIT | Default page limit for list tools; defaults t