# Add context to generate better code

> **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](/sonarqube-cloud/appendices/product-release-lifecycle.md) page for more information on release stages.

This guide walks you through the setup of [Context Augmentation](/agent-centric-development-cycle/features/context-augmentation.md) to expose the [Context Augmentation MCP tools](/agent-centric-development-cycle/developer-tools/mcp-server/reference/tools.md#context-augmentation) to your AI agent.

Two setup paths are available: configure Claude Code with the SonarQube CLI, or configure the SonarQube MCP Server manually for any supported agent (Cursor, Codex, Gemini CLI, Copilot, and others).

## 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](https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/branch-analysis/main-vs-long-lived-branches).
* Using SonarQube Cloud [Architecture](/sonarqube-cloud/architecture.md).

## Setup

Choose the setup path that matches your agent.

### Claude Code with SonarQube CLI

Use this option to configure Claude Code directly from your terminal. The CLI sets up a [self-hosted SonarQube MCP Server](/agent-centric-development-cycle/developer-tools/mcp-server/setup/self-hosted.md#local-server-stdio) with the project-scoped configuration that Context Augmentation requires.

#### Prerequisites specific to this setup

Make sure you have:

* Claude Code installed on your machine.
* [SonarQube CLI](https://docs.sonarsource.com/sonarqube-cli/) installed and authenticated.

#### Step 1: Run the integration command

From your project folder, run:

```bash
sonar integrate claude --project <YourProjectKey>
```

This command configures Claude Code for the current project. It registers the SonarQube MCP server for Claude Code, binds the integration to the project key you provide, and writes a project-specific Claude MCP configuration in `.mcp.json` for Claude Code.

The generated configuration is project-specific rather than global, which is required for Context Augmentation.

#### Step 2: Restart Claude Code

Restart Claude Code so the MCP configuration is loaded for the current project.

#### Step 3: Optimize tool invocation

Tool usage can be inconsistent depending on available tools, context, and agent behavior.

To increase the chance that Context Augmentation tools are called at the right time, Sonar recommends 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`](https://developers.openai.com/api/docs/guides/tools-connectors-mcp#defer-loading-tools-in-an-mcp-server) defaults to `false`. If your agent lazy-loads tools, configure it to load them eagerly on startup. For Claude Code, set [`ENABLE_TOOL_SEARCH`](https://code.claude.com/docs/en/mcp#configure-tool-search) to `false`.

**2. Add an operational directive**

Adding a directive is optional but recommended if you want Claude Code to follow a consistent Guide phase workflow. In Claude Code, add the directive to your [CLAUDE.md](https://code.claude.com/docs/en/best-practices#write-an-effective-claude-md) file in the project root, or use [Claude Skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview).

**Example directive:**

```
# SonarQube Agentic Workflow - Usage Directive (MUST FOLLOW)

Always use the Guide-and-Verify workflow for code generation and modification.

## GUIDE Phase - Before Generating Code

Before generating 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`
  - `get_references`
  - `get_type_hierarchy`
```

> **Note:** This example covers the GUIDE phase only, which is the scope of Context Augmentation. To extend the directive with a VERIFY phase that runs Agentic Analysis after each change, see the [Agentic Analysis guide](/agent-centric-development-cycle/how-to-guides/verify-your-code/make-your-agent-verify-its-code.md).

#### Step 4: 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 code generation and modification. 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.
```

2. 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).
```

### SonarQube MCP Server integration

Use this option to configure the SonarQube MCP Server manually. This is the setup path for agents other than Claude Code (Cursor, Codex, Gemini CLI, Copilot, and so on).

> **Warning:** Context Augmentation requires a [self-hosted SonarQube MCP Server](/agent-centric-development-cycle/developer-tools/mcp-server/setup/self-hosted.md#local-server-stdio) with a local filesystem mount. You can't use the [SonarQube Cloud-hosted MCP server](/agent-centric-development-cycle/developer-tools/mcp-server/setup/sonarqube-cloud-hosted.md#tool-availability-with-sonarqube-cloud) for CAG tools.

#### Step 1: Export the SonarQube token environment variable

Export the `SONARQUBE_TOKEN` [environment variable](/agent-centric-development-cycle/developer-tools/mcp-server/reference/environment-variables.md#common-variables) with a valid [Personal Access Token (PAT)](/sonarqube-cloud/managing-your-account/managing-tokens.md) for your project.

```bash
# 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](/agent-centric-development-cycle/developer-tools/mcp-server/reference/tools.md) are enabled. The following configuration enables the `cag` toolset required for Context Augmentation.

```json
{
  "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`](https://developers.openai.com/api/docs/guides/tools-connectors-mcp#defer-loading-tools-in-an-mcp-server) 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`](https://code.claude.com/docs/en/mcp#configure-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](https://cursor.com/docs/context/rules) file
* Claude Code: Add the directive to your [CLAUDE.md](https://code.claude.com/docs/en/best-practices#write-an-effective-claude-md) in the project root, or use [Claude Skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)
* Codex: Add the directive to your [AGENTS.md](https://developers.openai.com/codex/guides/agents-md/) file in the project root
* Gemini CLI: Add the directive to your [GEMINI.md](https://geminicli.com/docs/cli/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](/agent-centric-development-cycle/features/context-augmentation.md#guide-and-verify-loop) 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](/agent-centric-development-cycle/features/agentic-analysis.md), you can remove the **VERIFY Phase** section.

```
# SonarQube Agentic Workflow - Usage Directive (MUST FOLLOW)

**Always use the Guide-and-Verify workflow** for code generation and modification.

## GUIDE Phase - Before Generating Code

**Before generating 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 Generating 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 code generation and modification. 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.
```

2. 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:

```json
"SONARQUBE_DEBUG_ENABLED": "true",
"SONAR_LOG_LEVEL": "TRACE"
```

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

```json
"-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:

   ```bash
   docker ps
   ```

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

   ```bash
   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:

   ```bash
   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:

```json
"-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:

```bash
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:

```log
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:

```json
"--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:

```json
"--network=host"
```

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

```json
"--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](https://community.sonarsource.com/) or contact support if your license includes access to [commercial support](https://www.sonarsource.com/support/).

## Related pages

* [Agentic Analysis](/agent-centric-development-cycle/features/agentic-analysis.md)
* [MCP Server](/agent-centric-development-cycle/developer-tools/mcp-server.md)
* [Tools](/agent-centric-development-cycle/developer-tools/mcp-server/reference/tools.md)
* [Architecture](/sonarqube-cloud/architecture.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sonarsource.com/agent-centric-development-cycle/how-to-guides/add-context-to-generate-better-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
