Add context to generate better code

How to provide context to your agents to ensure the resulting code meets your software architecture and code quality standards.

Note: This feature is in Beta stage and is only available with SonarQube Cloud projects for organizations in the Team and Enterprise plans. See the Product release lifecycle page for more information on release stages.

This guide walks you through the setup of Context Augmentation for your AI agent. The recommended setup path for supported agents is the SonarQube CLI. It installs an agent skill that can access Context Augmentation without exposing the tools through MCP. If you need direct MCP configuration or use a workflow not covered by sonar integrate, you can manually configure a locally running SonarQube MCP Server that connects to SonarQube Cloud.

Two setup paths are available: use the recommended SonarQube CLI setup for supported agents, or manually configure the SonarQube MCP Server for direct MCP access.

General prerequisites

Before you start, make sure you meet the following prerequisites.

Environment

• Docker is installed and configured so your agent can run docker commands.

• The integration also works with any other OCI-compatible container runtime, such as Podman or nerdctl.

SonarQube Cloud admin settings

Context Augmentation is enabled in your SonarQube Cloud organization's admin settings.

Project settings

Make sure your project is:

• Connected to SonarQube Cloud.

• Analyzed in your CI pipeline on a long-lived branch.

• Using SonarQube Cloud Architecture.

Setup

Choose the setup path that matches your agent.

Supported agents with SonarQube CLI

Use this recommended option to configure an agent supported by sonar integrate, such as Claude Code, GitHub Copilot, or Codex. For Context Augmentation, the CLI installs the local Context Augmentation tool and an agent skill that can use it directly. The same command can also configure a locally running SonarQube MCP Server for SonarQube MCP tools other than the Context Augmentation tools.

Prerequisites specific to this setup

Make sure you have:

• A supported agent installed on your machine.

• SonarQube CLI installed and authenticated.

Step 1: Run the integration command

From your project folder, run:

sonar integrate <agent> --project <YourProjectKey>

Replace <agent> with the supported integration you want to configure, for example claude, copilot, or codex.

This command configures the selected agent for the current project. It installs a project-specific Context Augmentation skill, binds it to the project key you provide, and configures the skill to access the Context Augmentation capabilities through the CLI.

Context Augmentation is project-specific rather than global. If you run sonar integrate <agent> --global, Context Augmentation is skipped; rerun the command without --global from a project directory to install it there.

Step 2: Restart your agent

Restart your agent so the generated skill and configuration are loaded for the current project.

Step 3: Verify your setup

Ask your agent "What is the current architecture of the projects? Limit the answer to the top-level blocks.". The agent uses Context Augmentation to retrieve the current architecture (it might ask for your confirmation), then presents a high-level overview of the current project.

Example response

