Self-hosted
This page provides information on self-hosted SonarQube MCP Server setups and the associated transport modes Stdio, HTTPS, and HTTP including examples for each deployment.
Transport modes define how the MCP server communicates with your client. Options include Stdio, HTTPS, and HTTP. Each mode includes a deployment example for configuring your client. See Environment variables for details about required configuration values.
Warning: User tokens are required when setting up connected mode or an MCP server between SonarQube Server and SonarQube for IDE. Your binding won't function properly if you use project tokens, global tokens, or scoped organization tokens during setup.
Local server (Stdio)
For independent users who need a quick setup for their specific IDE or CLI. Run the official mcp/sonarqube container image using stdio transport for local development. This gives access to the full tool set.
The stdio transport mode is the recommended and default mode for local development and single-user setups used by all MCP clients. It's also the mode used in your Agentic Analysis and Context Augmentation workflow. The common variables are required to initialize any transport mode you choose.
Docker example
Note: Although the examples below use
docker, any OCI-compatible container runtime works (for example, Podman, nerdctl, etc). Simply replacedockerwith commands specific to your preferred tool.
SonarQube Cloud
Use this code sample when using the container image to configure your MCP HTTP server for integrating with SonarQube Cloud.
{
"mcpServers": {
"sonarqube": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "-e", "SONARQUBE_TOKEN", "-e", "SONARQUBE_ORG", "mcp/sonarqube"],
"env": {
"SONARQUBE_TOKEN": "<YourSonarQubeUserToken>",
"SONARQUBE_ORG": "<YourSonarQubeOrganization>"
}
}
}
}Note: SONARQUBE_URL should be defined as
https://sonarqube.useach time you use a SonarQube Cloud configuration (SONARQUBE_TOKEN+SONARQUBE_ORG) and want to connect to a US-region instance. See the Connecting to SonarQube Cloud in the US region section for details.
SonarQube Server
Use this code sample when using Docker to configure your MCP server for integrating with SonarQube Server or SonarQube Community Build.
Remote server (HTTPS and HTTP)
This setup is suited for a central server that multiple users will access, using their own clients. This setup uses the HTTPS transport mode for a shared team server.
HTTPS
HTTPS configurations are very similar to HTTP but require SSL certificates.
For local development, use HTTP instead of HTTPS to avoid SSL certificate issues.
For production deployments with proper SSL certificates from a trusted CA, use HTTPS.
Docker example
Note: Although the examples below use
docker, any OCI-compatible container runtime works (for example, Podman, nerdctl, etc). Simply replacedockerwith commands specific to your preferred tool.
SonarQube Cloud
Use this code sample when using the container image to configure your MCP HTTPS server for integrating with SonarQube Cloud. The server uses the SONARQUBE_TOKEN environment variable for initialization. Clients connect to the server using the Authorization: Bearer header.
Note: SONARQUBE_URL should be defined as
https://sonarqube.useach time you use a SonarQube Cloud configuration (SONARQUBE_TOKEN+SONARQUBE_ORG) and want to connect to a US-region instance. See the Connecting to SonarQube Cloud in the US region section for details.
SonarQube Server
Use this code sample when using the container image to configure your MCP HTTPS server for integrating with SonarQube Server or SonarQube Community Build. The server uses the SONARQUBE_TOKEN environment variable for initialization. Clients connect to the server using the Authorization: Bearer header.
Client configuration
Warning: Deprecation notice: Passing the token via the
SONARQUBE_TOKENheader is deprecated for HTTP(S) transport.
For HTTP(S) transport: use the
Authorization: Bearer <YourSonarQubeUserToken>header. This is mandatory for SonarQube Cloud embedded MCP, and recommended for all other HTTP(S) configurations.For stdio transport: no change:
SONARQUBE_TOKENas an environment variable is unchanged.See common variables for details.
When connecting to an HTTPS transport server, clients must include the Authorization header with a Bearer token in all requests.
HTTP
Important: The HTTP transport mode is not recommended. Use Stdio for local development or HTTPS for multi-user production deployments.
Enable HTTP transport for unencrypted multi-user scenarios where more than one client will connect to a shared server. The common variables are required for initialization, in addition to the listed HTTP variables that clients will need to access the server.
After setup, each client must provide its own user token for access.
Client configuration
When connecting to an HTTP transport server, clients must include the Authorization header with a Bearer token in all requests.
Service endpoints
When running in HTTPS or HTTP transport mode, the server exposes a few unauthenticated service endpoints in addition to the MCP endpoint at /mcp. These endpoints are for service-to-service use (monitoring, orchestration, client compatibility checks) and don't require an Authorization header.
/health
GET
Liveness probe. Returns 200 OK with an empty body once the server is accepting requests.
(empty body)
/info
GET
Returns the MCP server version as JSON. Useful for verifying the deployed server version.
{"version":"1.16.0"}
These endpoints are not available when running with the Stdio transport.
Using the configuration generator
Use the official SonarQube MCP Server configuration generator to get a configuration snippet for your setup.
To do this:
Identify your agent.
Find your common variables.
Enter the information into the SonarQube Server configuration generator and select the local (stdio) or remote server option.
Paste the generated configuration into your configuration file.
Last updated
Was this helpful?

