Agent Centric Development Cycle AC/DC

Tool names are written bare. Some agents namespace MCP tools as mcp__<server-name>__<tool> — if yours does, prefix accordingly using your own server name from your MCP config.

Always, before writing anything:

• get_guidelines — coding standards drawn from this project's own SonarQube issue history, filtered to the task at hand. Requires mode: project_based (default), category_based, or combined. Narrow with categories, languages, file_paths.

To find and read existing code, use these instead of grep and find. They resolve symbols through abstract syntax trees and control flow rather than text matching:

• search_by_signature_patterns — find declarations by regex on signatures
• search_by_body_patterns — find usages by regex inside method bodies
• get_source_code — read a symbol's source by fully qualified name

When changing architecture or touching shared code:

• get_current_architecture — the actual module dependency graph. depth is required; start at 0 for a top-level view, then drill in with path_prefix.
• get_intended_architecture — the constraints you've defined, so the agent stays inside them
• get_upstream_call_flow / get_downstream_call_flow — trace callers and callees by fqn
• get_references — every file referencing a type
• get_type_hierarchy — implementors and subtypes

Before adding or updating any dependency:

• check_dependency — pass purl (e.g. pkg:npm/lodash@4.17.21). Refuse the dependency outright if it comes back malicious. Block on BLOCKER or HIGH riskSeverity, and propose a version from fixedVersions. Requires SonarQube Advanced Security.

Semantic navigation covers Java, C#, JavaScript, TypeScript, Python, and Rust. Guidelines cover every SonarQube Cloud language.

Call run_advanced_code_analysis on each new or modified file:

• projectKey — falls back to SONARQUBE_PROJECT_KEY if configured
• branch — required. The branch used to retrieve the latest stored analysis context.
• filePath — required. Project-relative, e.g. src/main/java/MyClass.java
• fileScope — "MAIN" or "TEST". A plain string, not an array. Defaults to "MAIN".

This uses the latest stored analysis context for the branch rather than recomputing it, which is why it returns CI-depth results in seconds.

Do not report a file as done until its analysis comes back clean.

1. show_rule with the rule key (e.g. python:S7608) to get the rationale, the noncompliant example, and the recommended fix. Fix from the rule's guidance, not from a guess about what it wants.
2. Fix every finding on lines you touched this turn. Leave pre-existing findings on untouched lines alone unless you were asked to address them.
3. Re-run run_advanced_code_analysis on the same files to confirm the fix landed and introduced nothing new. Repeat until clean.
4. Surface findings to the user verbatim. Do not summarize them away or silently drop them.

Optional, for wider context:

• search_sonar_issues_in_projects — the existing issue backlog, to see whether a finding is yours or was already there
• search_dependency_risks — the dependency risks already recorded against the project, as opposed to check_dependency, which vets a package before you add it
• get_project_quality_gate_status — the project's gate state

There is no MCP tool that invokes the SonarQube Remediation Agent. That agent works the main-branch backlog and open pull requests from SonarQube Cloud and opens its own PRs. It is the Solve stage outside the coding loop; the loop above is the Solve stage inside it.