The architecture has 19 top-level modules with 35 dependencies between them:

  ---
  Foundation (no dependencies)

  ┌──────────────────┬──────────────────────┐
  │      Module      │      Depended on by    │
  ├──────────────────┼──────────────────────┤
  │ proj-api-base    │ All 18 other modules │
  └──────────────────┴──────────────────────┘

  ---
  Core layer (depend only on api-base)

  ┌────────────────────────────────────────────────┬────────────────────────────────────────┐
  │                     Module                     │                Purpose                 │
  ├────────────────────────────────────────────────┼────────────────────────────────────────┤
  │ proj-api-injection                             │ DI configuration interfaces            │
  │ proj-common                                    │ Shared utilities                       │
  │ proj-documentation                             │ Documentation                          │
  │ proj-impl-configuration-gestalt                │ Gestalt config implementation          │
  │ proj-peripheralcommadapter-loopback            │ Peripheral loopback driver             │
  │ proj-plantoverview-base                        │ Base UI components                     │
  │ proj-plantoverview-panel-loadgenerator         │ Load generator panel                   │
  │ proj-plantoverview-panel-resourceallocation    │ Resource allocation panel              │
  │ proj-plantoverview-themes-default              │ Default UI themes                      │
  │ proj-strategies-default                        │ Default routing/dispatching strategies │
  └────────────────────────────────────────────────┴────────────────────────────────────────┘

  ---
  Mid layer (depend on api-base + common)

  ┌────────────────────────────────────────┬────────────────────────────┐
  │                 Module                 │      Also depends on       │
  ├────────────────────────────────────────┼────────────────────────────┤
  │ proj-commadapter-loopback              │ common                     │
  │ proj-kernel-extension-http-services    │ common                     │
  │ proj-kernel-extension-rmi-services     │ common                     │
  │ proj-plantoverview-common              │ common, plantoverview-base │
  └────────────────────────────────────────┴────────────────────────────┘

  ---
  Application layer (leaf modules, nothing depends on them)

  ┌─────────────────────────────┬────────────────────────────────────────────────────────────┐
  │           Module            │                         Depends on                         │
  ├─────────────────────────────┼────────────────────────────────────────────────────────────┤
  │ proj-kernel                 │ api-base, common, commadapter-loopback                     │
  │ proj-kernelcontrolcenter    │ api-base, common, commadapter-loopback                     │
  │ proj-modeleditor            │ api-base, common, plantoverview-base, plantoverview-common │
  │ proj-operationsdesk         │ api-base, common, plantoverview-base, plantoverview-common │
  └─────────────────────────────┴────────────────────────────────────────────────────────────┘

  ---
  Dependency flow (simplified)

  proj-api-base
    └── proj-common
          └── proj-commadapter-loopback
          │     ├── proj-kernel
          │     └── proj-kernelcontrolcenter
          └── proj-plantoverview-base
                └── proj-plantoverview-common
                      ├── proj-modeleditor
                      └── proj-operationsdesk

  proj-api-base is the clear foundation — every module depends on it and nothing depends on the four application-layer modules (kernel, kernelcontrolcenter, modeleditor, operationsdesk).

SonarQube MCP Server integration

Use this option when you want to expose Context Augmentation through a manually configured SonarQube MCP Server. This remains useful for agents and workflows where you want direct control over MCP configuration, such as Cursor, Codex, Gemini CLI, Copilot, and custom setups.

Warning: Context Augmentation requires a locally running SonarQube MCP Server with a local filesystem mount. You can't use a SonarQube-hosted MCP server, whether SonarQube Cloud-hosted or SonarQube Server-hosted, for CAG tools.

Step 1: Export the SonarQube token environment variable

Export the SONARQUBE_TOKEN environment variable with a valid Personal Access Token (PAT) for your project.

# macOS/Linux (Bash/Zsh)
export SONARQUBE_TOKEN="{<YourUserToken>}"

Step 2: Add or edit your project-specific MCP configuration file

Important: Context Augmentation requires a project-specific configuration. Don't use your global MCP configuration.

The SONARQUBE_TOOLSETS value determines which MCP toolsets are enabled. The following configuration enables the cag toolset required for Context Augmentation.

{
  "mcpServers": {
    "sonarqube-mcp-server": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm", "--pull=always",
        "-e", "SONARQUBE_URL",
        "-e", "SONARQUBE_TOKEN",
        "-e", "SONARQUBE_ORG",
        "-e", "SONARQUBE_PROJECT_KEY",
        "-e", "SONARQUBE_TOOLSETS",
        "-v", "/ABSOLUTE/PATH/TO/YOUR/PROJECT:/app/mcp-workspace:rw",
        "mcp/sonarqube"
      ],
      "env": {
        "SONARQUBE_URL": "https://sonarcloud.io",
        "SONARQUBE_ORG": "<YourOrganizationKey>",
        "SONARQUBE_PROJECT_KEY": "<YourProjectKey>",
        "SONARQUBE_TOOLSETS": "cag"
      }
    }
  }
}

Note: Optional configurations:

• SONAR_SQ_BRANCH: Provide it when not using git, or when your git branch name doesn't match the branch name in SonarQube. Add "-e", "SONAR_SQ_BRANCH" to the args array and "SONAR_SQ_BRANCH": "<YourBranchName>" to the env object.

• Enable Agentic Analysis: To also enable Agentic Analysis, change SONARQUBE_TOOLSETS to "cag,projects,analysis".

