Provides SonarQube and SonarCloud integration patterns via the Model Context Protocol (MCP) server. Enables quality gate monitoring, issue discovery and triaging, pre-push code analysis, and rule education directly in the agent workflow. Use when the user wants to check quality gates, search for Sonar issues, analyze code snippets before committing, or understand SonarQube rules. Triggers on "sonarqube", "sonarcloud", "quality gate", "sonar issues", "analyze with sonar", "check sonar", "sonar rule", "pre-push analysis".
Provides SonarQube and SonarCloud integration patterns via the Model Context Protocol (MCP) server. Enables quality gate monitoring, issue discovery and triaging, pre-push code analysis, and rule education directly in the agent workflow. Use when the user wants to check quality gates, search for Sonar issues, analyze code snippets before committing, or understand SonarQube rules. Triggers on "sonarqube", "sonarcloud", "quality gate", "sonar issues", "analyze with sonar", "check sonar", "sonar rule", "pre-push analysis".
allowed-tools
Read
SonarQube MCP Integration
Leverage SonarQube and SonarCloud capabilities directly through the Model Context Protocol (MCP) server to enforce code quality, discover issues, and run pre-push analysis inside the agent workflow.
Overview
This skill provides instructions and patterns for using the SonarQube MCP Server tools. It enables automated workflows for:
Checking quality gate status before merges or deployments
Discovering and triaging issues by severity and project
Analyzing code snippets locally before committing (shift-left)
Understanding SonarQube rules with full documentation
When to Use
Use this skill when:
The user wants to check if a project passes its quality gate before merging a PR
The user wants to find critical or blocker issues in one or more SonarQube projects
The user wants to analyze a code snippet for issues before pushing to CI
The user wants to understand why a specific Sonar rule flagged their code
The user asks for pre-commit or pre-push quality feedback
The plugin includes a .mcp.json that starts the SonarQube MCP Server automatically via Docker. Before using this skill, set the required environment variables:
SonarQube Server (remote or local):
export SONARQUBE_TOKEN="squ_your_token"export SONARQUBE_URL="https://sonarqube.mycompany.com"# or http://host.docker.internal:9000 for local Docker
SonarCloud:
export SONARQUBE_TOKEN="squ_your_token"export SONARQUBE_ORG="your-org-key"# required for SonarCloud# SONARQUBE_URL is not needed for SonarCloud
Requirements:
Docker must be installed and running
SONARQUBE_TOKEN is always required
SONARQUBE_URL is required for SonarQube Server (use host.docker.internal for local instances)
SONARQUBE_ORG is required for SonarCloud (omit SONARQUBE_URL in that case)
Use this to mark false positives or accepted technical debt:
{"name":"change_sonar_issue_status","arguments":{"key":"AY1234","status":"falsepositive","comment":"This pattern is safe in our context because..."}}
Valid statuses: falsepositive (not a real issue), accept (acknowledged technical debt), reopen (reset to open)
Always present the list of issues to the user before changing their status. Never autonomously mark issues as false positives without explicit user confirmation.
Step 4: Pre-Push Analysis (Shift Left)
Use analyze_code_snippet to run SonarQube analysis on code before committing.
Parameters:
projectKey (string) — Project key for context
fileContent (string, required) — Full content of the file to analyze
language (string, optional) — Language hint for better accuracy
codeSnippet (string, optional) — Narrow results to a specific sub-range within fileContent
{"name":"analyze_code_snippet","arguments":{"projectKey":"my-typescript-app","fileContent":"async function fetchUser(id: string) {\n const query = `SELECT * FROM users WHERE id = ${id}`;\n return db.execute(query);\n}","language":"typescript"}}
Pattern — Analyze Python file:
{"name":"analyze_code_snippet","arguments":{"projectKey":"my-python-service","fileContent":"import pickle\n\ndef load_model(path):\n with open(path, 'rb') as f:\n return pickle.load(f)","language":"python"}}
Response interpretation:
Each issue includes: ruleKey, severity, clean code attribute, impact category, line number, quick fix availability
Address CRITICAL and HIGH severity issues before committing
Use show_rule with the ruleKey value for any unfamiliar rule
Step 5: Rule Education
Use show_rule to understand why a rule exists and how to fix flagged code.
Parameters:
key (string) — Rule key in format <language>:<rule-id> (e.g., typescript:S1082, java:S2068)
If gate fails: Extract failing conditions, present them to the user, then use search_sonar_issues_in_projects filtered by the same PR to show the actual issues.
Example 2: Shift-Left Analysis Before Push
User request: "Analyze this Go function before I push it"
{"name":"analyze_code_snippet","arguments":{"projectKey":"my-go-service","fileContent":"func handler(w http.ResponseWriter, r *http.Request) {\n id := r.URL.Query().Get(\"id\")\n query := fmt.Sprintf(\"SELECT * FROM orders WHERE id = %s\", id)\n rows, _ := db.Query(query)\n // ...\n}","language":"go"}}
Present findings → for each issue, optionally call show_rule with the ruleKey value to explain the fix.
Example 3: Triage BLOCKER Issues in a Project
User request: "Show me all blocker issues in payment-service"
SonarCloud and SonarQube Server APIs are mostly compatible but some features differ; check references/llm-context.md
Pagination is required for projects with many issues; check paging.total and paging.pageSize in the response to determine whether to iterate further pages
Quality gate status reflects the last completed analysis — trigger a new analysis if the code has changed
