SonarQube

​

Who is this for?

​

Prerequisites

• A SonarQube Server (self-hosted) or a SonarQube Cloud account.
• A User Token (type User token, not an analysis token) generated in My Account > Security > Generate Tokens: one shared token for the workspace, or one per user in per-user mode (see Authentication modes in the Workspace builder tab).
• The API base URL of your instance:
  • SonarQube Cloud: https://sonarcloud.io/api
  • Self-hosted: https://<your-sonarqube-host>/api
• For SonarQube Cloud only: the organization key that owns your projects (most search and create operations require it; use searchOrganizations to discover the keys visible to your token).
• Prisme.ai platform 27.5.7 or later. The SonarQube API must be reachable from the platform’s runtime.

context_id,agent_id,user_id

{
  "type": "oauth2",
  "status_url": "https://<api-host>/v2/workspaces/slug:<workspace>/webhooks/<instance>.oauthStatus",
  "connect_url": "https://<api-host>/v2/workspaces/slug:<workspace>/webhooks/<instance>.oauthConnect",
  "disconnect_url": "https://<api-host>/v2/workspaces/slug:<workspace>/webhooks/<instance>.oauthDisconnect",
  "scopes": []
}

You have access to the SonarQube MCP server. Use it whenever the user asks about code-quality data: projects, issues, security hotspots, measures, quality gates, rules or badges. Examples: "List the blocker issues in project X", "What's the coverage of auth-service?", "Show the security hotspots opened this week", "Why is the quality gate failing on main?". On SonarCloud, most search and create operations need an organization key; call searchOrganizations first if you don't know it. Prefer calling MCP tools directly over guessing, and confirm with the user before any destructive action (mark issues as false positive, change severity, delete a project or branch). If a tool answers that SonarQube is not connected for this user, ask the user to click Connect on the SonarQube capability.

{
  "name": "searchIssues",
  "arguments": {
    "componentKeys": "my_org_my-project",
    "types": "BUG,VULNERABILITY",
    "severities": "CRITICAL,BLOCKER",
    "statuses": "OPEN,CONFIRMED,REOPENED",
    "branch": "main",
    "ps": 100
  }
}

{
  "name": "searchOrganizations",
  "arguments": {
    "member": true
  }
}

{
  "name": "transitionIssue",
  "arguments": {
    "issue": "AY9z...",
    "transition": "falsepositive"
  }
}

{
  "name": "getComponentMeasures",
  "arguments": {
    "component": "my_org_my-project",
    "metricKeys": "ncloc,bugs,vulnerabilities,coverage,duplicated_lines_density",
    "branch": "main"
  }
}

{
  "name": "getProjectQualityGateStatus",
  "arguments": {
    "projectKey": "my_org_my-project",
    "branch": "main"
  }
}

{
  "name": "createProject",
  "arguments": {
    "name": "Website Revamp",
    "project": "my_org_website-revamp",
    "organization": "my_org",
    "visibility": "private"
  }
}

- SonarQube.searchIssues:
    componentKeys: '{{projectKey}}'
    types: BUG
    statuses: OPEN,CONFIRMED,REOPENED
    ps: 100
    output: issues

- SonarQube.getProjectQualityGateStatus:
    projectKey: '{{projectKey}}'
    branch: main
    output: gateStatus
- conditions:
    '{{gateStatus.projectStatus.status}} == "ERROR"':
      - emit:
          event: qualityGateFailed
          payload:
            project: '{{projectKey}}'
            conditions: '{{gateStatus.projectStatus.conditions}}'

- SonarQube.transitionIssue:
    issue: '{{issueKey}}'
    transition: falsepositive
- SonarQube.addIssueComment:
    issue: '{{issueKey}}'
    text: 'False positive; already addressed in {{commitSha}}'

- SonarQube.getMeasuresHistory:
    component: '{{projectKey}}'
    metrics: coverage,bugs,vulnerabilities,code_smells
    from: '{{lastWeekIso}}'
    ps: 1000
    output: history