• Include default SonarQube MCP tools: To include the default SonarQube MCP tools in addition to the Agentic Workflow tools, change the SONARQUBE_TOOLSETS value to: "analysis,issues,projects,quality-gates,rules,duplications,measures,security-hotspots,dependency-risks,coverage,cag".

• Read-only volume mounting of the project workspace: To mount the project workspace in read-only mode, specify ro instead of rw. Some tools might work in degraded mode.

Step 3: Optimize tool invocation (recommended)

Tool usage can be inconsistent depending on available tools, context, and agent behavior. To increase the chance of Context Augmentation tools being called at the right time, we recommend two additional configurations:

1. Ensure tools are loaded on startup:

Context Augmentation tools are designed to be called automatically based on their descriptions, so they must be available to the model from the start. Some agents lazy-load MCP tool descriptions, meaning they are only made available when explicitly requested—reducing the chance tools are invoked at the right time. Other agents load them eagerly by default, such as Codex, where defer_loading defaults to false. If your agent lazy-loads tools, configure it to load them eagerly on startup. For example, with Claude Code, set ENABLE_TOOL_SEARCH to false.

2. Add an operational directive:

Adding a directive is optional. It is only needed if you want to enforce a specific Guide-phase workflow—without one, Context Augmentation still works, and the agent decides the right workflow and when to call the tools on its own, based on the tool descriptions.

To enforce a workflow, instruct your agent by adding a directive to its configuration file. Where to add it depends on your agent:

• Cursor: Create a .cursor/rules/sonar-context-augmentation.md Cursor rule file

• Claude Code: Add the directive to your CLAUDE.md in the project root, or use Claude Skills

• Codex: Add the directive to your AGENTS.md file in the project root

• Gemini CLI: Add the directive to your GEMINI.md file in the project root

• Copilot: Add the directive to your .github/copilot-instructions.md file in the project root

Example directive:

Note: The following directive is one example of a Guide-and-Verify flow. You can customize your guidance by picking from the available Context Augmentation tools to match your team's workflow. If you're only using Context Augmentation without Agentic Analysis, you can remove the VERIFY Phase section.

# SonarQube Agentic Workflow - Usage Directive (MUST FOLLOW)

**Always use the Guide-and-Verify workflow** for writing and modifying code.

## GUIDE Phase - Before Writing or Editing Code

**Before writing or editing code** you MUST:
1. Call `get_guidelines` for project context and coding standards
2. Locate existing code with `search_by_signature_patterns` or `search_by_body_patterns`
3. Read implementation with `get_source_code`

**When changing architecture or dependencies** you MUST:
- Check `get_current_architecture` and `get_intended_architecture`
- Analyze impact using:
  - `get_upstream_call_flow` / `get_downstream_call_flow` - trace method calls
  - `get_references` - find all usages
  - `get_type_hierarchy` - check inheritance

**Before adding or updating a third-party dependency** you MUST:
- Call `check_dependency` with the package URL (purl) to check for vulnerabilities, malware, and license compliance

## VERIFY Phase - After Writing or Editing Code

You must strictly follow this Analyze-Then-Commit workflow for every code modification. No code is considered complete until it has passed the following SonarQube validation loop:

1. **Read Phase:** After any modification or before commit, use the `Read` tool to load the current state of all relevant source files.
2. **Analysis Phase:** For every new or modified file, you must call `run_advanced_code_analysis` using:
   - `filePath`: The project-relative path to the file (e.g., `src/main/java/MyClass.java`)
   - `branchName`: The active development branch
   - `fileScope`: `["MAIN"]` or `["TEST"]` depending on the code type
3. **Evaluation & Remediation:**
   - **Rule Lookup:** For every issue flagged, call `show_rule` with the specific rule key (e.g., `java:S1874`)
   - **Mandatory Fixes:** You are prohibited from committing code with **CRITICAL** or **HIGH** issues. Implement fixes based on the rule's rationale and recommended guidance immediately.
4. **Verification:** After applying fixes, re-run the analysis to ensure issues are resolved and no regressions were introduced.

Step 4: Restart your agent

