Sonarqube Mcp

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

Trigger phrases: "check quality gate", "sonarqube quality gate", "find sonar issues", "search sonar issues", "analyze code with sonar", "check sonar rule", "sonarcloud issues", "pre-push sonar check", "sonar pre-commit"

Prerequisites and Setup

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)

Quick Start

1. Set your SonarQube/SonarCloud credentials:

   # SonarQube Server
   export SONARQUBE_TOKEN="squ_your_token"
   export SONARQUBE_URL="https://sonarqube.mycompany.com"

   # SonarCloud
   export SONARQUBE_TOKEN="squ_your_token"
   export SONARQUBE_ORG="your-org-key"

2. Verify MCP tool availability:

• Tool names follow the pattern: mcp__sonarqube-mcp__<tool-name>

3. If the MCP server fails to start, check:

• Docker is running
• Environment variables are set
• Reference: mcp/sonarqube on Docker Hub

Reference Documents

• references/metrics.md — Common SonarQube metrics and their meaning
• references/severity-levels.md — Sonar severity levels and impact categories
• references/best-practices.md — Workflows for PR checks and pre-commit analysis
• references/llm-context.md — Tool selection guide and parameter mapping for LLM agents

Instructions

Step 1: Identify the Required Operation

Determine which operation the user needs:

If the user's intent is ambiguous, ask for the project key and the goal before proceeding.

Step 2: Quality Gate Monitoring

Use get_project_quality_gate_status to verify a project meets its quality standards.

Parameters:

• projectKey (string) — Project key in SonarQube/SonarCloud
• pullRequest (string, optional) — Pull request ID for PR-specific gate check
• analysisId (string, optional) — Specific analysis ID

Note: There is no branch parameter on this tool. Without a pullRequest or analysisId, the tool returns the quality gate status for the default branch.

Pattern — Check default branch gate:

{
  "name": "get_project_quality_gate_status",
  "arguments": {
    "projectKey": "my-application"
  }
}

Pattern — Check PR gate before merge:

{
  "name": "get_project_quality_gate_status",
  "arguments": {
    "projectKey": "backend-service",
    "pullRequest": "456"
  }
}

Interpreting the response:

• status: "OK" — Gate passed, safe to merge/deploy
• status: "ERROR" — Gate failed; check conditions array for failing metrics
• Each condition shows: metricKey, actualValue, errorThreshold, comparator

For more on metric keys, see references/metrics.md.

Step 3: Issue Discovery and Triaging

Use search_sonar_issues_in_projects to find and prioritize issues.

Parameters:

• projects (array, optional) — List of project keys; omit to search all accessible projects
• severities (array, optional) — Filter: BLOCKER, HIGH, MEDIUM, LOW, INFO
• pullRequestId (string, optional) — Limit search to a specific PR
• p (integer, optional) — Page number (default: 1)
• ps (integer, optional) — Page size (default: 100, max: 500)

Pattern — Find blockers and critical issues:

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["my-backend", "my-frontend"],
    "severities": ["BLOCKER", "HIGH"],
    "p": 1,
    "ps": 50
  }
}

Pattern — Search issues in a PR:

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["my-service"],
    "pullRequestId": "123",
    "severities": ["HIGH", "MEDIUM"],
    "p": 1,
    "ps": 100
  }
}

Managing issues with `change_sonar_issue_status`:

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

Supported languages: javascript, typescript, python, java, go, php, cs, cpp, kotlin, ruby, scala, swift

Pattern — Analyze TypeScript file before commit:

