sonar-list-issues

name	sonar-list-issues
description	Search and filter SonarQube issues for a project, branch, or pull request via the SonarQube MCP Server (project key optional when MCP integration already defines the default project)
argument-hint	[project-key?] [--severity values] [--qualities values] [--statuses values] [--rules values] [--component path] [--branch name] [--pr id]

SonarQube — List Issues

Search for issues (bugs, vulnerabilities, code smells) in a SonarQube project using the SonarQube MCP Server.

Usage

sonar-list-issues                                          # issues in the current project
sonar-list-issues my-project                               # issues in a specific project key
sonar-list-issues my-project --severity HIGH,BLOCKER       # filter by severity
sonar-list-issues my-project --qualities SECURITY          # filter by software quality
sonar-list-issues my-project --statuses OPEN,CONFIRMED     # filter by status
sonar-list-issues my-project --rules python:S2077          # filter by rule key
sonar-list-issues my-project --component src/auth/login.py # issues in a specific file
sonar-list-issues my-project --pr 42                       # on a pull request

Prerequisites

This skill requires the SonarQube MCP Server to be configured and the tool mcp__sonarqube__search_sonar_issues_in_projects to be available in your session.

If a tool fails due to authentication problems, ask the user to ensure they have given their consent for automatic token exchange through SonarQube Cloud > My Account > Access Tokens > Agent Apps. Otherwise surface the tool error verbatim and stop.

Instructions

Step 1: Resolve the project key (only when needed)

MCP tools sometimes do not require projectKey when the SonarQube MCP Server has a default project for this workspace (e.g. SONARQUBE_PROJECT_KEY configured in the server env). Resolve a key only when you must pass it (tool schema requires it, or the user targets another project):

• If the user provided a project key, use it.
• Otherwise look for sonar.projectKey in sonar-project.properties at the repo root.
• If still not found, omit projects in the MCP call and rely on the integration default.

Step 2: Parse optional flags from the user-provided arguments

Flag	Maps to MCP parameter
--severity <values>	severities (array)
--qualities <values>	impactSoftwareQualities (array)
--statuses <values>	issueStatuses (array)
--rules <values>	(filter client-side from response)
--component <path>	files (array; file key project-key:src/...)
--branch <name>	(not supported on this tool — see note)
--pr <id>	pullRequestId
--page <n>	p
--page-size <n>	ps (1–500, default 100)

When --component is given as a plain path, prepend the resolved project key (when you have one) to form the component key (e.g. my-project:src/auth/login.py).

Note on --branch: mcp__sonarqube__search_sonar_issues_in_projects does not expose a branch parameter directly. If the user passes --branch, tell them branch filtering is not supported on this MCP tool and offer to run the query against the default branch or a pull request instead.

Step 3: Validate arguments

Before building the call, validate each user-supplied value against the rules below. If any value fails validation, stop and tell the user what was rejected and why — do not run the call. Validate the resolved project key (from args or sonar-project.properties) against the project-key pattern before sending it.

Argument	Allowed pattern / values
project key	^[a-zA-Z0-9_\-\.:]+$
--severity	comma-separated subset of: INFO, LOW, MEDIUM, HIGH, BLOCKER
--qualities	comma-separated subset of: MAINTAINABILITY, RELIABILITY, SECURITY
--statuses	comma-separated subset of: OPEN, CONFIRMED, FALSE_POSITIVE, ACCEPTED, FIXED
--rules	comma-separated values matching ^[a-zA-Z0-9_\-:]+$
--component	path matching ^[a-zA-Z0-9_\-\./:,]+$
--pr	digits only
--page	positive integer
--page-size	integer 1–500

Step 4: Call mcp__sonarqube__search_sonar_issues_in_projects

Include projects only if you resolved a project key in Step 1 and you want to target a non-default project; otherwise omit it and rely on the integration default.

{
  "projects": ["<only-if-needed>"],
  "severities": ["HIGH", "BLOCKER"],
  "impactSoftwareQualities": ["SECURITY"],
  "issueStatuses": ["OPEN"],
  "files": ["<project-key>:src/auth/login.py"],
  "pullRequestId": "<id>",
  "p": 1,
  "ps": 100
}

Omit any field that was not requested by the user. If --rules was given, filter the returned issues client-side by rule matching one of the supplied rule keys.

Step 5: Format the results

If issues are found, present a summary line then a table sorted by severity then line number:

## SonarQube Issues — `my-project`

Found **12 issue(s)**:

| File                 | Line | Severity  | Rule         | Message                       |
| -------------------- | ---- | --------- | ------------ | ----------------------------- |
| src/auth/login.py    | 12   | 🔴 Blocker | python:S2077 | SQL injection risk            |
| src/utils/helpers.py | 34   | 🟠 Critical / High | python:S2259 | Null dereference              |
| src/api/routes.py    | 67   | 🟡 Medium  | python:S3776 | Cognitive complexity too high |

Severity icons (the label depends on the server version):

• 🔴 Blocker
• 🟠 Critical / High
• 🟡 Major / Medium
• 🔵 Minor / Low
• ⚪ Info

If the response is paginated and more issues exist, mention the next page (e.g. "Showing page 1 of N. Re-run with --page 2 to see more.").

If no issues are found:

## SonarQube Issues — `my-project`

✅ No issues found.

Step 6: Next steps

• To fix a specific issue: "Invoke the sonar-fix-issue skill with <rule> <file>:<line>."
• To check the quality gate: "Invoke the sonar-quality-gate skill."