Restart your AI agent to apply the new MCP configuration.

Step 5: Verify your setup

1. Ask your agent "What is Guide and Verify?". Your agent describes the SonarQube Agentic workflow as configured in step 3.

Example response

 "Guide & Verify" is a workflow defined in your project's CLAUDE.md file for writing and modifying code. It has two phases:

  GUIDE Phase (before writing code):
  - Fetch project guidelines and coding standards via get_guidelines
  - Locate existing code using search tools
  - Read the relevant implementation via get_source_code
  - For architectural changes: check current/intended architecture, trace call flows, find usages, inspect type hierarchies

  VERIFY Phase (after writing code):
  1. Read — reload all modified source files
  2. Analyze — run run_advanced_code_analysis on each changed file against the active branch
  3. Evaluate & Fix — look up flagged rules with show_rule, and mandatory fix any CRITICAL or HIGH severity issues before committing
  4. Re-verify — re-run analysis to confirm fixes and check for regressions

  In short, it's a SonarQube-backed quality gate that requires you to understand existing code before touching it and validate every change with static analysis before considering it done.

1. Ask your agent "What is the current architecture of the projects? Limit the answer to the top-level blocks.". The agent calls the get_current_architecture tool (it might ask for your confirmation). The agent then presents a high-level overview of the current project.

Example response

The architecture has 19 top-level modules with 35 dependencies between them:

  ---
  Foundation (no dependencies)

  ┌──────────────────┬──────────────────────┐
  │      Module      │      Depended on by    │
  ├──────────────────┼──────────────────────┤
  │ proj-api-base    │ All 18 other modules │
  └──────────────────┴──────────────────────┘

  ---
  Core layer (depend only on api-base)

  ┌────────────────────────────────────────────────┬────────────────────────────────────────┐
  │                     Module                     │                Purpose                 │
  ├────────────────────────────────────────────────┼────────────────────────────────────────┤
  │ proj-api-injection                             │ DI configuration interfaces            │
  │ proj-common                                    │ Shared utilities                       │
  │ proj-documentation                             │ Documentation                          │
  │ proj-impl-configuration-gestalt                │ Gestalt config implementation          │
  │ proj-peripheralcommadapter-loopback            │ Peripheral loopback driver             │
  │ proj-plantoverview-base                        │ Base UI components                     │
  │ proj-plantoverview-panel-loadgenerator         │ Load generator panel                   │
  │ proj-plantoverview-panel-resourceallocation    │ Resource allocation panel              │
  │ proj-plantoverview-themes-default              │ Default UI themes                      │
  │ proj-strategies-default                        │ Default routing/dispatching strategies │
  └────────────────────────────────────────────────┴────────────────────────────────────────┘

  ---
  Mid layer (depend on api-base + common)

  ┌────────────────────────────────────────┬────────────────────────────┐
  │                 Module                 │      Also depends on       │
  ├────────────────────────────────────────┼────────────────────────────┤
  │ proj-commadapter-loopback              │ common                     │
  │ proj-kernel-extension-http-services    │ common                     │
  │ proj-kernel-extension-rmi-services     │ common                     │
  │ proj-plantoverview-common              │ common, plantoverview-base │
  └────────────────────────────────────────┴────────────────────────────┘

  ---
  Application layer (leaf modules, nothing depends on them)

  ┌─────────────────────────────┬────────────────────────────────────────────────────────────┐
  │           Module            │                         Depends on                         │
  ├─────────────────────────────┼────────────────────────────────────────────────────────────┤
  │ proj-kernel                 │ api-base, common, commadapter-loopback                     │
  │ proj-kernelcontrolcenter    │ api-base, common, commadapter-loopback                     │
  │ proj-modeleditor            │ api-base, common, plantoverview-base, plantoverview-common │
  │ proj-operationsdesk         │ api-base, common, plantoverview-base, plantoverview-common │
  └─────────────────────────────┴────────────────────────────────────────────────────────────┘

  ---
  Dependency flow (simplified)

  proj-api-base
    └── proj-common
          └── proj-commadapter-loopback
          │     ├── proj-kernel
          │     └── proj-kernelcontrolcenter
          └── proj-plantoverview-base
                └── proj-plantoverview-common
                      ├── proj-modeleditor
                      └── proj-operationsdesk

  proj-api-base is the clear foundation — every module depends on it and nothing depends on the four application-layer modules (kernel, kernelcontrolcenter, modeleditor, operationsdesk).

