SonarQube MCP Server: putting Sonar findings inside an AI agent's context
Official SonarQube MCP Server for code quality and security in AI agents
At a glance
- What is it?
- SonarSource ships an official MCP server that exposes SonarQube Server or Cloud to agent clients and can analyze a code snippet in the agent's own context. It is a thin bridge over an existing SonarQube deployment, not a replacement for one, and the container image is the intended delivery path.
- Who is it for?
- Adopt it if you already run SonarQube Server or SonarQube Cloud and want an agent to read those findings or scan a snippet without leaving the chat. Do not adopt it as a standalone analyzer: it needs a reachable SonarQube instance and a user token, and the README does not describe offline operation.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills between an agent and a SonarQube instance
An agent editing code has no view of what the project's quality gate already says about that code. It can read the files in the working tree, but the issue list, the severity assignments and the security findings live in SonarQube, behind an API the agent has no tool for. This server is that tool. It implements the Model Context Protocol so an MCP-capable client can call SonarQube Server or SonarQube Cloud as a set of tools rather than as a REST endpoint the model has to be taught. The audience is narrow and specific: teams that already run SonarQube and use an agent client such as Claude Code, Cursor, Codex CLI, Gemini CLI or Antigravity. If you do not run SonarQube, the README describes no path that makes this useful on its own. The second capability, analyzing a code snippet directly inside the agent context, is the more interesting one, because it means the model can ask about a fragment before it is committed rather than after a scan.
What actually moves: MCP tools over a stdio container
The architecture visible in the README is deliberately small. The server runs as a container, communicates with the client over stdio (every example passes -i and --rm), and reads its target from environment variables. There is no daemon, no port to open, no database. The client spawns the container, the container talks to SonarQube over the network using the supplied URL and token, and results come back as MCP tool responses. That means the credential crosses three boundaries: the client's configuration, the process environment, and the container. The README's security section acknowledges this by telling you to avoid hardcoding tokens in command-line arguments because they land in shell history, and to use environment variable substitution in config files. The snippet analysis path is notable because it does not require a prior scan of the repository; the README states the server supports analyzing a code snippet within the agent context, which is a different flow from querying existing project findings. The README does not document the tool names or the request shapes, so what the model can ask for is only partly visible from the supplied material.
Wiring it up: environment variables and per-client config
Every setup path in the README reduces to the same three variables. SONARQUBE_TOKEN carries the user token. SONARQUBE_ORG carries the organization key and applies to SonarQube Cloud. SONARQUBE_URL points at a self-hosted SonarQube Server, and for SonarQube Cloud US it is set to https://sonarqube.us. The container image is sonarsource/sonarqube-mcp. For Claude Code the documented command is claude mcp add sonarqube with --env SONARQUBE_TOKEN=$SONAR_TOKEN and --env SONARQUBE_ORG=$SONAR_ORG, followed by the docker run invocation with matching -e flags. For Codex CLI you edit ~/.codex/config.toml and add an [mcp_servers.sonarqube] block whose command is docker and whose args array repeats the same -e pairs, with env holding the values. For Antigravity you either install from the MCP Store or paste a JSON block into mcp_config.json under mcpServers. Cursor has deeplink install buttons, and the README notes that for SonarQube Cloud US you must add SONARQUBE_URL manually after installation. One detail worth copying: the examples use --pull=always for automatic updates, and the README says to pin a version tag such as sonarsource/sonarqube-mcp:1.19.0.2785 when you want reproducible deployments. The README also notes that any OCI-compatible runtime works, so Podman or nerdctl can replace docker in the same arguments. Gemini CLI has moved out of this repository; the README directs you to the sonarqube-agent-plugins repository and the command gemini extensions install https://github.com/SonarSource/sonarqube-agent-plugins.
Where the design bites: tokens, versions and the missing tool reference
The most concrete constraint is the credential. The README's own security guidance treats the token as sensitive and warns against committing it, which tells you the server is designed to hold a live credential with whatever permissions that token carries. A user token scoped to an entire organization is a wide grant to hand to an agent process that a model can drive. The README does not describe a read-only mode or a scoped token type, so the blast radius is whatever SonarQube grants that token. The second constraint is the dependency itself. This is a client for SonarQube, not an analyzer in its own right. No SonarQube instance, no server. The README gives no offline mode and no bundled rules engine. Third, the README documents configuration exhaustively and tool behavior barely at all. There is no list of exposed tools, no parameter reference, and no description of what a snippet analysis returns or which languages it covers. For an engineer deciding whether to adopt it, that is the largest gap: you can see how to start it, but not what it will do once running. Version compatibility with older SonarQube Server releases is also not stated in the supplied material, so treat it as unverified.
How this differs from pointing an agent at the SonarQube web API
The obvious alternative is to skip the MCP layer and let the agent call the SonarQube Web API directly, either through a generic HTTP tool or through a small script you write. The difference is in who owns the interface. With the MCP server, SonarSource owns the tool definitions, the argument shapes and the response formatting, and updates arrive as new container tags. With a direct API integration, you own all of that: you write the wrapper, you handle pagination and authentication, and you fix it when the API changes. The trade is control against maintenance. A direct integration can be narrowed to exactly the endpoints you want and can run with a token you scoped yourself, which addresses the credential concern above. The MCP server gives you a supported, versioned artifact that works across several clients with the same configuration block, and it adds the snippet analysis path that a raw API call would not give you without extra work. If your agent only ever needs one endpoint, the wrapper is smaller. If you want the snippet flow and the same setup across Claude Code, Cursor and Codex CLI, the server is the shorter route.
Upgrade cadence and what the licence metadata does not say
The release tags show a steady cadence: 1.24.0.3152 on 2026-08-04, 1.25.0.3221 on 2026-08-18, and 1.26.0.4269 on 2026-08-31, roughly every two weeks. Because the documented deployment is a container pulled at start time, staying current is close to free if you use --pull=always, and pinning a tag is the way to opt out. The cost of upgrading is the usual one for a moving MCP surface: tool names or argument shapes can change between minor versions, and the README does not promise stability. If you pin, you take on the job of watching for releases yourself. On licensing, the GitHub metadata reports NOASSERTION, which means the repository does not declare a recognized SPDX licence in the metadata this review was based on. That is not the same as having no licence, and it is not something to guess at. Read the LICENSE file in the repository and get your own answer before shipping the container inside a commercial product. The README itself makes no licensing statement.
Who should wire this in, and what to confirm before you do
This fits teams that already treat SonarQube as their source of truth for code quality and want that truth available to an agent while it writes code. It fits least well where there is no SonarQube instance, where the token available is broader than you would hand a model, or where the agent needs to work without network access to a SonarQube server. The gap in the documentation is the thing to close first. Before adopting, run the container once and enumerate the tools the client discovers; the README does not tell you what they are, and that list determines whether the server covers the questions your agent actually asks. Confirm the token type and its scope against your SonarQube instance, since the README treats it as a plain user token. Then decide between --pull=always and a pinned tag, and read the LICENSE file in the repository, because the metadata alone does not settle the licence question.
Editorial conclusion
Adopt it if you already run SonarQube Server or SonarQube Cloud and want an agent to read those findings or scan a snippet without leaving the chat. Do not adopt it as a standalone analyzer: it needs a reachable SonarQube instance and a user token, and the README does not describe offline operation. Before wiring it into a shared agent, verify which SonarQube version your instance runs, whether the token is a user token or a project analysis token, and whether your client supports the Docker-based stdio transport shown in the README. Also check the licence file in the repository, because the GitHub metadata reports NOASSERTION rather than a named licence.
Community notes