{
  "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)

Pattern — Get rule documentation:

{
  "name": "show_rule",
  "arguments": {
    "key": "typescript:S1082"
  }
}

Response includes: rule name, type, severity, full description, tags (e.g., cwe, owasp-a2), language, remediation effort estimate, code examples (non-compliant vs compliant).

Step 6: Get Component Measures

Use get_component_measures to retrieve detailed metrics for a project, directory, or file.

Parameters:

• projectKey (string) — Project key in SonarQube/SonarCloud
• pullRequest (string, optional) — PR ID for PR-scoped metrics
• metricKeys (array) — List of metric keys to retrieve

Common metric keys: coverage, bugs, vulnerabilities, code_smells, complexity, cognitive_complexity, ncloc, duplicated_lines_density, new_coverage, new_bugs

Pattern — Project health dashboard:

{
  "name": "get_component_measures",
  "arguments": {
    "projectKey": "my-project-key",
    "metricKeys": ["coverage", "bugs", "vulnerabilities", "code_smells", "ncloc"]
  }
}

For full metric reference, see references/metrics.md.

Step 7: Present Results to User

After each tool call:

• Summarize findings in human-readable form
• Flag issues that require attention (BLOCKER, HIGH severity)
• Propose next actions based on findings
• Wait for user confirmation before taking remediation steps (e.g., changing issue status, modifying code)

Examples

Example 1: Pre-Merge Quality Gate Check

User request: "Check if the quality gate passes for project backend-api on PR #234"

{
  "name": "get_project_quality_gate_status",
  "arguments": {
    "projectKey": "backend-api",
    "pullRequest": "234"
  }
}

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"

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["payment-service"],
    "severities": ["BLOCKER"],
    "p": 1,
    "ps": 50
  }
}

Group results by category (Security, Reliability, Maintainability) and present to user. Offer to call show_rule for unfamiliar rules.

Best Practices

1. Environment Setup — Set credentials once per session; the MCP server automatically picks them up 2. Always check quality gate before merge — Run get_project_quality_gate_status as part of any PR review workflow 3. Shift left on security issues — Use analyze_code_snippet during development, not only in CI 4. Prioritize by severity — Address BLOCKER and HIGH issues first; document decisions for MEDIUM and LOW 5. Use `show_rule` for unfamiliar keys — Never dismiss a rule without understanding its intent 6. Paginate large result sets — Use p and ps parameters; handle multi-page responses for complete coverage 7. Never change issue status autonomously — Always present issues to the user and get explicit confirmation before calling change_sonar_issue_status 8. Provide language hints — Specify language in analyze_code_snippet for more accurate analysis

Constraints and Warnings

• MCP server must be configured and running; verify tool availability before use
• analyze_code_snippet analyzes snippets in isolation — full project context may affect results in CI
• Issue status changes (false positive, won't fix) require appropriate SonarQube permissions
• 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

SonarQube MCP Best Practices

Workflows and patterns for integrating SonarQube quality checks into the development lifecycle.

PR Quality Gate Workflow

The recommended workflow for checking code quality before merging a pull request.

Step 1: Trigger PR Analysis

SonarQube analyzes PRs automatically when integrated with CI/CD. After CI runs, check the gate:

{
  "name": "get_project_quality_gate_status",
  "arguments": {
    "projectKey": "my-service",
    "pullRequest": "<pr-number>"
  }
}

Step 2: Evaluate Gate Status

If status: "OK" → safe to proceed with merge review.

If status: "ERROR": 1. Extract failing conditions from the conditions array 2. For each failing condition, identify the metric and gap (actual vs threshold) 3. Use search_sonar_issues_in_projects filtered by PR to surface the specific issues

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["my-service"],
    "pullRequestId": "<pr-number>",
    "severities": ["BLOCKER", "HIGH", "MEDIUM"],
    "p": 1,
    "ps": 100
  }
}

Step 3: Triage Issues

Group found issues by:

• Security (category: SECURITY) → highest priority
• Reliability (category: RELIABILITY) → bugs that affect behavior
• Maintainability (category: MAINTAINABILITY) → code smells

Present categorized summary to the developer before requesting changes.

Step 4: Verify Fix

After the developer pushes fixes, re-check the quality gate using the updated PR number or trigger a new analysis via CI.

---

Pre-Commit Analysis (Shift Left)

Catch issues before they reach the CI pipeline using analyze_code_snippet.

When to Use

• Before committing new functions or classes
• When refactoring security-sensitive code
• Before adding a new external dependency integration

Workflow

1. Extract the snippet — identify the function or module to analyze 2. Specify the language — always pass the language parameter for accuracy 3. Review findings — address CRITICAL and HIGH issues before committing 4. Learn from rules — use show_rule to understand unfamiliar findings

Multi-Language Examples

TypeScript (SQL injection check):

{
  "name": "analyze_code_snippet",
  "arguments": {
    "projectKey": "my-app",
    "fileContent":"async function getUser(id: string) {\n  const query = `SELECT * FROM users WHERE id = ${id}`;\n  return db.execute(query);\n}",
    "language": "typescript"
  }
}

Java (hardcoded credentials):

