Supports SonarCloud via organization filtering, enabling similar capabilities as SonarQube for cloud-based code quality and security analysis.
Provides tools for interacting with SonarQube to list projects, retrieve project metrics, manage code quality issues, analyze security vulnerabilities, check quality gates, and view historical analysis trends.
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., "@SonarQube MCP Server Show quality metrics for project 'my-app'"
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.
A Model Context Protocol (MCP) server that provides AI assistants with access to SonarQube code quality, security, and project analytics data.
Project Listing: Get comprehensive project information with quality metrics
Project Metrics: Fetch detailed quality metrics including coverage, duplication, maintainability
Issue Management: List and analyze code quality issues with filtering capabilities
Security Analysis: Get detailed security vulnerability and hotspot information
Quality Gates: Check quality gate status and conditions
Historical Analysis: View project evolution and quality trends over time
Related MCP server: sonarqube-mcp
# Global installation
npm install -g mcp-sonarqube
# Local installation in your project
npm install mcp-sonarqubeClone the repository:
git clone https://github.com/akhilthomas236/sonarqube-mcp-npm.git
cd sonarqube-mcpInstall dependencies:
npm installBuild the project:
npm run buildnpm install -g mcp-sonarqubeexport SONARQUBE_URL="http://your-sonarqube-instance:9000"
export SONARQUBE_TOKEN="your-sonarqube-token"mcp-sonarqubeCreate .vscode/mcp.json in your workspace:
{
"servers": {
"sonarqube": {
"command": "npx",
"args": ["mcp-sonarqube"],
"env": {
"SONARQUBE_URL": "http://localhost:9000",
"SONARQUBE_TOKEN": "your-sonarqube-token-here"
}
}
}
}Then use with GitHub Copilot:
@copilot List all projects in our SonarQube instance
@copilot Show me quality metrics for project "my-app"
@copilot What are the critical security vulnerabilities in project "api-service"?Log in to your SonarQube instance
Go to User > My Account > Security
Generate a new token with appropriate permissions
Use this token as your SONARQUBE_TOKEN
npm startThe server runs on stdio transport and communicates via the Model Context Protocol.
list_projectsLists all projects in your SonarQube instance with key metrics.
Parameters:
search (optional): Filter projects by name or key
qualityGate (optional): Filter by quality gate status (OK, WARN, ERROR)
organization (optional): Filter by organization (SonarCloud)
get_project_metricsGet comprehensive metrics for a specific project.
Parameters:
projectKey (required): The SonarQube project key
branch (optional): Branch name (defaults to main branch)
metrics (optional): Comma-separated list of specific metrics
list_issuesList code quality issues with filtering options.
Parameters:
projectKey (required): The SonarQube project key
branch (optional): Branch name
types (optional): Issue types (BUG, VULNERABILITY, CODE_SMELL)
severities (optional): Severities (BLOCKER, CRITICAL, MAJOR, MINOR, INFO)
statuses (optional): Statuses (OPEN, CONFIRMED, REOPENED, RESOLVED, CLOSED)
assignees (optional): Assignee usernames
tags (optional): Issue tags
limit (optional): Maximum number of issues (default: 50)
get_security_vulnerabilitiesGet detailed security vulnerability analysis.
Parameters:
projectKey (required): The SonarQube project key
branch (optional): Branch name
severities (optional): Filter by severities
statuses (optional): Filter by statuses
assigned (optional): Filter by assigned/unassigned
limit (optional): Maximum number of vulnerabilities (default: 50)
get_quality_gateCheck quality gate status and conditions.
Parameters:
projectKey (required): The SonarQube project key
branch (optional): Branch name
get_analysis_historyView historical analysis data and trends.
Parameters:
projectKey (required): The SonarQube project key
branch (optional): Branch name
from (optional): Start date (YYYY-MM-DD)
to (optional): End date (YYYY-MM-DD)
limit (optional): Maximum number of analyses (default: 10)
src/
├── index.ts # MCP server entry point
├── services/
│ └── sonarqube-client.ts # SonarQube API client
├── tools/ # MCP tool implementations
│ ├── list-projects.ts
│ ├── get-project-metrics.ts
│ ├── list-issues.ts
│ ├── get-security-vulnerabilities.ts
│ ├── get-quality-gate.ts
│ └── get-analysis-history.ts
├── types/
│ └── sonarqube.ts # TypeScript type definitions
└── utils/
└── formatting.ts # Utility functionsnpm run build - Build the TypeScript project
npm run dev - Run in development mode with ts-node
npm start - Start the MCP server
npm test - Run tests
Create a new tool file in src/tools/
Implement the tool schema and handler function
Add the tool to the imports and tools array in src/index.ts
Add a case for the tool in the CallTool handler
To use this MCP server with VS Code and Copilot:
Create .vscode/mcp.json in your workspace:
{
"servers": {
"sonarqube": {
"command": "npx",
"args": ["mcp-sonarqube"],
"env": {
"SONARQUBE_URL": "http://localhost:9000",
"SONARQUBE_TOKEN": "your-token-here"
}
}
}
}If you have the package installed locally:
{
"servers": {
"sonarqube": {
"command": "node",
"args": ["./node_modules/mcp-sonarqube/dist/index.js"],
"env": {
"SONARQUBE_URL": "http://localhost:9000",
"SONARQUBE_TOKEN": "your-token-here"
}
}
}
}If you have the package installed globally:
{
"servers": {
"sonarqube": {
"command": "mcp-sonarqube",
"env": {
"SONARQUBE_URL": "http://localhost:9000",
"SONARQUBE_TOKEN": "your-token-here"
}
}
}
}Install the MCP extension for VS Code
The SonarQube tools will be available in Copilot Chat
@copilot Use the SonarQube tools to give me a quality overview of project "my-app"@copilot Show me all security vulnerabilities in project "my-app" that are CRITICAL or BLOCKER@copilot Check if project "my-app" passes its quality gate@copilot Show me the quality trends for project "my-app" over the last monthThe server provides detailed error messages for common issues:
Missing environment variables
Invalid project keys
SonarQube connection issues
Authentication failures
Invalid parameters
If you encounter this error in VS Code or when using the MCP server, try these solutions:
Test the server directly first:
# Test if the server starts correctly
node dist/index.js
# Should output: "SonarQube MCP Server started successfully"
# Test with an MCP initialize request
echo '{"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": {"name": "test", "version": "1.0.0"}}}' | node dist/index.jsFor VS Code integration issues:
Make sure the package is installed globally: npm install -g mcp-sonarqube
Try using the full path instead of npx:
{
"servers": {
"sonarqube": {
"command": "node",
"args": ["/path/to/global/node_modules/mcp-sonarqube/dist/index.js"],
"env": {
"SONARQUBE_URL": "http://localhost:9000",
"SONARQUBE_TOKEN": "your-token"
}
}
}
}Restart VS Code after changing the MCP configuration
For npx issues:
Clear npm cache: npm cache clean --force
Reinstall the package: npm uninstall -g mcp-sonarqube && npm install -g mcp-sonarqube
Check Node.js version (requires Node.js 18+)
Environment variable issues:
Ensure SONARQUBE_URL and SONARQUBE_TOKEN are properly set
Test connection: curl -u your-token: $SONARQUBE_URL/api/projects/search
If you encounter API errors related to invalid parameters:
"additionalFields components must be one of..."
This error has been fixed in version 1.0.2+
Update to the latest version: npm update -g mcp-sonarqube
The server now uses valid additionalFields values: rules,users,comments
Invalid parameter values:
Check that your SonarQube version supports the API endpoints being used
Some parameters may have different valid values in different SonarQube versions
Refer to your SonarQube instance's API documentation at: {SONARQUBE_URL}/web_api
Connection errors:
Verify SonarQube URL is accessible
Check firewall settings
Ensure SonarQube server is running
Authentication errors:
Verify token is valid and has appropriate permissions
Check token expiration
Ensure token has at least "Browse" permission on projects
SSL/TLS issues:
For self-signed certificates, you may need to set NODE_TLS_REJECT_UNAUTHORIZED=0 (not recommended for production)
Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file for details
npm Package: https://www.npmjs.com/package/mcp-sonarqube
GitHub Repository: https://github.com/akhilthomas236/sonarqube-mcp-npm
SonarQube Documentation: https://docs.sonarqube.org/
Model Context Protocol: https://modelcontextprotocol.io/
For issues and questions:
Check the SonarQube API documentation
Verify your token permissions
Ensure network connectivity to SonarQube
Check the server logs for detailed error messages
Create an issue on GitHub
Get historical analysis data and trends for a SonarQube project
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The SonarQube project key | |
| branch | No | Branch name (optional, defaults to main branch) | |
| from | No | Start date for analysis history (YYYY-MM-DD format) | |
| to | No | End date for analysis history (YYYY-MM-DD format) | |
| limit | No | Maximum number of analyses to return (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, placing full burden on the description. It only states the purpose without disclosing behavioral traits such as read-only nature, pagination, or any side effects. Minimal transparency.
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 concise with a single sentence, no unnecessary words. However, it lacks structure like separate sections or usage notes, but still efficient.
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?
With 5 parameters and no output schema, the description does not explain return values, how trends are represented, or how to interpret the data. The agent would lack context to use the output effectively.
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 description coverage is 100% with detailed parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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' and the resource 'historical analysis data and trends for a SonarQube project', which is distinct from sibling tools like get_project_repository or list_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?
The description implies usage for retrieving historical analysis and trends, but lacks explicit guidance on when to use versus alternatives or conditions like requiring a projectKey. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get git repository information and source code management details for a SonarQube project
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The SonarQube project key (required) | |
| includeBranches | No | Include branch information in the response (optional, default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Only states retrieval but no details on side effects, permissions, or read-only nature. Minimal behavioral disclosure.
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, 15 words, no redundancy. Efficiently communicates purpose.
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?
Simple tool with two parameters and no output schema. Description is adequate but could mention return format or typical usage. No major gaps but not fully complete.
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 covers both parameters fully, so baseline is 3. Description provides context but adds no extra semantic information beyond the schema.
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?
Clear verb 'Get' and specific resource 'git repository information and source code management details' for a SonarQube project. Distinguishes from siblings like get_analysis_history or list_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 tool vs alternatives. Lacks context or exclusions that help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get quality gate status and conditions for a SonarQube project
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The SonarQube project key | |
| branch | No | Branch name (optional, defaults to main branch) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as read-only nature, required authentication, error handling, or any side effects. The minimal description leaves an AI agent to infer 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 concise sentence that directly states the purpose. It is front-loaded with the key action and resource.
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?
Given the simple tool with 2 parameters (both well-described in schema) and no output schema, the description is reasonably complete. It could mention the type of conditions returned, but it suffices for a straightforward getter.
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 coverage is 100%, so the description does not need to add much. It adds no extra meaning beyond the schema. Baseline 3 is appropriate.
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 'Get quality gate status and conditions for a SonarQube project' clearly states the verb (Get) and resource (quality gate status and conditions). It differentiates from sibling tools like get_analysis_history and get_security_vulnerabilities by focusing on quality gates.
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 alternatives, no prerequisites, and no conditions under which it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed security vulnerability analysis from a SonarQube project
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The SonarQube project key | |
| branch | No | Branch name (optional, defaults to main branch) | |
| severities | No | Comma-separated severities (BLOCKER, CRITICAL, MAJOR, MINOR, INFO) | |
| statuses | No | Comma-separated statuses (OPEN, CONFIRMED, REOPENED, RESOLVED, CLOSED) | |
| assigned | No | Filter by assigned/unassigned vulnerabilities | |
| limit | No | Maximum number of vulnerabilities to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no insight into behavior beyond the name. No mention of read-only nature, response details, or any side effects. Without annotations, this is insufficient.
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, no wasted words, but could benefit from a brief example or usage hint without being verbose.
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?
No output schema, no annotations, and a terse description. The tool has 6 parameters and multiple filter options, yet the description does not explain what the analysis includes or how results are structured.
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 coverage is 100%, so the description adds no additional meaning beyond parameter names and schema descriptions. Baseline score of 3 is appropriate.
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 it retrieves security vulnerability analysis from SonarQube, but does not explicitly distinguish it from sibling tools like 'list_issues' or 'sonarqube_get_project_metrics'.
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 tool versus alternatives (e.g., for general issues vs. security-specific). No information on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List code quality issues from a SonarQube project with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | The SonarQube project key | |
| branch | No | Branch name (optional, defaults to main branch) | |
| types | No | Comma-separated issue types (BUG, VULNERABILITY, CODE_SMELL) | |
| severities | No | Comma-separated severities (BLOCKER, CRITICAL, MAJOR, MINOR, INFO) | |
| statuses | No | Comma-separated statuses (OPEN, CONFIRMED, REOPENED, RESOLVED, CLOSED) | |
| assignees | No | Comma-separated assignee usernames | |
| tags | No | Comma-separated tags | |
| limit | No | Maximum number of issues to return (default: 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'list', implying read-only, but does not explicitly state that no data is modified, nor does it mention authentication, rate limits, or pagination 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 of 10 words, concise and front-loaded with the core purpose. Every word contributes.
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?
With 8 parameters, no output schema, and no annotations, the description is too minimal. It lacks information on output format, pagination, defaults (e.g., limit default 50), or any behavioral context beyond listing.
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?
The input schema has 100% description coverage (all 8 parameters have descriptions). The tool description adds no additional meaning beyond 'with filtering options', which is already implied by the parameter descriptions. Baseline 3 is appropriate.
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 'List code quality issues from a SonarQube project with filtering options', providing a specific verb ('list') and resource ('code quality issues from a SonarQube project'). It distinguishes itself from sibling tools like get_security_vulnerabilities or get_analysis_history by focusing on general 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 explicit guidance is provided on when to use this tool versus alternatives. Sibling tools are listed but no comparisons or contexts are given, leaving the agent to infer usage without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive project quality metrics including coverage, technical debt, complexity, and issue counts
| Name | Required | Description | Default |
|---|---|---|---|
| projectKey | Yes | SonarQube project key (required) | |
| branch | No | Specific branch to analyze (optional, defaults to main branch) | |
| metrics | No | Comma-separated list of specific metrics to retrieve (optional, defaults to standard quality metrics) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects (assuming read-only), authentication needs, rate limits, or any behavioral traits beyond retrieving data. Minimal disclosure.
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 that is front-loaded with purpose and examples; no unnecessary words. Efficient and to the point.
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?
No output schema, so description should explain return values better. It lists example metrics but does not specify output format, error cases, or how to interpret results. Adequate but not thorough for a metrics retrieval 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?
Schema description coverage is 100%, so baseline is 3. The tool description adds value by listing example metrics, but does not explain the format or constraints of the optional metrics parameter beyond what is in the schema.
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 it retrieves comprehensive quality metrics and lists specific examples (coverage, technical debt, complexity, issue counts), which distinguishes it from sibling tools that focus on specific areas like security vulnerabilities or analysis history.
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 explicit guidance on when to use this tool versus alternatives, but the focus on general metrics is implied by the description and sibling tool names. Lacks explicit when-not-to-use or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all accessible SonarQube projects with their basic information and quality status
| Name | Required | Description | Default |
|---|---|---|---|
| organization | No | Filter projects by organization (optional) | |
| search | No | Search term to filter project names (optional) | |
| qualityGate | No | Filter by quality gate status: OK, WARN, ERROR (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states the basic function without mentioning read-only nature, permission requirements, or any side effects. This is insufficient for an agent to assess safety.
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, efficient sentence of 12 words. It is front-loaded with the key action and resource, achieving conciseness without losing clarity.
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?
For a simple listing tool with no output schema, the description covers the essential purpose and available filters. It lacks pagination info but remains adequate for basic use.
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 description coverage is 100%, so baseline is 3. The description does not add any meaning beyond the schema's parameter descriptions, which are already clear.
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 'list', resource 'SonarQube projects', and output 'basic information and quality status'. It effectively distinguishes this tool from siblings like 'list_issues' and 'get_quality_gate' by focusing on project listing.
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 or when not to use this tool, nor does it mention alternatives among siblings. Users are left to infer from context.
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.1.1get_analysis_historyget_project_repositoryget_quality_gateget_security_vulnerabilitieslist_issuessonarqube_get_project_metricssonarqube_list_projectsEach tool targets a distinct SonarQube resource: project listing, metrics, quality gate, issues, security vulnerabilities, analysis history, and repository info. No overlap in purpose.
Most tools use verb_noun snake_case (e.g., get_analysis_history), but two tools include a 'sonarqube_' prefix (sonarqube_get_project_metrics, sonarqube_list_projects), breaking the pattern. The convention is mixed but still readable.
7 tools is well-scoped for a SonarQube analysis server, covering the primary read operations without redundancy.
Covers major reading operations (metrics, issues, security, quality gate), but misses some likely endpoints like 'get_project' for a single project or 'get_issue' for a specific issue. Minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
MCP server for AI access to Swagger by SmartBear.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/akhilthomas236/sonarqube-mcp-npm'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
