This server exposes SonarRemedy's CLI as MCP tools, letting an AI agent drive the SonarQube technical-debt recovery workflow (fetch issues, build queues, process proposals, integrate fixes, and configure projects) without manual CLI use.
Fetch Sonar issues into an export (sonar_remedy_fetch), optionally scoped by repo/project and output path.
Slice exports into durable queues (sonar_remedy_slice), with optional execute and repo/project binding.
Run/lease proposal batches (sonar_remedy_run) from a queue, with limit, resume, and execute controls.
Inspect queue state via sonar_remedy_status, sonar_remedy_progress, and sonar_remedy_schedule.
Fetch and slice every chunk into its own queue (sonar_remedy_run_all).
Run the local analysis pipeline and publish/regenerate Sonar results (sonar_remedy_analyze), with repo/branch/script/project options.
Integrate a recorded proposal serially (sonar_remedy_integrate), applying it and running bound checks.
Bind reviewed check commands and approve a checks sha256 (sonar_remedy_configure).
List saved project configs (sonar_remedy_projects).
Save a project's Sonar/repo config non-interactively (sonar_remedy_configure_project), storing token references rather than secrets.
Allows an AI agent to fetch SonarQube issues, measures, and quality gate status, queue and propose fixes, then apply and verify them while tracking progress.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SonarRemedy Fetch Sonar issues for project 'checkout' and show progress."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Recover SonarQube technical debt automatically — a proposal-only worker swarm with a serial integrator, driven by any AI (VS Code Copilot, OpenCode, Claude Code) over MCP.
Python 3.11+ (stdlib only — no pip dependencies). Windows is the primary target.
A. Install as a CLI (recommended):
git clone https://github.com/YeisonManco/SonarRemedy
cd SonarRemedy
python -m pip install -e .Use the editable install (
-e).sonarremedy updateauto-detects the clone via the editable install; a non-editable install moves the code tosite-packagesandupdatecannot find the clone anymore.
This installs three commands:
Command | What it runs |
| the facade CLI ( |
| the interactive config wizard |
| the MCP server for the editor |
B. Run without installing (skip pip install, call the module directly):
python -B SonarRemedy/sonar_remedy.py --helpImportant: this installs the CLI for the terminal only. Copilot Chat in VS Code does not know about SonarRemedy until you run
sonarremedy initin your project — see Set up an editor. Install and editor setup are two separate steps.
Related MCP server: SonarQube MCP Server
Update the pack with one command — it works from anywhere (the clone is auto-detected):
sonarremedy updateIt runs git pull + pip install for you. If you need to point at a specific clone, use sonarremedy update --path C:\path\to\SonarRemedy. Check the version with sonarremedy --version.
Fetch — pulls open issues, measures, and the quality gate from Sonar (chunked when the project exceeds the issue budget).
Queue — a durable SQLite queue groups findings by file+kind and leases bounded proposal contexts.
Propose — a proposal-only worker (a sub-agent or headless model) reads one bounded job.json and returns a strict proposal.json. Workers never touch the repo.
Integrate — a single serial integrator applies proposals, runs configured checks (RED/GREEN), and verifies byte-for-byte.
Track — status/progress report the next action, remaining jobs, and an ETA.
flowchart TD
U["User: recover the debt of X"] --> O[Orchestrator<br/>AI drives the CLI]
O --> F[fetch<br/>Sonar issues to export.json]
F --> S[slice<br/>build durable queue]
S --> R[run --execute<br/>lease N jobs, one job.json each]
R --> W1[Worker 1<br/>proposal-only]
R --> W2[Worker 2<br/>proposal-only]
R --> WN[Worker N<br/>proposal-only]
W1 --> I[Serial integrator<br/>apply, RED, GREEN, verify]
W2 --> I
WN --> I
I --> ST[status<br/>next action + ETA]
ST -->|re-scan| FConcurrency model:
One worktree per branch — set up once by the orchestrator, never one per worker.
Workers propose in parallel — each is isolated (no tools, no repo access) and reads only its own job.json.
The integrator applies serially — one proposal at a time (RED → GREEN → byte-for-byte), even though proposals were prepared in parallel.
No commits/push in the pack — the integrator edits the files; committing and pushing are separate human operations.
Each branch gets its own queue + worktree + evidence; fixes never cross branches.
Python does all the mechanical analysis; the AI does exactly one thing — propose the fix.
Layer | Modules | Role |
Fetch |
| Pull Sonar issues (chunked if over budget) |
Queue |
| Durable SQLite queue — claims, leases, fail-closed binding |
Detect |
| Find suppressions; detect language + distilled hints |
Integrate |
| Apply proposals serially, run checks, verify byte-for-byte |
Report |
| Next action, ETA, parallel/serial plan |
AI (external) | proposal worker | Reads one |
Everything that does not need AI is mechanical (zero tokens). The AI only proposes what the mechanical tools cannot: understanding the code and writing an idiomatic fix.
sonarremedy <command> [flags]
Command | What it does |
| Pull Sonar issues into an export (chunked if over budget) |
| Build a durable queue from an export |
| Lease/process a bounded manual proposal batch |
| Serially apply a recorded proposal + run bound checks |
| Step one phase of fetch/slice/run/integrate automatically |
| Loop the full cycle (fetch→slice→run→integrate→status) to the end |
| Bind reviewed check commands + the target snapshot |
| Draft |
| Detect Sonar-evasion directives ( |
| Detect Sonar exclusions/suppressions by language + category (17 rules) |
| Manage the exclusion whitelist/blacklist ( |
| List applied fixes + the human follow-up each requires |
| Regenerate the deterministic audit-trail |
| Defer pending/proposed work without changing target files |
| Resolve an expired lease, never automatically retrying |
| Report the queue's next action + ETA |
| Write a human-readable progress file |
| Show the parallel/serial plan for pending jobs |
| Run the local pipeline to regenerate Sonar results |
| Fetch + slice every chunk into its own queue |
| List saved project configs |
| Save a project config non-interactively |
| Interactively register multiple projects |
| Wire up VS Code + Copilot, and create |
| Remove generated state + sibling worktrees (keep |
| Remove |
| Report whether the project's setup is up to date with the installed pack |
| Diagnose the setup + a queue's identity (root/branch/revision) with fixes |
|
|
doctor reports what is wrong and how to fix it — use it before guessing:
sonarremedy doctor # project version + setup
sonarremedy doctor --state <queue> --repo <path> # compare the queue's identity
sonarremedy doctor --fix # apply the safe repairs--state is the queue directory created by slice (it contains queue.sqlite3), not an export .json file.
Each identity mismatch reports the exact fix command: git -C <root> checkout <branch> (branch), run --repo <bound root> (root), or re-fetch + re-slice (revision).
--fix applies only the safe repairs — it re-runs init when the project's recorded version is behind the pack or init files are missing (and re-writes the pointer + version marker). It never touches a queue or the git state.
doctor also reports a project check: which saved project binds to the checkout you passed (ok / ambiguous / warning). This is your "am I about to touch the right repo?" guard. A warning means no saved project matches this checkout; ambiguous means two configs match — pass --project to disambiguate.
Project auto-detection: when you run a pipeline command (fetch/slice/run/recover/…) without --project/--config, the pack auto-selects the saved project that matches the actual target checkout — the explicit --repo <path> you passed (the documented way to run these commands: from the pack directory with --repo naming the real checkout), falling back to the current directory only when no --repo was given. No match falls back to the default config; an ambiguous match errors asking for --project.
doctor also reports three more safety checks: project_collisions (two saved projects share a local_path/URL — give them distinct values), remote_credentials (the checkout's origin remote embeds a token — re-set it without the token and use a credential manager), and queue_project (the project registered for a --state queue in the ~/.sonar-remedy/queues.json index). slice --execute and recover both record their queues automatically, whether the project is resolved from --project, from a matching --repo/checkout, or from a --config file whose own repository unambiguously matches a saved project.
One worktree per branch. Slicing binds the queue to the checkout you passed. On a multi-worktree repo, always use the SAME
--repopath acrossfetch→slice→run, or you will hittarget_identity_mismatch.Init per worktree. A new worktree comes from
HEAD, so it does NOT inherit the uncommitted.github/instructions,.vscode/mcp.json, or the gitignored.sonarremedy/setup — and you do NOT need to commit them. Aftergit worktree add, runsonarremedy init --dir <worktree>(idempotent, merges your instructions) and verify withsonarremedy doctor --dir <worktree>; if files are missing,doctor --fix --dir <worktree>recreates them.
# 1. Configure a project (Sonar URL, project key, token, repo, branch)
sonar-remedy-config --project <name> --persist
# 2. Fetch Sonar issues (chunked if over the budget)
sonarremedy --project <name> fetch --repo <path>
# 3. Slice the queue, run a batch, then resume
sonarremedy slice --export <export.json> --state <queue> --execute
sonarremedy run --state <queue> --execute --limit 8
# ... workers propose fixes ...
sonarremedy run --state <queue> --resume --execute
sonarremedy status --state <queue>If you skipped the install, replace sonarremedy with python -B SonarRemedy/sonar_remedy.py and sonar-remedy-config with python -B SonarRemedy/sonar_remedy_config.py.
Paste these in Copilot Chat, in order. Close Visual Studio before integrating (locked files fail the build gate).
Recuperá la deuda técnica del proyecto
<name>en la rama<branch>usando SOLO los tools MCP de SonarRemedy (sonar_remedy_*). No hagas trabajo manual, no leas el código fuente vos mismo, no improvises. Primero corrésonar_remedy_doctor --repo <checkout>y decime el estado. Después corrésonar_remedy_recovercon elchecks.jsony su sha aprobado,execute: true. Seguí el loop hasta el final: fetch → slice → run → configure → integrate → re-scan. No te detengas a preguntar salvo que sea un bloqueo real (mirá la FAQ de troubleshooting); si algo falla, reportá elreasonexacto y seguí.
recover reaches run and asks for proposalsEscribí una propuesta por cada job que te dé el tool, usando el contexto que te da (el método completo + la regla). Formato exacto del
proposal.json:{"version", "job_id", "attempt_id", "lease", "context_fingerprint", "status": "proposed", "edits": [{"path", "before_sha256", "replacements": [{"old", "new"}]}], "reason": "<token_sin_espacios>", "risks": [], "test_plan": "...", "follow_up": []}. Eloldtiene que matchear byte a byte el archivo. Preservá comportamiento, BOM y newlines; no debilites tests, no agregues supresiones/exclusiones, no inventes prueba. Si un job necesita un refactor que cruza archivos, diferilo conreason: "cross_file_refactor_required".
Seguí con el loop, no te frenes. Si
recoverpide más propuestas, escribilas. Si un ciclo terminó (re_scan_required), el propiorecoverre-publica el análisis local y arranca el siguiente ciclo —no preguntes, seguí. Pará solo cuando devuelvadone(0 issues) oimpossible(todo terminal), o un bloqueo humano real.
Cuando termine, mostrame el resumen (cuántos
applied/locally_verified, cuántosdeferred/failedy por qué) y el diff de los cambios. Avisame cuando esté listo para commitear; yo reviso y commiteo/pusheo (el hook pre-push corre la suite antes del push).
Standing rules (also wired into the Copilot instructions by init): never do the work manually, never commit/push with --no-verify, and on any blocked report the exact reason and stop — a failed baseline build keeps the job proposed for retry, it never applies anything red.
Copilot interprets instructions, so it can improvise. autopilot is the harness that owns the flow instead: every call advances as far as the rules allow — setup-gate, slice, run, configure-gate, integrate, status — and reports its phase with the exact next command. The model only fills bounded proposals; it never chooses a step.
sonarremedy autopilot --state <queue> --repo <path> # plan only (dry-run)
sonarremedy autopilot --state <queue> --repo <path> --export <export.json> --execute
# ... write one proposal per waiting proposal_path ...
sonarremedy autopilot --state <queue> --repo <path> --execute # resume
sonarremedy autopilot --state <queue> --repo <path> --execute --integrateDry-run is the default: it prints the ordered phases and writes nothing.
A repo without init stops at the setup gate with the exact init --dir fix (no commit/push of instructions required — see the worktree note above).
Proposals stop at awaiting_proposals with each proposal_path; integrating stops at the configure gate until checks are explicitly bound (configure --checks ... --approve-checks-sha256 ... --execute).
The same flow is available to Copilot as the sonar_remedy_autopilot MCP tool.
recover)sonarremedy recover --state <base> --checks <file> --approve-checks-sha256 <sha> --execute loops the cycle automatically: fetch → slice → run → configure → integrate → status, and on re_scan_required it re-analyzes (publishes to Sonar) and starts the next cycle. It stops only on 0 issues, no progress (everything terminal), or when the model must write proposals. The checks sha is approved once and reused.
fetch now pulls per-file coverage from Sonar's component tree and turns each file with uncovered lines into a coverage job (kind: "coverage", one per file, with uncovered_lines/lines_to_cover/coverage), so coverage is recoverable in measurable slices exactly like smells/security. Files at 100% are skipped; the lookup degrades gracefully (a token without coverage-tree access still fetches everything else, with a warning). The coverage hint (add a focused test for the uncovered lines) is already wired.
Duplication works the same way: fetch turns each duplicated file into a duplication job (duplicated_lines/duplicated_blocks/duplicated_lines_density). And fetch now reads the project's quality-gate conditions and reports them as gate_conditions, so the recovery TARGET is explicit (e.g. coverage ≥ 90, duplication < 5) instead of guessed.
sonar_remedy_fetch accepts kinds (and fetch a --kinds flag) to pull only the sources you want — smells, security, hotspots, coverage, duplication — instead of everything at once. Ask for just coverage, just duplication, or just hotspots.
Integration runs only the check commands you explicitly bind — nothing else executes on the target. Write them from examples/debt-checks.example.json (a template: the sha256 placeholder must be replaced, never invented) following docs/checks-reference.md:
Real absolute .exe paths, real cwd, real failing-test markers; compute each sha256 with python -B -c "import hashlib,sys; print(hashlib.sha256(open(sys.argv[1],'rb').read()).hexdigest())" <tool.exe> (recompute after every tool update).
Dry-run first: sonarremedy configure --state <queue> --repo <path> --checks <file> — validates the shape and prints checks_sha256 without writing.
Review it yourself, then approve: repeat with --approve-checks-sha256 <digest> --execute.
Don't hand-write it from scratch: sonarremedy detect-checks --repo <path> drafts it from the repo (solution, test projects, dotnet + real sha256) and tells you the 1–2 judgments to complete (same flow as sonar_remedy_detect_checks).
Set TYPESAFE_API_KEY and integrate() asks TypeSafe's System One a cheap yes/no question — does this proposal's diff plausibly address the Sonar rule it targets? — right before the expensive baseline build runs, and records the answer as evidence (typesafe-precheck.json in the job's integration folder). It is opt-in and purely advisory: with no key set (the default), nothing about integrate() changes at all, and even a network failure or a malformed response never blocks, gates, or alters integration — the worst case is an error status recorded instead of a score.
With the same env var set, sonar_remedy_scan_exclusions / sonar_remedy_scan_suppressions (sonar_exclusions_report.scan() / sonar_suppressions.scan()) also ask System One a cheap yes/no question per finding — does this NOSONAR/@ts-ignore/pragma-style directive look like a justified exception, or is it just silencing a real issue? — and attach the answer as an advisory typesafe_legitimacy field, so a human reviewing hundreds of findings can prioritize the least-justified-looking ones. It only scores each scan's most-severe still-open findings (pending exclusions, ambiguous suppressions), never an already-blocked/certain one, capped at 20 calls per scan regardless of findings count. Same contract as the pre-check: opt-in, purely advisory, never auto-blocks or auto-allows an exclusion — a human still decides, per host-agents/sonarremedy-instructions.md §9 — and with no key set nothing about either scan changes.
A hotspots-kind issue is always deferred for human review at intake (debt_queue.plan()) — it never reaches a worker, since hint_for("hotspots") is "do not auto-fix blindly." With TYPESAFE_API_KEY set, plan() also asks System One a cheap yes/no question per deferred hotspot job — does this pattern look like a genuine, exploitable risk, or a likely false positive / already-safe pattern? — and attaches the answer as an advisory typesafe_hotspot_risk field on the job record, visible to the human doing that review through document()'s report.json. Scoring is capped at 20 hotspot jobs per plan() call, and never touches security-kind jobs (even ones also deferred for human review) or any pending job. Same contract as the other two: opt-in, purely advisory, never gates, blocks, or un-defers a job — the existing defer-for-human-review decision stays exactly as it is — and with no key set nothing about plan() changes.
init installs a pre-push hook into the project's .git/hooks, so broken code cannot be pushed: the hook runs the project's gates and blocks the push on red. Never use --no-verify.
Pack repos: suite + ruff check + ruff format --check (mirrors CI).
Managed projects: commands declared in .sonarremedy-hooks.json ({"pre-push": [[...argv...]]}); without it, the hook blocks with the exact shape to declare.
doctor verifies the hook (git_hooks: ok/missing/foreign/outdated) and --fix reinstalls it. A foreign hook is never overwritten.
doctor --repo <path> also detects an orphaned integration barrier (a killed integrate) and --fix releases it only when the tree matches the recorded pre-integration snapshot; real quarantines and mismatches stay blocked.
Enforcement travels with the pack: hook + harness + instructions need no server settings. Optionally, on repos you own, add branch protection (GitHub → Settings → Branches → rule for main: require status checks) as a server-side backstop.
To save a project config non-interactively (for scripts), use:
sonarremedy configure-project --name <name> --sonar-url <url> --project-key <key> `
--repo-url <git-url> --local-path <path> --worktree-root <path>The config stores the name of the token env var, never the value. Each project can use its own var, so multiple Sonar servers/accounts coexist:
sonarremedy configure-project ... --token-env SONAR_TOKEN_PROJECT_B --pat-env GIT_PAT_PROJECT_BOne command wires up VS Code + Copilot Chat:
sonarremedy init --dir <your-project>It writes:
.vscode/mcp.json — the sonar-remedy MCP server (points at this pack).
.github/copilot-instructions.md — the Copilot instruction.
Reload VS Code, then in Copilot Chat: "recuperá la deuda de <proyecto>".
Verify it's wired up (optional): confirm the two files exist, then test the server in a terminal:
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' | sonar-remedy-mcpIt should reply with "serverInfo":{"name":"sonar-remedy"...}. In VS Code, the sonar_remedy_* tools then appear in Copilot Chat (you may need to reload the window: Ctrl+Shift+P → "Developer: Reload Window").
Manual (the same two files, by hand):
Copy host-agents/vscode-mcp.json to the project's .vscode/mcp.json (adjust the args path).
Copy host-agents/copilot-instructions.md to .github/copilot-instructions.md.
The MCP server exposes every command as a tool: sonar_remedy_fetch, sonar_remedy_slice, sonar_remedy_run, sonar_remedy_status, sonar_remedy_progress, sonar_remedy_schedule, sonar_remedy_analyze, sonar_remedy_run_all, sonar_remedy_configure_project, sonar_remedy_scan_suppressions, sonar_remedy_scan_exclusions, sonar_remedy_rules, sonar_remedy_report, …
Workers are proposal-only — no tools, no repo access. Only the serial integrator writes.
Binding fails closed: wrong target/branch/revision blocks, never silent.
Secrets (SONAR_TOKEN, GIT_PAT) live in the environment — never in files, args, or prompts.
Mutations require --execute; dry-run is the default.
locally_verified (tests passed) is not sonar_confirmed (Sonar no longer reports it); a fresh re-scan confirms.
A suppression scan (scan-suppressions) flags directives that may evade Sonar (NOSONAR, #pragma, # noqa, …) as certain or ambiguous — only the ambiguous ones need AI judgment, so no tokens are spent on clear cases.
An exclusions scan (scan-exclusions) reports Sonar exclusions/suppressions/coverage exclusions/technical exceptions by language + category, each with a severity (danger level). It is a separate, optional scan for "just the exclusions". Exclusions are never auto-fixed — a suppression may be legitimate, so a human reviews each one.
See CONTRIBUTING.md — TDD (RED/GREEN), Python stdlib only (no pip dependencies), and keep the MCP server in sync with the CLI. The full queue contract is in docs/work-queue.md.
Per-language fix skills live in skills/ — dotnet-index.md, python-index.md, angular-index.md, react-index.md, plus the Sonar workflow skills under skills/sonar/. A worker fixes using both the kind hint and the language hint.
python -B -m unittest discover -s tests -vMIT — see LICENSE.
Run the local pipeline to regenerate+publish Sonar results.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| branch | No | ||
| script | Yes | ||
| execute | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. Words like 'regenerate' and 'publish' hint at side effects, but it does not state whether existing results are overwritten, whether publishing is external and irreversible, whether permissions are required, or whether execution is long-running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, and the primary action is front-loaded. It earns its place and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no parameter documentation, no output schema, no annotations, and eleven siblings, this description is far too sparse. It cannot support safe, correct invocation because it omits parameter semantics, side-effect details, return behavior, and tool-selection guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description says nothing about repo, branch, script, execute, or project. The agent is left to guess what each parameter means, making correct invocation largely a matter of luck.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Run the local pipeline') and outcome ('regenerate+publish Sonar results'), so an agent can understand the core function. However, it does not meaningfully distinguish the tool from siblings like sonar_remedy_run or sonar_remedy_run_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the eleven sibling tools. It names no alternatives, exclusions, or conditions such as 'use when results are stale' or 'use for local-only analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bind reviewed check commands and the current target snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | ||
| checks | Yes | ||
| execute | No | ||
| approve_checks_sha256 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the action and does not state whether binding mutates state, requires approval, is reversible, or affects later run/schedule operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler and is front-loaded with the action. Its brevity is structurally appropriate, even though it sacrifices other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter configuration tool with no annotations, no output schema, and 0% schema coverage, a one-line purpose is not enough. Missing context includes the meaning of required state and checks, the role of execute, the purpose of approve_checks_sha256, and how this differs from configure_project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and all four parameters are undocumented. The description loosely maps 'reviewed check commands' to checks and 'current target snapshot' to state, but it does not explain execute or approve_checks_sha256, nor does it provide value formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a real action ('Bind') and names the resources involved ('reviewed check commands' and 'current target snapshot'), so it is not a tautology. However, the phrasing is jargon-heavy and does not distinguish this tool from the sibling sonar_remedy_configure_project or other remedy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, what prerequisites must exist before binding, or which alternative sibling tools should be used instead. An agent must infer the intended workflow from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a project's Sonar/repo config non-interactively. The token is NOT stored here — the user sets SONAR_TOKEN separately (masked).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| provider | No | ||
| repo_url | Yes | ||
| sonar_url | Yes | ||
| allow_http | No | ||
| local_path | Yes | ||
| main_branch | No | ||
| project_key | Yes | ||
| worktree_root | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own; it usefully states that the token is NOT stored and that the operation is non-interactive. It does not disclose whether the config is created or overwritten, where it is saved, or what other side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence definition with the primary action front-loaded and the security note following naturally. It contains no filler, though it leans too sparse for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 required parameters, no output schema, and no annotations, the description is far too minimal. It omits return behavior, storage location, overwrite semantics, and any relationship to sibling tools, leaving an agent without enough context to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 9 undocumented parameters. It only clarifies that the token is external (SONAR_TOKEN) and does not explain any required parameters such as name, sonar_url, project_key, repo_url, local_path, or worktree_root.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Save a project's Sonar/repo config' and qualifies it with 'non-interactively,' which makes the action clear. It does not explicitly contrast with the sibling sonar_remedy_configure, but the project-level scope provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in non-interactive/automated contexts and gives an important operational note that SONAR_TOKEN must be set separately. However, it does not state when to use this tool versus sonar_remedy_configure or any other sibling, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch Sonar issues for a project into an export (chunked if over budget).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| output | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions chunking over budget, but does not clarify whether the operation is read-only, whether it writes or modifies files, what side effects occur, or any auth/rate-limit concerns. The description is too sparse for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the core action front-loaded. The parenthetical 'chunked if over budget' adds useful behavior, though the term 'budget' is ambiguous. No waste, but slight under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three undocumented parameters, no output schema, no annotations, and a large sibling family, the description is far too minimal. It omits parameter semantics, return behavior, side effects, and when to choose this tool over siblings, leaving significant gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (repo, output, project) with zero description coverage, and the tool description does not explain any of them. 'For a project' hints at the project parameter, but repo and output are completely undefined, leaving the agent unable to construct a correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (Fetch), a resource (Sonar issues for a project), and an outcome (into an export), with a notable behavioral detail (chunked if over budget). It is distinct enough from sibling tools like sonar_remedy_run or sonar_remedy_status, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as sonar_remedy_run, sonar_remedy_slice, or sonar_remedy_progress. There is no mention of prerequisites, exclusions, or the specific scenario where fetching into an export is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Serially apply a recorded proposal and run bound checks.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | ||
| state | Yes | ||
| execute | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects and operational behavior. It discloses that the operation is serial and that bound checks are run, but it does not say whether this mutates state, whether it is destructive or reversible, what 'apply' actually changes, or what happens when 'execute' is absent. For an integration tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no filler; it front-loads the main action and sequencing. It could be called under-specified, but as far as conciseness and structure go, every word earns its place. It is appropriately sized for a one-line summary, though not for complete usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and three undocumented parameters, the description is not complete enough for reliable invocation. The agent is left guessing about what a 'recorded proposal' is, what 'state' and 'job' must contain, what 'execute' controls, and what the return behavior is. It gives the gist but not enough context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain 'job,' 'state,' or 'execute.' The description does not even hint at how the recorded proposal maps to the parameters. This leaves the agent without any parameter-level meaning beyond the bare names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Serially apply a recorded proposal' and adds the secondary action 'run bound checks.' This is clear enough to distinguish it from generic run/status siblings, though 'recorded proposal' is unexplained domain jargon. It is not a tautology and gives a real sense of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to choose this tool over siblings like sonar_remedy_run, sonar_remedy_run_all, or sonar_remedy_slice. There are no explicit conditions, exclusions, or alternatives mentioned. The only hint is the adverb 'serially,' which is not developed into usable decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a human-readable progress file.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Write' implies a file mutation, but the description does not state side effects, file location, overwrite behavior, required permissions, or return value. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is under-specified rather than efficiently complete. It does not earn its brevity because it omits essential usage and parameter information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single undocumented required parameter, the description leaves virtually everything to the agent's imagination. It does not specify the file's purpose, content format, or integration with the other sonar_remedy tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes a single required 'state' string with 0% description coverage, and the tool description does not mention 'state' at all. The description adds no meaning to the parameter, so the agent cannot infer what value to supply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Write') and a resource ('a human-readable progress file'), so it is not a pure tautology. However, it lacks specificity: it does not say what kind of progress file, where it is written, or how it relates to the sibling sonar_remedy_* tools, leaving the agent uncertain about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many siblings (fetch, status, run, etc.). No conditions, prerequisites, or alternatives are mentioned, so an agent has no basis for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved project configs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'List' clearly signals a read-only operation, but the description does not mention what the result contains, whether any state is accessed or modified, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence conveys the operation and resource with no wasted words. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, but the description is minimal. It provides enough to invoke the tool, but the lack of any output or return-value detail leaves some ambiguity about what 'project configs' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, and there are no parameters, so parameter semantics are trivially complete. The baseline for zero-parameter tools is 4; no further description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and a specific resource ('saved project configs'), which also differentiates it from sibling tools like sonar_remedy_run or sonar_remedy_configure_project. It is unambiguous about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. Sibling names suggest related operations, but the description provides no explicit selection criteria, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lease/process a bounded manual proposal batch.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | ||
| resume | No | ||
| execute | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'lease/process' but does not explain side effects, whether the operation is idempotent, what 'bounded' means, or what happens on execution. The boolean 'execute' parameter hints at a dry-run vs. execution mode, but the description does not clarify this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than efficiently informative. It front-loads the action but omits essential context that would make the sentence useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, no output schema, and a terse description, the tool definition is incomplete. An agent cannot reliably determine how to invoke this tool correctly, what the parameters mean, or what the outcome will be.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four undocumented parameters. It does not explain 'state', 'limit', 'resume', or 'execute' beyond their names. The term 'bounded' loosely maps to 'limit', but no concrete semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lease/process a bounded manual proposal batch' identifies a specific action (lease/process) and resource (a bounded manual proposal batch), which is more than a tautology. However, it does not distinguish this tool from siblings like sonar_remedy_run_all or sonar_remedy_slice, and the meaning of 'lease/process' is ambiguous without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sonar_remedy_run_all or sonar_remedy_schedule. The description implies a manual batch operation but does not state conditions, prerequisites, or exclusions, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch + slice every chunk into its own queue.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| state | Yes | ||
| execute | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects and behavior. It hints that the tool queues chunks, but it does not explain whether this executes remediations, mutates state, requires prior setup, or has rate/ordering implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is terse and front-loaded, but it is under-specified rather than efficiently complete. It leaves too much implicit for a tool with four parameters and no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, 0% schema coverage, no output schema, and many closely named siblings, this description is far too thin. It does not explain what 'every chunk' means, how the parameters affect execution, or what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters: repo, state, execute, project. The required state parameter is completely unexplained, so an agent cannot determine what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names concrete operations ('Fetch + slice') and a scope ('every chunk'), so it is not a tautology. However, it does not identify the input resource (repo/project) or what 'chunk' refers to, and it does not clearly distinguish run_all from the related fetch/slice/run siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus sonar_remedy_fetch, sonar_remedy_slice, sonar_remedy_run, or the other siblings. No exclusions, prerequisites, or alternative-selection conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the parallel/serial plan for pending jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Show' implies a read-only informational operation, which is useful, and 'pending jobs' clarifies scope. However, it does not describe side effects, return format, or what the 'state' parameter controls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It front-loads the action and resource, making the core purpose immediately understandable, although the missing parameter detail is penalized elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, no output schema, and no annotations, the description is too sparse. It omits the meaning of the required 'state' parameter, gives no output expectations, and lacks any guidance on alternatives among the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only required parameter, 'state', has no schema description and is not mentioned in the tool description. Schema description coverage is 0%, and the description adds nothing about accepted values or how state affects the plan, leaving the agent unable to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Show', and a concrete resource, 'the parallel/serial plan for pending jobs'. It distinguishes the tool from siblings like sonar_remedy_progress or sonar_remedy_status by focusing on the plan rather than execution state or results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of the sibling tools, nor does it explain what 'state' should be provided. An agent cannot tell whether this is for pre-run planning, post-run reporting, or filtering by job state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a durable queue from an export.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| state | Yes | ||
| export | Yes | ||
| execute | No | ||
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden, but it does not explain side effects, persistence guarantees, whether 'execute' acts as a dry-run flag, idempotency, or required state handling. 'Create' implies a mutation, but that is the only behavioral signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clean sentence with no redundancy, but it is under-specified for a tool with five parameters and no annotations. This brevity reads as under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and five parameters, the description is too thin for an agent to invoke the tool correctly. Critical knowledge about parameter meanings, execution behavior, and when to use the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'export.' Required parameters like 'state' and optional ones like 'repo,' 'project,' and 'execute' are completely unexplained, so the description does not compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and object: 'Create a durable queue from an export.' This conveys the core purpose and distinguishes it from run/schedule/status siblings, though terms like 'durable queue' and 'slice' remain somewhat unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like sonar_remedy_run or sonar_remedy_schedule. There are no prerequisites, conditions, or exclusions, leaving the agent to infer usage entirely from the tool name and a one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the queue's next action and ETA.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose that the output includes the next action and ETA, which is useful on its face, but it does not mention side effects, read-only guarantees, failure modes, or how the 'state' input affects the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with no filler and the core reporting purpose is front-loaded. It is concise, though the conciseness comes at the cost of omitting parameter and usage context, which is penalized elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an undocumented required parameter, the description is too sparse. It names the expected type of result but fails to explain the meaning of 'state', the structure of the report, or how this relates to the queue and sibling operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'state' parameter at all. Since the schema only says the parameter is a required string, the agent has no idea what valid states are, what formats are accepted, or what relationship 'state' has to the queue's next action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Report') and resource ('the queue's next action and ETA'), so an agent can tell this tool is about queue status. However, it does not distinguish itself from the sibling sonar_remedy_progress, which likely overlaps in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus any sibling, nor does it mention prerequisites, conditions, or exclusions. The agent is left to infer that status is useful for checking queue progression, but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0sonar_remedy_analyzesonar_remedy_configuresonar_remedy_configure_projectsonar_remedy_fetchsonar_remedy_integratesonar_remedy_progresssonar_remedy_projectssonar_remedy_runsonar_remedy_run_allsonar_remedy_schedulesonar_remedy_slicesonar_remedy_statusScored across 12 tools
Most tools target distinct workflow stages, but run_all is misleading (it actually fetches and slices rather than running all processing) and status/schedule overlap somewhat. Descriptions are clear enough to resolve most ambiguity.
All tools share the consistent sonar_remedy_ prefix and snake_case style, which is predictable. However, suffixes mix plain verbs (fetch, slice, integrate) with nouns (projects, status, progress) and verb+object (configure_project), so the pattern is not fully uniform.
Twelve tools cover a multi-stage Sonar remediation workflow without feeling bloated. Each tool maps to a meaningful operation or report, and the count is well-scoped for the domain.
The set covers configuration, fetching, queueing, processing, integration, analysis, and status reporting for the remediation pipeline. Minor lifecycle operations such as explicitly deleting/resetting a queue or updating a saved project config are absent but workaroundable.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Governance copilot for AI-assisted coding. 72 packs, 532 rules, proof bundles.