{
  "name": "analyze_code_snippet",
  "arguments": {
    "projectKey": "my-java-app",
    "fileContent":"public class DatabaseConfig {\n  private static final String PASSWORD = \"myS3cr3t\";\n  public Connection connect() { ... }\n}",
    "language": "java"
  }
}

Python (deserialization risk):

{
  "name": "analyze_code_snippet",
  "arguments": {
    "projectKey": "my-python-app",
    "fileContent":"import pickle\n\ndef load_session(data):\n    return pickle.loads(data)",
    "language": "python"
  }
}

Go (error ignored):

{
  "name": "analyze_code_snippet",
  "arguments": {
    "projectKey": "my-go-service",
    "fileContent":"func readFile(path string) []byte {\n  data, _ := os.ReadFile(path)\n  return data\n}",
    "language": "go"
  }
}

---

Issue Triage Workflow

Systematic approach to clearing a backlog of Sonar issues.

Step 1: Prioritize by Severity

Always start with BLOCKER issues, then CRITICAL/HIGH:

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["my-project"],
    "severities": ["BLOCKER"],
    "p": 1,
    "ps": 100
  }
}

Step 2: Understand Each Issue

For each unfamiliar rule, retrieve documentation:

{
  "name": "show_rule",
  "arguments": {
    "key": "java:S2068"
  }
}

Step 3: Fix or Document

Fix: Implement the recommended fix from rule documentation.

Accept (with reason):

{
  "name": "change_sonar_issue_status",
  "arguments": {
    "key": "AY1234",
    "status": "falsepositive",
    "comment": "This pattern is safe because input is validated upstream at the API boundary."
  }
}

Step 4: Verify Progress

After fixes, check the project health:

{
  "name": "get_component_measures",
  "arguments": {
    "projectKey": "my-project",
    "metricKeys": ["bugs", "vulnerabilities", "code_smells", "security_rating", "reliability_rating"]
  }
}

---

Continuous Quality Monitoring

For ongoing projects, establish a monitoring routine:

---

Security-Focused Workflow

When working on security-sensitive code (auth, payments, user data):

1. Run pre-commit analysis on every modified function 2. Check for OWASP-tagged issues after CI analysis 3. Review all category: SECURITY issues regardless of severity 4. Never mark security issues as FALSE-POSITIVE without team review

{
  "name": "search_sonar_issues_in_projects",
  "arguments": {
    "projects": ["my-service"],
    "pullRequestId": "<pr-number>",
    "p": 1,
    "ps": 100
  }
}

Then filter the response for "category": "SECURITY" entries and review all of them, starting from BLOCKER.

---

Quality Gate Failure Resolution Checklist

When a quality gate fails on a PR:

• [ ] Identify all failing conditions in conditions array
• [ ] Search issues filtered by PR to find root causes
• [ ] Group issues by category (Security, Reliability, Maintainability)
• [ ] Fix BLOCKER and CRITICAL/HIGH issues
• [ ] For MEDIUM/LOW: fix if quick, else document in PR description
• [ ] Re-run CI to trigger new Sonar analysis
• [ ] Re-check quality gate status after fix
• [ ] Do not merge until status: "OK"

SonarQube MCP — LLM Tool Selection Guide

Optimized context for LLM agents to select the right MCP tool, map parameters, and interpret responses efficiently.

Tool Selection Decision Tree

User wants to...
├── check if code is ready to merge/deploy
│   └── get_project_quality_gate_status (projectKey + pullRequest)
│
├── find issues in a project or PR
│   └── search_sonar_issues_in_projects (projects + severities + pullRequestId)
│
├── analyze code before committing
│   └── analyze_code_snippet (projectKey + fileContent + language)
│
├── understand why a rule flagged code
│   └── show_rule (key: "<language>:<rule-id>")
│
├── get project health metrics (coverage, bugs, etc.)
│   └── get_component_measures (projectKey + metricKeys)
│
└── accept or dismiss a specific issue
    └── change_sonar_issue_status (key + status + comment)

Tool Quick Reference

get_project_quality_gate_status

Purpose: Verify if a project passes its defined quality gate.

Required: one of projectKey, projectId, or analysisId

Optional: pullRequest (string, PR number as string)

Note: No branch parameter exists on this tool. Without pullRequest or analysisId, the default branch status is returned.

Key output fields:

• projectStatus.status — "OK" or "ERROR" (or "WARN" in older versions)
• projectStatus.conditions[] — array of conditions, each with metricKey, status, actualValue, errorThreshold, comparator

