SonarQube MCP Server (Centralized for multiple Users)

SonarQube MCP Server
1

Environment

  • SonarQube Server or Cloud? both
  • Deployment type (STDIO/HTTP, Docker/JAR): Docker
  • Client / AI tool using MCP (if applicable): Cursor

Description

We’re deploying the official SonarQube MCP Server as a centralized service in Google Cloud Run. The container listens on HTTP inside (bound to $PORT). Clients (Cursor/Kiro/etc.) connect to the public HTTPS endpoint.

Question 1: Token Ownership and Scope for Container Initialization

"I am setting up the SonarQube MCP Server in a containerized environment to integrate with SonarCloud. The documentation mentions that a SONARQUBE_TOKEN is required for container initialization.

My question is regarding the identity and permissions of this token:

  • Ownership: Since this token is used by the container service and not a specific end-user, should it be created under a dedicated ‘Service Account’ user, or does it need to be a Personal Access Token (PAT) from an Organization Admin?

  • Permissions: What are the minimum required permissions for this initialization token? Does it require ‘Administer’ rights at the organization level, or is ‘Execute Analysis’ / ‘Browse’ sufficient just to wake up the service?

  • Type: Can I use a ‘Scoped Organization Token’ for this, or must it specifically be a ‘User Token’ as seen in some local setup guides?"

Question 2: Handling Multiple Organizations in a Multi-Tenant Setup

"I have a set of users split across two different SonarCloud organizations (Org A and Org B). When initializing the MCP server container, I am required to provide the SONARQUBE_ORG variable.

  • Initialization: If the container is initialized with the name of ‘Org A’, will users from ‘Org B’ still be able to use the MCP tools to query their projects, provided they pass their own user tokens in the headers?

  • Multi-Org Support: Does a single MCP Server container support multiple organizations simultaneously, or do I need to deploy a separate container instance for every organization I want to support?"

Question 3: Client-Side vs. Server-Side Organization Logic

"When an AI assistant (like Claude or Cursor) makes a request through the MCP server, it often provides an organization key.

If I have already provided an organization name at the container level during startup, does the container enforce that specific organization for all requests? Or is the container-level organization only used for a ‘system check’ during startup, allowing the client-side organization name to override it for specific tool calls?"

3

SonarQube Team, do you have any thought on these MCP server configuration questions?

5

Hello @sanjesh,

Thanks for reaching out!

Regarding the questions around the token. SONARQUBE_TOKEN is indeed mandatory even in HTTP mode. This is because the MCP server does a few things at startup:

  • download plugins for the analysis tools
  • check the minimal supported version (for SonarQube Server, not for Cloud)
  • check if SonarQube Advanced Security is enabled

To allow for such requests, a scoped organization token should be sufficient, if you use a Team or Enterprise plan on SQC. Otherwise you will need to use a user token. In this case, I would recommend to define a new service user with limited permissions. ‘Execute analysis’ should be sufficient.

Generally, no, because most HTTP requests made by the MCP server target a specific SQC organization. Some tools that are not organization-specific might work, but I would not recommend this approach as it might bring confusion to your users.

Each instance can point only to a single organization. You would need to deploy two different instances, one per organization.

Yes. The organization needs to be provided at startup of the MCP server and cannot be overridden from tools. As per my previous answer, you would have to use 2 different instances in your case to support 2 different organizations.

Hope this helps, let me know if you have more questions!

1 Like
8

Hello @sanjesh,

Thanks for the detailed questions. Damien’s original reply was accurate at the time, but the server has since gained meaningful new capabilities, particularly around HTTP(S) transport. Here is an updated answer to all three questions.

Question 1: Token ownership and permissions for container initialization

In HTTP(S) mode (which is what you’re deploying on Cloud Run), SONARQUBE_TOKEN at startup is now optional.

If you do provide one, it is used exclusively for:

  • Downloading analyzer plugins at startup

  • Checking the minimum supported version (SonarQube Server only)

  • Checking whether SonarQube Advanced Security is enabled

If you do not provide a startup token, those steps are simply skipped with a log message (analysis tools won’t be available), and the server starts fine. Every actual tool call is then authenticated with the individual user token passed per-request via the Authorization: Bearer <token> HTTP header.

So if you want a startup token for the plugin download and capability checks, a scoped organization token with Execute Analysis permission is sufficient (Team/Enterprise plan on SonarQube Cloud). Otherwise you can omit it entirely and skip those startup checks.

Question 2: Multi-org support - this is now fully supported

This is the biggest change since Damien’s reply. A single MCP server instance can now serve users across multiple organizations simultaneously.

The server now supports two deployment models:

Model A - Single-org gateway (one org baked in at startup):

SONARQUBE_ORG=my-org-a ← set at container startup

All requests are routed to my-org-a. Each client uses their own token via Authorization: Bearer <token>. Clients must not send a SONARQUBE_ORG header, the server will reject it with HTTP 400.

Model B — Multi-org gateway (no org set at startup):

SONARQUBE_ORG is NOT set at container startup

Each client must send their own SONARQUBE_ORG header with every request. This means a single container can serve users from Org A and Org B simultaneously, no need for separate deployments per org.

Client configuration for Model B looks like this:

{
  "mcpServers": {
    "sonarqube": {
      "url": "https://your-cloud-run-service/mcp",
      "headers": {
        "Authorization": "Bearer <user-personal-token>",
        "SONARQUBE_ORG": "<their-org-key>"
      }
    }
  }
}

The server is fully stateless: no session state, no sticky sessions. So horizontal scaling is also supported out of the box.

Question 3: Client-side vs. server-side organization logic

The behavior is strictly mutually exclusive:

  • If SONARQUBE_ORG is set at server startup → it is enforced for all requests. Clients sending a SONARQUBE_ORG header will receive HTTP 400.

  • If SONARQUBE_ORG is not set at server startup → every client connecting to SonarQube Cloud must supply a SONARQUBE_ORG header. Requests without it will receive HTTP 400.

So for your multi-org Cloud Run deployment, the recommended approach is Model B above: don’t set SONARQUBE_ORG at startup, and let each client pass their own org key per-request.

One additional note on the recommended transport

Plain HTTP transport is marked not recommended in production. For a Cloud Run deployment exposed over HTTPS, we recommend using HTTPS transport (SONARQUBE_TRANSPORT=https) with a proper TLS certificate, or placing the container behind a TLS-terminating reverse proxy (Cloud Run’s built-in HTTPS endpoint should work well for this). The Authorization: Bearer model described above applies to both HTTP and HTTPS modes.

Hope this clears things up! Let me know if you have further questions.

1 Like