Provides tools for fetching SonarCloud issues related to pull requests, with the ability to filter by organization, project, PR number, and issue status, supporting authentication via API token.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SonarCloud MCP Server fetch open issues for PR #42 in my-org/my-project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that provides tools for fetching SonarCloud issues related to pull requests.
Example prompt:
Fetch the list of OPEN or ACCEPTED issues from sonarcloud for this PR, which are assigned to __me__, fix them and push the changes to this PR.
Emphasis on the __me__ part, which is a special value in the sonarcloud API to reference the current user (token owner). You can stick this in your .claude/tools folder as sonarcloud-issues.md to have a shortcut which requests claude code to fetch and fix issues from SonarCloud.
Fetch issues from SonarCloud for specific pull requests
Filter by organization, project, and PR number
Supports authentication via API token
Returns formatted issue data with severity, type, and location information
Related MCP server: SonarQube MCP Server
Follow the instructions in the SonarCloud documentation to generate a SonarCloud API token.
# Build the Docker image
npm run docker:build
# Or build directly
docker build -t sonarcloud-mcp .npm ci
npm run buildRun via docker:
docker run -i --rm \
-e SONARCLOUD_TOKEN=your_token_here \
-e SONARCLOUD_ORGANISATION=your_organisation_here \
-e SONARCLOUD_PROJECT_KEY=your_project_key_here \
sonarcloud-mcpExport the required environment variables and run the server:
export SONARCLOUD_TOKEN=your_token_here
export SONARCLOUD_ORGANISATION=your_organisation_here
export SONARCLOUD_PROJECT_KEY=your_project_key_here
npm startSONARCLOUD_TOKEN: Your SonarCloud API token (required)j
SONARCLOUD_ORGANISATION: Your SonarCloud organization key (optional, can be passed as a parameter)
SONARCLOUD_PROJECT_KEY: Your SonarCloud project key (optional, can be passed as a parameter)
Add to your claude_desktop_config.json or claude.json:
{
"mcpServers": {
"sonarcloud": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"SONARCLOUD_TOKEN",
"-e",
"SONARCLOUD_ORGANISATION",
"-e",
"SONARCLOUD_PROJECT_KEY",
"sonarcloud-mcp"
],
"env": {
"SONARCLOUD_TOKEN": "<your token here>",
"SONARCLOUD_ORGANISATION": "<your organisation here>",
"SONARCLOUD_PROJECT_KEY": "<your project key here>"
}
}
}
}Add to your claude_desktop_config.json or claude.json:
{
"mcpServers": {
"sonarcloud-mcp": {
"command": "node",
"args": [
"/path/to/sonarcloud_mcp/dist/index.js"
],
"env": {
"SONARCLOUD_TOKEN": "<your token here>",
"SONARCLOUD_ORGANISATION": "<your organisation here>",
"SONARCLOUD_PROJECT_KEY": "<your project key here>"
}
}
}
}fetch_sonarcloud_issues: Fetches SonarCloud issues for a specific pull request.
Fetch SonarCloud issues for a specific pull request
| Name | Required | Description | Default |
|---|---|---|---|
| additionalFields | No | Comma-separated list of the optional fields to be returned in response. Action plans are dropped in 5.5, it is not returned in the response. | |
| asc | No | Ascending sort (default: true) | |
| assigned | No | To retrieve assigned or unassigned issues | |
| assignees | No | Comma-separated list of assignee logins. The value '__me__' can be used as a placeholder for user who performs the request | |
| author | No | SCM accounts. To set several values, the parameter must be called once for each value. | |
| branch | No | Branch key | |
| cleanCodeAttributeCategories | No | Comma-separated list of clean code attribute categories. | |
| componentKeys | No | Comma-separated list of component keys. Retrieve issues associated to a specific list of components (and all its descendants). A component can be a project, directory or file. | |
| createdAfter | No | To retrieve issues created after the given date (inclusive). Either a date (server timezone) or datetime can be provided. If this parameter is set, createdSince must not be set | |
| createdAt | No | Datetime to retrieve issues created during a specific analysis | |
| createdBefore | No | To retrieve issues created before the given date (inclusive). Either a date (server timezone) or datetime can be provided. | |
| createdInLast | No | To retrieve issues created during a time span before the current time (exclusive). Accepted units are 'y' for year, 'm' for month, 'w' for week and 'd' for day. If this parameter is set, createdAfter must not be set | |
| cwe | No | Comma-separated list of CWE identifiers. Use 'unknown' to select issues not associated to any CWE. | |
| facets | No | Comma-separated list of the facets to be computed. No facet is computed by default. | |
| impactSeverities | No | Comma-separated list of impact severities. | |
| impactSoftwareQualities | No | Comma-separated list of software qualities. | |
| issueStatuses | No | Comma-separated list of issue statuses | |
| issues | No | Comma-separated list of issue keys | |
| languages | No | Comma-separated list of languages. Available since 4.4 | |
| onComponentOnly | No | Return only issues at a component's level, not on its descendants (modules, directories, files, etc). This parameter is only considered when componentKeys or componentUuids is set. (default: false) | |
| organization | No | Organization key | |
| owaspTop10 | No | Comma-separated list of OWASP Top 10 lowercase categories. | |
| owaspTop10-2021 | No | Comma-separated list of OWASP Top 10 - 2021 lowercase categories. | |
| p | No | 1-based page number (default: 1) | |
| ps | No | Page size. Must be greater than 0 and less or equal than 500 (default: 100) | |
| pullRequest | No | Pull request id | |
| resolved | No | To match resolved or unresolved issues | |
| rules | No | Comma-separated list of coding rule keys. Format is <repository>:<rule> | |
| s | No | Sort field | |
| sinceLeakPeriod | No | To retrieve issues created since the leak period. If this parameter is set to a truthy value, createdAfter must not be set and one component id or key must be provided. (default: false) | |
| sonarsourceSecurity | No | Comma-separated list of SonarSource security categories. Use 'others' to select issues not associated with any category | |
| tags | No | Comma-separated list of tags. | |
| token | No | SonarCloud API token (optional if set in environment) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects, required authentication, rate limits, pagination behavior (though the schema includes p and ps), or what happens when no criteria are specified. The description is too sparse to inform the AI about critical runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but omits essential information for a tool with 33 parameters. It is not front-loaded with the most important usage details. While every word is justified, the overall structure fails to earn its place due to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex input schema with 33 parameters, no output schema, and no annotations. The description only covers one use case (pull request) and does not mention common filtering patterns, response structure, or limitations. It is not adequate for an AI to understand the full scope and proper invocation of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides. For example, it does not highlight that 'pullRequest' is a key parameter or explain how it interacts with other filters. The schema itself is well-documented, so the description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource 'SonarCloud issues' with a qualifier 'for a specific pull request'. However, this is overly narrow because the tool supports filtering by many other criteria (branch, componentKeys, etc.), not only pull requests. The purpose is clear but misleadingly constrained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'summarize_sonarcloud_issues'. There is no mention of when not to use it, prerequisites, or context-dependent preferences. The lack of usage direction forces the AI to infer from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a high-level summary of SonarCloud issues for a PR
| Name | Required | Description | Default |
|---|---|---|---|
| pullRequest | No | Pull request id | |
| token | No | SonarCloud API token (optional if set in environment) | |
| impactSeverities | No | Comma-separated list of impact severities. | |
| sinceLeakPeriod | No | To retrieve issues created since the leak period. If this parameter is set to a truthy value, createdAfter must not be set and one component id or key must be provided. (default: false) | |
| issueStatuses | No | Comma-separated list of issue statuses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations. Description does not disclose whether the tool modifies state, requires authentication beyond token (optional in schema), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no redundant information. Efficient but perhaps too brief for a 5-param tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lacks details about the output format, what 'high-level summary' means, and any prerequisites. Despite full schema coverage, the return value and usage constraints are unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover 100% of parameters. The tool description adds no additional semantic meaning for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'high-level summary of SonarCloud issues', and the scope 'for a PR', distinguishing it from the sibling tool 'fetch_sonarcloud_issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this summary tool vs the sibling 'fetch_sonarcloud_issues'. Lacks explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0fetch_sonarcloud_issuessummarize_sonarcloud_issuesThe two tools have clearly distinct purposes: one fetches issues, the other provides a summary. There is no overlap or ambiguity between them.
Both tools follow a consistent 'verb_noun' naming pattern (fetch_sonarcloud_issues, summarize_sonarcloud_issues), making the naming predictable and clear.
With only 2 tools, the server feels thin. While it may serve a narrow purpose, the tool count is at the borderline of being insufficient for a typical server scope.
The tools cover fetching and summarizing issues for a PR, but are missing operations like retrieving details for a single issue or listing all issues for a project. The surface is notably incomplete for broader SonarCloud operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
The Jam MCP server provides AI tools with instant bug context without manual prompting, enabling a streamlined workflow from bug identification to ticket creation and pull request generation without switching between tools.
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dozzman/sonarcloud-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
