sonarqube-api-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SONAR_TOKEN | Yes | SonarQube token. Sent as Basic Auth using Authorization: Basic base64("${SONAR_TOKEN}:"). | |
| SONAR_HOST_URL | Yes | SonarQube base URL. Trailing slashes are normalized. | |
| SONAR_PROJECT_KEY | No | Default project key used by project-scoped tools when projectKey and projectName are omitted. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_sonar_issuesC | Search read-only SonarQube issues through /api/issues/search. |
| get_quality_gate_statusC | Get read-only SonarQube quality gate status for a project. |
| get_rule_detailsC | Get read-only SonarQube rule details. |
| get_component_measuresC | Get read-only SonarQube component measures for metric keys. |
| get_sonar_sourcesA | Get read-only SonarQube source lines for a component. |
| search_sonar_projectsB | Find SonarQube project keys by project name or key. |
| get_sonar_issue_contextB | Get one SonarQube issue with source lines around the affected range. |
| get_sonar_fix_planA | Return unresolved SonarQube issues grouped by file with optional source context for fixing new-code or overall-code issues. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool targets a distinct aspect of SonarQube (measures, quality gate, rules, issues, sources, projects) with no overlapping purposes. An agent can clearly differentiate between them.
Tools mostly follow a verb_noun pattern, but there is inconsistency in the use of the 'sonar' prefix: some include it (get_sonar_fix_plan) while others do not (get_component_measures). This mixed style reduces clarity.
Eight tools is well-scoped for a SonarQube API server, covering the core read operations without being excessive or insufficient.
The tool surface covers essential read-only operations (measures, quality gate, rules, issues, sources, projects). Minor gaps like a dedicated list_rules tool are present, but agents can work around using search_sonar_issues.