When to use: Before merge decisions, deployment gates, release checks.

---

search_sonar_issues_in_projects

Purpose: Find and filter issues across projects.

All parameters optional — omit projects to search all accessible projects.

Key parameters:

• projects — ["project-key-1", "project-key-2"]
• severities — ["BLOCKER", "HIGH", "MEDIUM", "LOW", "INFO"]
• pullRequestId — string (PR number), not integer
• p — page number (start at 1)
• ps — page size (default: 100, max: 500)

Key output fields per issue:

• key — unique issue ID (used in change_sonar_issue_status)
• rule — rule key (used in show_rule); note: field is named ruleKey in analyze_code_snippet responses
• severity — legacy severity value
• status — current issue status (display only; use change_sonar_issue_status to change it)
• message — human-readable description
• attribute — clean code attribute
• category — SECURITY, RELIABILITY, MAINTAINABILITY
• component — file path within the project
• startLine, endLine — location in the file

Pagination: Check paging.total and paging.pageSize in response; iterate p while paging.pageIndex * paging.pageSize < paging.total.

When to use: Issue triage, PR review, sprint cleanup, security audits.

---

analyze_code_snippet

Purpose: Run SonarQube analysis on a raw code string without CI.

Required: projectKey, fileContent (full file content as string)

Optional: language (always specify for best accuracy), codeSnippet (narrow results to a sub-range of the file)