Troubleshooting

Enabling detailed logs

If you encounter issues with the Context Augmentation MCP tools, first enable detailed logging to identify the root cause.

Add the following environment variables to the env object in your MCP configuration:

"SONARQUBE_DEBUG_ENABLED": "true",
"SONAR_LOG_LEVEL": "TRACE"

Then expose them to the Docker container by adding these entries to the args array:

"-e", "SONARQUBE_DEBUG_ENABLED",
"-e", "SONAR_LOG_LEVEL"

Exporting logs

After you enable detailed logging, use one of the following methods to retrieve the logs.

Option 1: Export logs from the running Docker container

1. Identify the container ID used by the MCP server:

   docker ps

   If multiple containers are running the same image, filter by your project key:

   docker ps -q | xargs docker inspect --format '{{.Id}} {{.Config.Env}}' | grep "SONARQUBE_PROJECT_KEY=<YourProjectKey>" | awk '{print $1}'

   Replace <YourProjectKey> with the project key configured in your MCP server.

2. Extract the logs as an archive file:

   docker exec <container_id> sh -c "cd /app/storage && tar czf - logs/" > logs.tar.gz

Option 2: Mount logs to a local directory

Add the following volume mount to the args array in your MCP configuration, replacing <LOCAL_LOG_DIRECTORY> with an absolute path to an existing local directory:

"-v", "<LOCAL_LOG_DIRECTORY>:/app/storage/logs:rw"

After you restart the MCP server, logs are written directly to that local directory.

Context Augmentation tools not loading

Symptom: After setting up the MCP server, only two tools appear: search_my_sonarqube_projects and run_advanced_code_analysis and none of the Context Augmentation tools are available.

Fix: Pull the latest version of the Docker image, then restart your AI agent:

docker pull mcp/sonarqube

---

SonarQube connection failed

Symptom: After you complete the setup, architecture tools don't appear. Only get_guidelines and two general SonarQube MCP tools (search_my_sonarqube_projects and run_advanced_code_analysis) are available. The following error messages appear in the logs:

SonarQube connection failed: [Errno -2] Name does not resolve
Architecture: SonarQube not available. Architecture loading skipped. Architecture tools will be unavailable.

Fix: Verify the value of SONARQUBE_URL in your MCP configuration. It must point to the SonarQube Cloud instance hosting your project's analysis. For example, https://sonarcloud.io.

Additional fix for Linux systems on corporate or restricted networks:

The default Docker DNS pass-through might be blocked, preventing the container from resolving hostnames. This issue can also appear intermittently.

Pass an explicit DNS server address to Docker by adding the following entry to the args array:

"--dns=8.8.8.8"

Replace 8.8.8.8 with your organization's DNS server address if needed.

As a last resort, configure the container to share the host network:

"--network=host"

Or instruct the container to use your host's DNS resolver directly:

"--dns=127.0.0.53"

Warning: Using --network=host removes Docker's network isolation for this container, which might reduce security. Use this option only if other approaches haven't resolved the issue.

Architecture tools fail with "Universal Dependency Graph (UDG) not loaded"

Symptom: Architecture tools such as get_type_hierarchy and search_by_signature_patterns return an error message: "Universal Dependency Graph (UDG) not loaded".

Cause: The MCP server is configured to use a branch that has not been analyzed or does not exist in SonarQube Cloud.

Fix: Verify that the SONAR_SQ_BRANCH environment variable in your MCP configuration points to a valid branch that SonarQube Cloud has analyzed. If you recently created the branch or changed its name, make sure a fresh analysis has completed successfully.

Need help?

Post a question on the community forum or contact support if your license includes access to commercial support.

Related pages

• Agentic Analysis

• MCP Server

• Tools

• Architecture