- SonarQube.createProject:
    name: '{{repoName}}'
    project: '{{org}}_{{repoName}}'
    organization: '{{org}}'
    visibility: private
    output: project
- SonarQube.selectQualityGate:
    projectKey: '{{project.project.key}}'
    gateName: 'Sonar way'
    organization: '{{org}}'

​

Migrating from the previous version

​

What changes, and when

​

Before you start

• Platform: 27.5.7 or later.
• Inventory, per workspace where SonarQube is installed: the instance name (slug), the agents that use the SonarQube capability, and who can generate a new SonarQube token if needed.
• Access: a workspace editor account on each of these workspaces, and an API access token for that account (step 3 is an API call).
• Decide the mode for each workspace: keep one shared token, or switch to personal tokens (see Authentication modes in the Workspace builder tab).

​

Step 1 — Deploy the new version

• Check that the platform’s startup import includes the extended group (STARTUP_IMPORT_GROUPS). Otherwise, import the sonarqube workspace from the release repository manually.
• To confirm the new version is live: in any workspace, open the SonarQube instance configuration. The new version shows a single read-only Configuration app field; the old one showed SonarQube API Base URL, API Token, MCP Endpoint and MCP API Key.

​

Step 2 — Check that DSUL instructions still work (optional)

​

Step 3 — Reconfigure each instance

• creates the secret sonarqubeAuth, pre-filled with the old token and API base URL;
• creates the secret sonarqubeAuthorizedAgents, empty;
• links both to the instance;
• fills in the Configuration app link.

API_URL="https://<your-api-host>/v2"      # the platform API, including /v2
WORKSPACE_ID="<workspace id>"
INSTANCE="<instance slug, URL-encoded: spaces as %20>"
TOKEN="<API access token of a workspace editor>"

curl -X PATCH "$API_URL/workspaces/$WORKSPACE_ID/apps/$INSTANCE/config" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"configAppUrl": ""}'

curl "$API_URL/workspaces/$WORKSPACE_ID/apps/$INSTANCE/config" -H "Authorization: Bearer $TOKEN"

​

Step 4 — Check authentication in the configuration app

• Keeping a shared token: the token and API base URL are pre-filled. Click Test connection; it must report success.
• Switching to personal tokens: select Personal token per user, keep the API base URL, Save authentication. The shared token is removed from sonarqubeAuth. Users connect on their first use (see the Agent builder tab).

​

Step 5 — Re-authorize agents

1. Tick each agent from your inventory (or Allow all agents). The list is empty after migration, so every agent is refused until allowed.
2. Click Install capability on each agent. It adds the new SonarQube MCP tool.
3. Remove the old SonarQube capability from each agent: the MCP tool whose server URL ends with /workspaces/slug:sonarqube/webhooks/mcp. Install capability only replaces a tool named sonarqube or pointing at the new endpoint, so an old capability under another name stays and keeps failing.
4. If an administrator had published SonarQube in the Capabilities catalog, publish it again with Add to catalog / Update catalog entry (or update the entry by hand, see Platform admin setup) so that it points at the new endpoint.

​

Step 6 — Rotate the shared SonarQube token

• After migration, generate a new SonarQube token for every workspace that kept a shared token, paste it in the configuration app, then revoke the old one in SonarQube.
• If you switched to personal tokens, revoke the old shared token in SonarQube.
• Treat the stored events of the sonarqube workspace as containing credentials (retention, access rights, purge).

​

Step 7 — Clean up (optional)

​

Verification checklist

• Each instance configuration has a non-empty configAppUrl.
• Test connection succeeds (shared mode), or a user connects with Connect my token and Test connection succeeds (per-user mode).
• An allowed agent answers a SonarQube question; its tool call goes to /webhooks/<instance>.mcp.
• No agent still has the old capability (/workspaces/slug:sonarqube/webhooks/mcp).
• Old shared tokens are revoked in SonarQube.

​

Security

​

Error Handling

​

Common Issues

​

External Resources