Language values: javascript, typescript, python, java, go, php, cs (C#), cpp, kotlin, ruby, scala, swift

Key output fields per issue:

• ruleKey — use with show_rule for explanation (note: rule in search_sonar_issues_in_projects, ruleKey here)
• severity — issue severity
• cleanCodeAttribute — clean code attribute
• impacts — object mapping quality dimension to severity level
• startLine — line number in the file
• quickFixes — boolean, whether a quick fix is available

Limitations:

• Analyzes file content in isolation, without full project context
• Some rules require cross-file analysis and will not fire
• Results may differ slightly from full CI analysis

When to use: Shift-left review, pre-commit checks, code review assistance.

---

show_rule

Purpose: Retrieve full documentation for a SonarQube rule.

Required: key in format <language>:<rule-id>

Language prefixes: java, javascript, typescript, python, go, php, cs, cpp, kotlin, ruby

Examples: java:S2068, typescript:S1082, python:S5659, go:S4036

Key output fields:

• name — human-readable rule name
• type — BUG, VULNERABILITY, CODE_SMELL, SECURITY_HOTSPOT
• severity — legacy severity
• description — full explanation of the risk and rationale
• tags — standards: cwe, owasp-a1, sans-top25, cert
• remediationEffort — time estimate for fix (e.g., "30min")
• codeExamples — array with noncompliant and compliant code examples

When to use: After finding an unfamiliar rule key, before dismissing an issue, for developer education.

---

get_component_measures

Purpose: Retrieve specific metrics for a project, directory, or file.

Required: projectKey (project key), metricKeys (array)

Optional: pullRequest (string, for PR-scoped metrics)

Note: No branch parameter exists on this tool.

Common metric key groups:

Overall health: bugs, vulnerabilities, code_smells, coverage, duplicated_lines_density, ncloc

Ratings: reliability_rating, security_rating, sqale_rating

New code only: new_bugs, new_vulnerabilities, new_coverage, new_duplicated_lines_density

Complexity: complexity, cognitive_complexity

When to use: Project health dashboards, sprint reviews, release readiness checks.

---

change_sonar_issue_status

Purpose: Update the status of a specific issue.

Required: key (issue key from search_sonar_issues_in_projects response field key), status

Valid status values: falsepositive, accept, reopen

Optional: comment (strongly recommended — always document the reason)

Requires: SonarQube user permissions to change issue status.

When to use: Issue triage sign-off, false positive management, technical debt acknowledgment.

Never call this tool without explicit user confirmation and a documented reason.

---

Common Agent Patterns

Pattern 1: Gate + Issues (PR review)

1. get_project_quality_gate_status (projectKey, pullRequest)
2. If status == "ERROR":
   a. search_sonar_issues_in_projects (projects, pullRequestId)
   b. Group by category, present to user
   c. For unfamiliar rules: show_rule (key)

Pattern 2: Shift-Left (pre-commit)

1. analyze_code_snippet (projectKey, fileContent, language)
2. For each finding:
   a. show_rule (ruleKey) if severity >= HIGH or rule is unfamiliar
3. Present findings, propose fixes
4. Wait for user to apply fixes before commit

Pattern 3: Project Triage

1. search_sonar_issues_in_projects (projects, severities: ["BLOCKER"])
2. For each BLOCKER: show_rule (rule) to get remediation
3. Repeat for HIGH, MEDIUM
4. get_component_measures (projectKey, metricKeys: [...ratings]) for overall health

Pattern 4: Release Gate Check

1. get_project_quality_gate_status (projectKey)
2. get_component_measures (projectKey, metricKeys: ["bugs", "vulnerabilities", "coverage"])
3. Report combined gate + metrics summary

Parameter Mapping Cheatsheet

SonarQube Server vs SonarCloud Differences

If the user's project key contains an underscore and appears to follow org_repo format, it is likely a SonarCloud project.

SonarQube Metrics Reference

Common SonarQube metrics used in quality gate conditions and component measures.

Reliability Metrics

Security Metrics

Maintainability Metrics

Coverage Metrics

Duplication Metrics

Size and Complexity Metrics

Rating Scale

Ratings are assigned from A (best) to E (worst):

Quality Gate Condition Operators

When interpreting quality gate conditions:

Example Quality Gate Response

{
  "projectStatus": {
    "status": "ERROR",
    "conditions": [
      {
        "status": "ERROR",
        "metricKey": "new_coverage",
        "comparator": "LT",
        "errorThreshold": "80",
        "actualValue": "65.2"
      },
      {
        "status": "OK",
        "metricKey": "new_bugs",
        "comparator": "GT",
        "errorThreshold": "0",
        "actualValue": "0"
      },
      {
        "status": "ERROR",
        "metricKey": "new_duplicated_lines_density",
        "comparator": "GT",
        "errorThreshold": "3",
        "actualValue": "5.8"
      }
    ]
  }
}

Reading the response:

• new_coverage failed: actual 65.2% is below the required 80% minimum
• new_bugs passed: 0 new bugs, gate requires 0
• new_duplicated_lines_density failed: 5.8% duplication exceeds 3% threshold

SonarQube Severity Levels Reference

Complete reference for Sonar severity levels, impact categories, and clean code attributes.

Legacy Severity Levels

The traditional SonarQube severity model used five levels:

New Severity Model (SonarQube 10+)

Newer versions use a Clean Code taxonomy with impact (severity on quality) and likelihood dimensions.

Impact Categories

HIGH — Significant negative effect; must be addressed promptly MEDIUM — Moderate effect; should be scheduled for resolution LOW — Minor effect; can be deferred to routine maintenance

Quality Dimensions

Clean Code Attributes

Issues are also tagged with a clean code attribute explaining why the code is problematic:

Filtering by Severity in MCP Tools

Use ONLY these values in the `severities` API parameter for search_sonar_issues_in_projects:

{
  "severities": ["BLOCKER", "HIGH", "MEDIUM", "LOW", "INFO"]
}

Important: The legacy labels CRITICAL, MAJOR, MINOR may appear in display text and older Sonar documentation, but they are not valid filter values for the severities API parameter. CRITICAL → use HIGH, MAJOR → use MEDIUM, MINOR → use LOW.

Triage Decision Matrix

Use this matrix to decide how to handle each issue:

Issue Statuses for change_sonar_issue_status

The key parameter is the issue's key field from search_sonar_issues_in_projects.

Always require explicit user confirmation before changing issue status. Document the reason in the comment field.

Security Rule Tags

Security-related rules are tagged with industry standard references:

Use show_rule with the rule key to see all tags and their implications.

Example Issue Response

{
  "key": "AY1234",
  "rule": "java:S2068",
  "project": "payment-service",
  "component": "src/main/java/PaymentService.java",
  "severity": "BLOCKER",
  "status": "OPEN",
  "message": "Remove this hard-coded password",
  "attribute": "TRUSTWORTHY",
  "category": "SECURITY",
  "startLine": 45,
  "endLine": 45,
  "created": "2025-01-15T10:30:00Z"
}

Reading this response:

• severity: BLOCKER + category: SECURITY → must fix before any release
• rule: java:S2068 → use show_rule with key java:S2068 to get remediation guidance
• attribute: TRUSTWORTHY → clean code violation related to security trustworthiness