Fixing with AI editors

You've run a scan. You have findings. Some of them are obvious one-line fixes; most of them aren't. This is where AI editors earn their keep, and where SiteCMD's MCP integration changes how the work feels.

This page is the overview of the fix-with-AI workflow. For setting up your specific editor, see AI editors.

The loop

SiteCMD's MCP server gives your editor two ways in. The quick one reads a small page of findings and fetches guidance for the selected check. The verified one runs through a fix attempt, which is how SiteCMD checks the agent's work for it:

1. Pick the issue in SiteCMD and click Fix with your agent, or have the agent open the attempt itself with start_fix while the app is running. Either way SiteCMD opens a fix attempt and writes its fix brief: the issue, where to fix it in the repository, and the acceptance criteria.
2. The agent reads the brief. It calls get_fix_brief with the known attempt ID. Use list_fix_attempts only to find an existing attempt whose ID is unknown. The brief supplies the working context; fetch additional evidence only if something needed for the fix is missing. See focused context and pending requests.
3. The agent edits your source. Nothing in SiteCMD changes yet.
4. The agent calls request_verification with a summary of what it changed, then polls get_fix_status. SiteCMD runs the required check or source audit and records whether verification succeeded. The duration depends on that work. The agent cannot mark anything fixed; SiteCMD decides.
5. Run a broader scan when needed. Start it in SiteCMD, or have the agent call run_scan with scope: "web", "code", or "full", then poll get_scan_status. For live-site changes, compare_scans shows differences between two Web Scans. It does not compare Code Scan reports; use verification and current issues for source fixes.
6. Iterate. A failed verification or a regression comes back with the evidence, and the agent tries again against the same acceptance criteria.

Without a fix attempt, the agent can triage a small page from get_issues, read get_issue for the selected check, edit, and scan again. When it wants SiteCMD checking its work, it opens an attempt with start_fix.

What makes this different from "ask the AI to write some code" is that the verification is not the AI's opinion. SiteCMD re-runs the same check that caught the issue, and if the fix didn't work, the AI sees that immediately.

What the AI sees

When the editor calls SiteCMD's MCP server, it gets back structured data, not vibes:

• The check ID that failed (so the editor can look it up in its own context if needed)
• The exact severity, category, and confidence
• The location (URL, file path, line number where applicable)
• The fix prompt written specifically for that check
• Detected framework (Next.js, Astro, Rails, etc.) from get_projects, so the agent knows which stack it is editing

The fix prompts carry the check's context so the editor can act without asking you to restate the finding, and they come back ranked by causal reach: the issue most likely to be causing others comes first. On a fix attempt, the fix brief goes further and maps the issue to the repository locations where the fix belongs.

Why this is better than copy-pasting

The old workflow:

1. You read the SiteCMD finding.
2. You copy-paste the finding into your AI chat.
3. The AI guesses what your codebase looks like.
4. You implement what it suggests.
5. You re-run the scan and hope it's fixed.

The MCP-integrated workflow:

1. You ask the AI to fix it.
2. The AI reads the finding, the fix prompt, your detected framework, your file structure.
3. It makes the edit.
4. The AI requests verification and reads SiteCMD's result.

The differences add up. Less context-passing. Less hallucination about what your codebase contains. Verifiable feedback after each attempt.

What the AI can't do

A few things to know upfront:

• MCP does not run a scanner. run_scan asks the desktop app to perform the scan. With the app stopped, scan and start-fix requests wait and expire after 24 hours. The separate CLI can scan without the desktop app.
• MCP cannot directly change issue lifecycle states. Ignore, Block, Snooze, and Reopen are desktop controls. An agent requests verification instead of declaring its own fix successful.
• MCP grants access to the local project database. Project selectors are filters, not access restrictions. Your configured editor can read findings from any project; returned evidence and source excerpts may reach its model provider under the editor's settings. See the access model.

Supported editors

Editor	Setup page
Cursor	Cursor integration
Claude Code	Claude Code integration
Windsurf	Windsurf integration
VS Code	VS Code integration
GitHub Copilot	GitHub Copilot integration
Cline	Cline integration
JetBrains IDEs	JetBrains integration
Zed	Zed integration
OpenAI Codex CLI	Codex integration

If your editor speaks MCP, it works. Setup takes about a minute per editor (paste a config snippet, restart the editor, you're done). For the protocol-level overview, see AI editor overview.

Without MCP

If you can't use MCP (different editor, restricted environment, just don't want to), you can still get most of the value:

• The Issues page detail view shows the full fix prompt for any finding. Copy it and paste it into any chat-style AI session.

The MCP workflow is faster because there's no copy-paste step. But the underlying fix prompts are the same regardless of how you get them to your AI.

What fix prompts look like

Each fix prompt is structured to give an AI editor enough context to act:

• What the check verifies and why it matters, in plain language
• The severity, category, and check ID, so the fix lands on the right finding
• Causal context when the issue is linked to others: what likely causes it, and what it likely causes downstream
• The fix instruction written for that specific check

Prompts come back ranked by causal reach, so the first one is the issue whose fix is most likely to clear others below it.

The verification habit

The single biggest improvement to your fix-with-AI flow is making verification a habit. After every set of fixes:

1. Have the AI call request_verification on its fix attempt and poll get_fix_status for SiteCMD's verdict.
2. Run a broader Web, Code, or Full scan when needed and wait for it to complete.
3. For Web Scans, use compare_scans to review changes. For Code Scan, review the verified attempt and current findings.

This is the loop that turns AI-assisted fixing from "guess and check" into something reliable. Without it, you're back to copy-pasting and hoping.