SonarQube MCP HTTP mode: hotspot, duplication, and coverage-detail tools fail, while direct SonarQub

[ach762]

Title

SonarQube MCP HTTP mode: hotspot, duplication, and coverage-detail tools fail, while direct SonarQube API calls with the same USER token succeed

Body

We’re seeing what looks like an MCP-side issue in HTTP transport mode where several read-only tools fail even though the same SonarQube USER token succeeds directly against SonarQube Server Web API endpoints in the same API families.

Environment

• SonarQube Server: 26.3.0.120487
• SonarQube MCP Server image: mcp/sonarqube:latest as at 23/03/26
• Resolved image digest: sha256:83994943cbb9e145a58f30e98293559b22f665f802037db1b965d57dc11fc068
• Image created: 2026-03-23T06:26:23.411056613Z
• Transport: HTTP
• SonarQube URL: http://192.168.0.32:9000
• MCP URL: http://192.168.0.32:3000/mcp
• Auth: SonarQube USER token
• Client auth header: Authorization: Bearer <token>

We verified the Docker host is actually on the current latest for that machine:

• docker pull mcp/sonarqube:latest returned Image is up to date
• running container image id matches the same digest

docker-compose

services:
  sonarqube-mcp:
    image: mcp/sonarqube:latest
    container_name: sonarqube-mcp
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      SONARQUBE_TOKEN: "<same user token as client>"
      SONARQUBE_URL: "http://192.168.0.32:9000"
      SONARQUBE_TRANSPORT: "http"
      SONARQUBE_HTTP_HOST: "0.0.0.0"
      SONARQUBE_HTTP_PORT: "3000"
      TELEMETRY_DISABLED: "true"

Client (VSCode) MCP config

{
  "servers": {
    "sonarqube": {
      "type": "http",
      "url": "http://192.168.0.32:3000/mcp",
      "headers": {
        "Authorization": "Bearer <same user token>"
      }
    }
  }
}

MCP tools that work

• search_my_sonarqube_projects
• get_project_quality_gate_status
• list_quality_gates
• search_metrics
• search_sonar_issues_in_projects
• get_component_measures
• show_rule
• analyze_code_snippet

MCP tools that fail

• search_security_hotspots → Insufficient privileges
• show_security_hotspot → Insufficient privileges
• search_files_by_coverage → Insufficient privileges
• search_duplicated_files → Insufficient privileges
• get_duplications → Insufficient privileges
• get_file_coverage_details → Insufficient privileges

Important detail
The exact same token succeeds directly against SonarQube Server for the corresponding API families:

GET /api/hotspots/search?projectKey=MyProject&p=1&ps=1 -> 200
GET /api/duplications/show?key=MyProject:apps/plotsheets/src/components/generator/TeamPanel.tsx -> 200
GET /api/measures/component_tree?component=MyProject&metricKeys=coverage&qualifiers=FIL&p=1&ps=3 -> 200
GET /api/measures/component_tree?component=MyProject&metricKeys=duplicated_lines_density&qualifiers=FIL&metricSort=duplicated_lines_density&s=metric&p=1&ps=3 -> 200
GET /api/sources/lines?key=MyProject:apps/plotsheets/src/components/generator/TeamPanel.tsx -> 200

So this does not appear to be:

• an invalid token
• a missing general permission on the SonarQube user
• Security Hotspots being unavailable over the SonarQube API
• duplication / coverage listing APIs being unavailable over the SonarQube API
• an outdated cached MCP image on the Docker host

Instead, it looks like one or both of:

• MCP is not forwarding the same effective auth context for some tool families
• MCP is calling different upstream endpoints/parameters than expected for hotspots, coverage, and duplications

Relevant MCP logs

INFO SonarQube MCP Server - Tool called: search_security_hotspots
ERROR SonarQube MCP Server - Tool failed: search_security_hotspots
org.sonarsource.sonarqube.mcp.serverapi.exception.ForbiddenException: SonarQube answered with Insufficient privileges
    at org.sonarsource.sonarqube.mcp.serverapi.ServerApiHelper.handleError(ServerApiHelper.java:186)
    at org.sonarsource.sonarqube.mcp.serverapi.ServerApiHelper.get(ServerApiHelper.java:61)
    at org.sonarsource.sonarqube.mcp.serverapi.hotspots.HotspotsApi.search(HotspotsApi.java:57)
    at org.sonarsource.sonarqube.mcp.tools.hotspots.SearchSecurityHotspotsTool.execute(SearchSecurityHotspotsTool.java:76)

INFO SonarQube MCP Server - Tool called: show_security_hotspot
ERROR SonarQube MCP Server - Tool failed: show_security_hotspot
org.sonarsource.sonarqube.mcp.serverapi.exception.ForbiddenException: SonarQube answered with Insufficient privileges
    at org.sonarsource.sonarqube.mcp.serverapi.ServerApiHelper.handleError(ServerApiHelper.java:186)
    at org.sonarsource.sonarqube.mcp.serverapi.ServerApiHelper.get(ServerApiHelper.java:61)
    at org.sonarsource.sonarqube.mcp.serverapi.hotspots.HotspotsApi.show(HotspotsApi.java:67)
    at org.sonarsource.sonarqube.mcp.tools.hotspots.ShowSecurityHotspotTool.execute(ShowSecurityHotspotTool.java:49)

Question
Should these MCP read-only tools be working in this setup, given that the same USER token succeeds directly against the corresponding SonarQube Server API families?

[ach762]

Typically, moments after posting this issue, we found the problem. Documenting here for any future readers.

What we had done was configured codex to use a bearer_token_env_var and incorrectly picked the bash environment variable for the project token instead of the user token. Codex was not using the mcp.json file in the vscode directory, and was doing its own thing.

After correcting the config.toml to use the correct environment variable, it now works.