sonar-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SONAR_URL | Yes | Base URL of the SonarQube instance, e.g. https://sonar.example.com | |
| SONAR_TOKEN | Yes | SonarQube user token (My Account -> Security -> Generate Tokens) | |
| SONAR_DEFAULT_PROJECT_KEY | No | Project key used when a tool call does not name one |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| getHotspotA | Get one Security Hotspot. Returns review details, rule guidance, locations, flows, and changelog. |
| listHotspotsA | List project Security Hotspots that need human review. Defaults to |
| getIssueA | Get one issue by key. Returns full issue details and changelog, including status and assignment history. Scope explicitly: omitting both |
| getIssueSnippetsA | Get Sonar-analysed source snippets for all issue locations, including cross-file flows. Returns component path, language, code lines, and SCM metadata. Use when local source is unavailable or may differ from the analysed ref. Scope explicitly: omitting both |
| getProjectIssuesBreakdownA | Count project issues by logical module and rule; intended for multi-module projects. A module is the first |
| getProjectIssuesSummaryA | Count project issues and group them by severity, type, status, rule, tag, and SCM author. Returns the total and facet counts; use before listing details. Scope explicitly: omitting both |
| listIssuesA | List project issues with optional severity, type, status, rule, path, and ref filters. Returns rule, severity, type, status, message, file location/text range, and cross-file flows. Defaults to open issues. Scope explicitly: omitting both |
| getProjectA | Get one project analysis. Returns project metadata, quality gate failures, and metrics for size, findings, coverage, duplication, and technical debt. Scope explicitly: omitting both |
| listComponentsA | Browse or search a project's analysed component tree. Use returned |
| listProjectBranchesA | List analysed project branches. Returns name, main/type flags, analysis date, quality gate, and issue counts; use the name as |
| listProjectPullRequestsA | List project PR analyses. Returns key, title, source/base branches, URL, analysis date, quality gate, and issue counts; use the key as |
| listProjectsA | List projects, optionally filtered by name. Returns key, name, and qualifier; use the key as |
| getRuleA | Get a Sonar rule. Returns title, severity, type, language, tags, and structured explanation and fix sections. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review-pull-request | Produce a PR review report from Sonar's PR analysis: quality-gate verdict, new issues introduced by the PR (with top rules and most-affected files), security hotspots flagged for review, and a merge recommendation. Use this when reviewing a PR before merge. |
| fix-file | Build a flat fix checklist for SonarQube findings in ONE file: line-by-line list with rule context, snippets fetched for every issue (so you see exactly what Sonar saw), and explicit cross-file impact. Use when the work is concentrated in one file. |
| analyze-path | Fast situational read of SonarQube findings in a project or path: severity/type breakdown, top rules, most-affected files, and security hotspots. Use this first to estimate the scope of work before drilling into individual issues. |
| fix-path | Build an actionable fix plan for SonarQube findings under a path (directory or subtree). Groups issues by file, looks up rule guidance once per unique rule, and surfaces common fix patterns. Use when you have a directory to clean up. |
| investigate-issue | Deep analysis of one Sonar issue: full issue details with changelog, the rule's full description (root cause + how-to-fix + resources), code snippets across all locations including cross-file flows, and a structured report with a concrete fix recommendation. Use when someone hands you an issue key and asks 'what is this and how do I fix it?'. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool targets a distinct resource and action (get/list for project, issue, hotspot, rule, components, branches, PRs). The three issue-related tools are clearly differentiated: listIssues returns details, getProjectIssuesSummary returns aggregate facets, and getProjectIssuesBreakdown groups by module/rule.
All tool names follow a consistent getX/listX pattern in camelCase, with nouns clearly indicating the resource. No mixing of conventions or vague verbs.
13 tools is well within the ideal 3-15 range and each tool covers a specific aspect of SonarQube analysis (projects, issues, hotspots, rules, branches, PRs, components). No redundancy or bloat.
Core read-only analysis workflows are well covered: project metrics, issue list/detail/snippets/aggregations, hotspot handling, and branch/PR scoping. Minor gaps include no listRules (only getRule) and no write actions (e.g., issue assignment or hotspot review), but these are not central to an analysis-focused server.