Provides read-only tools for inspecting a SonarQube instance: explains why a project's quality gate is red (listing failing conditions), searches unresolved issues filtered by severity, type, status, branch, pull request or new code, reads measures such as coverage and bugs, fetches source lines around an issue, and lists branches and accessible projects.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SonarQube MCP why is the quality gate red on my-project?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
🔍
MCP server for SonarQube — explain a red quality gate, search issues, read measures and source snippets.
Website · Documentation
Red gate, explained — status, new-code period and every condition, with the failing ones listed first and ratings shown as A–E
Issue search — filter a project's unresolved issues by severity, type, status, branch, pull request or new code, each with file, line, rule, message, author and date
Measures on demand — read any metric (coverage, bugs, new_coverage, sqale_rating) for a project, branch or pull request
Source in context — fetch the lines around an issue without leaving your MCP client
Strictly read-only — all six tools are annotated read-only and idempotent; nothing in SonarQube is ever changed
Token stays private — it is never returned, and is redacted from any error message
Zero-install usage — run directly via npx -y @kud/mcp-sonarqube@latest
Related MCP server: sonarqube-api-mcp
npm install -g @kud/mcp-sonarqubeOr use without installing via npx (see Configuration below). Requires Node.js 22 or later.
Set the host and a token, then start the server over stdio:
SONAR_HOST_URL=https://sonarqube.example.com \
SONAR_TOKEN=your-token \
npx -y @kud/mcp-sonarqube@latestYour MCP client then exposes six tools:
Tool | What it does | Inputs |
| Explains why a quality gate is red, failing conditions first |
|
| Searches unresolved issues |
|
| Reads measures such as |
|
| Shows the source lines around an issue |
|
| Lists branches with quality gate status and last analysis date |
|
| Lists or searches the projects the token can see |
|
A few details worth knowing:
severities accepts INFO, MINOR, MAJOR, CRITICAL, BLOCKER; types accepts CODE_SMELL, BUG, VULNERABILITY.
statuses defaults to unresolved issues. limit defaults to 10 for issues and 50 for projects, with a maximum of 500.
sonarqube_issue_source takes the component and line exactly as sonarqube_issues returns them, for example my-project:src/index.ts. contextLines defaults to 5, maximum 50.
Typical questions to put to your client: "why is the gate red on my-project?", "list the blocker bugs in new code on pull request 42", "what is the new coverage on the main branch?".
SonarQube MCP works with any MCP-compatible client — Claude Desktop, Cursor, Cline, Zed, Continue, and others. Register it in your client's MCP server configuration:
{
"mcpServers": {
"sonarqube": {
"command": "npx",
"args": ["-y", "@kud/mcp-sonarqube@latest"],
"env": {
"SONAR_HOST_URL": "https://sonarqube.example.com",
"SONAR_TOKEN": "<your-token>"
}
}
}
}The config file and its exact location depend on your client. Claude Desktop, for example, uses claude_desktop_config.json (Settings → Developer → Edit Config).
For a self-hosted instance on your own machine, point the host at it directly, for example http://127.0.0.1:9000.
If you use Claude Code, the server is also available as the sonarqube plugin from the kud/claude-plugins marketplace:
/plugin marketplace add kud/claude-plugins
/plugin install sonarqube@kudConfiguration is resolved by the @kud/sonarqube core. The first variable set wins; there is no default host, and the server exits at start-up without one.
Setting | Environment variables, in order | Required |
Host |
| Yes |
Token |
| Yes, for private projects |
Both can also come from the config file shared with the sonarqube-dash CLI, at $XDG_CONFIG_HOME/sonarqube-dash-cli/config.json (default ~/.config/sonarqube-dash-cli/config.json), using the keys host and token. Environment variables take precedence over the file.
git clone https://github.com/kud/mcp-sonarqube.git
cd mcp-sonarqube
npm install
npm run devTo test interactively with the MCP Inspector:
npm run inspect:devAll HTTP, authentication and config resolution live in the @kud/sonarqube core; this package only validates tool input, calls the client and shapes the output.
📚 Full documentation → mcp-sonarqube/docs
List a project's branches with their quality gate status and last analysis date
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context by naming the returned fields, but says nothing about pagination, whether the main branch is included, or ordering/limits on results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler; the action and returned content are front-loaded. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only listing tool with complete schema coverage and no output schema, the description covers purpose and result content adequately. Minor gaps remain around result set behavior (pagination, main branch inclusion), but nothing essential to a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single required parameter with 100% schema description coverage ('Project key'), so the schema carries parameter meaning. The description's phrase 'a project's branches' reinforces the association but adds no format or identifier syntax beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (a project's branches) and even names the returned fields (quality gate status, last analysis date). This is easily distinguished from siblings like sonarqube_projects or sonarqube_issues without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: it lists branches for a given project, so an agent can infer it needs a project key. There is no explicit when-to-use, no mention of alternatives, and no note on when branches would be absent (e.g., non-branch-enabled projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a project's unresolved issues with file, line, rule, severity, type, message, author and creation date
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum issues to return (default 10, max 500) | |
| types | No | Filter by issue type | |
| branch | No | Branch name | |
| newCode | No | Only issues in the new-code period | |
| project | Yes | Project key | |
| statuses | No | Filter by status (OPEN, CONFIRMED, REOPENED, RESOLVED, CLOSED). Defaults to unresolved issues | |
| severities | No | Filter by severity | |
| pullRequest | No | Pull request id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds that results default to unresolved issues, but that fact is already in the statuses parameter description, and nothing is said about result volume, ordering, or cross-branch default behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the core purpose stated first. It is not bloated, though the trailing field list is the weakest, least accurate part of the sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should hint at what comes back; the field list serves that role loosely but is ambiguous about whether those are returned fields or filters. With 8 parameters and no mention of branch/PR scoping or result limits, the definition is adequate but incomplete for an agent picking the right scope on a first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description names fields (file, line, rule, message, author, creation date) that are NOT parameters, which can mislead an agent into expecting filters that do not exist. Meanwhile real parameters (branch, pullRequest, newCode, limit) go unmentioned, so the sentence adds noise rather than meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb (search) and resource (a project's unresolved issues) and enumerates the fields of interest, so an agent knows what it retrieves. It does not name or contrast with siblings, but the siblings cover clearly different resources (branches, projects, measures, quality gate), so confusion risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to use this tool versus alternatives, no prerequisites (e.g. needing a project key), and no guidance on combining with sonarqube_issue_source for drill-down. Usage is only implied by the word 'search'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the source lines around a line of a component, as returned by sonarqube_issues (component and line)
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line to centre the snippet on | |
| component | Yes | Component key, e.g. my-project:src/index.ts | |
| contextLines | No | Lines of context either side (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a safe, read-only, idempotent, open-world operation. The description adds that it retrieves surrounding source lines, but it does not add significant behavioral detail beyond that, such as permissions or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no filler. Every phrase contributes to identifying the resource, the operation, or the source of the required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool with full schema coverage and rich annotations, the description is nearly complete. It could mention the return shape more explicitly, but the core behavior is sufficiently clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents component, line, and contextLines. The description adds useful provenance by indicating that component and line values should come from sonarqube_issues output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: show source lines around a line of a component. It also distinguishes the tool from sonarqube_issues by tying the component and line values back to that sibling's output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the tool should be used after sonarqube_issues has provided a component and line. However, it does not explicitly state when not to use it or name other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read measures for a project, e.g. coverage, bugs, new_coverage, reliability_rating (ratings shown as A-E)
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Branch name | |
| project | Yes | Project key | |
| metricKeys | Yes | Metric keys, e.g. [coverage, bugs, sqale_rating] | |
| pullRequest | No | Pull request id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety and repeatability are covered. The description adds one useful behavioral detail — that rating metrics are rendered as letter grades A-E — but says nothing about branch/pull-request scoping semantics or how missing/never-computed metrics are reported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the core purpose front-loaded and no filler. It is arguably even slightly under-specified rather than padded, which is the right failure mode for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a fully described schema and no output schema, the description covers the essentials but leaves gaps: no indication of what a result entry looks like (metric key plus value/period), and no guidance on branch vs pullRequest scoping. Adequate but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (project, metricKeys, branch, pullRequest) are already documented in the schema, setting the baseline at 3. The description contributes a small extra by naming additional metric keys (new_coverage, reliability_rating) and explaining the A-E output convention, but it does not clarify how branch and pullRequest interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Read measures for a project") and enumerates representative metrics, so the agent knows exactly what data this returns. It does not explicitly contrast itself with siblings like sonarqube_issues or sonarqube_quality_gate, but the 'measures/metrics' framing is distinctive enough to separate it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The only usage-adjacent content is the metric examples, which guide what to pass rather than when to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search projects the token can see
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum projects to return (default 50, max 500) | |
| query | No | Name or key fragment to match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added context is permission scoping ('the token can see'), which is genuinely useful, but it says nothing about pagination, default result size, or ordering. Modest value-add against already-rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the visibility scope comes immediately after the verb. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-optional-param read tool with full schema coverage and complete annotations, the definition is sufficient to call it correctly. It could note whether results are paginated, but no output schema is needed and nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented (limit with default/max, query as name-or-key fragment), so the schema carries the burden. The description's 'search' wording loosely signals the query param but adds no format or matching semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb pair ('List or search') and resource ('projects') plus the visibility scope ('the token can see'). The sibling tools are all different resources (issues, measures, branches), so no sibling differentiation is needed, though it never distinguishes list-vs-search mode activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List or search' implies two usage modes but gives no condition for choosing between them and no guidance on when to reach for this versus the issue/measures siblings when drilling into a project. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain why a quality gate is red: status, new-code period, and conditions with the failing ones first (ratings as A-E)
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Branch name | |
| project | Yes | Project key | |
| pullRequest | No | Pull request id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's value is in disclosing the response shape: failing conditions ordered first and ratings rendered A-E. That is genuinely useful behavioral context beyond the annotations, though error and missing-gate behavior are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the purpose front-loaded and the output facets following. Nothing is redundant, though the clause list is packed tightly enough to read as slightly cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no title, the description does the needed work of sketching the return payload (status, new-code period, conditions, ratings). Remaining gaps are edge-case behavior rather than core invocation information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for project, branch, and pullRequest, so the schema carries parameter meaning. The description adds nothing about how branch/PR selection affects the gate result, leaving it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('explain') and resource ('quality gate'), plus the exact facets returned (status, new-code period, conditions). It is clearly distinct from siblings like sonarqube_issues or sonarqube_measures, though it never names them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Explain why a quality gate is red' implies the triggering condition (a failing gate), but there is no explicit when-to-use guidance, no mention of how branch/pullRequest scoping changes the call, and no named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0sonarqube_branchessonarqube_issue_sourcesonarqube_issuessonarqube_measuressonarqube_projectssonarqube_quality_gateScored across 6 tools
Most tools target clearly distinct resources: projects, branches, issues, issue source, measures, and quality gate. There is some potential overlap between sonarqube_quality_gate and sonarqube_measures because both surface ratings/metrics, and sonarqube_branches also includes quality gate status, but the descriptions make their scopes sufficiently distinct.
All tools use a consistent sonarqube_ prefix and snake_case resource-oriented naming. The convention is predictable throughout, with no mixed camelCase or inconsistent verb styles.
Six tools is well within the appropriate range and each tool maps to a core read-only SonarQube workflow. The surface is focused without obvious redundant tools.
The set covers project discovery, branches, unresolved issues, source context, measures, and quality gate explanation, forming a coherent triage workflow. Minor gaps exist for adjacent SonarQube data such as security hotspots and rule metadata, but core agent needs are covered.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
30+ deterministic dev and delivery tools: linting, metrics, diagrams, model advice, AI-text checks.
Seven read-only tools for public breach disclosures, organization histories, timelines and statistics. Retains attribution, redaction and coverage limits. No breached records or credentials.
