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 findings and fix prompts. 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. 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 list_fix_attempts to find the open attempt and get_fix_brief to read it, with get_issues and get_fix_prompts for the surrounding context.
3. The agent edits your source. Nothing in SiteCMD changes yet.
4. The agent calls request_verification with a one-paragraph summary of what it changed. SiteCMD re-runs that check within a few seconds and records the result on the attempt as verified or failed. The agent cannot mark anything fixed; SiteCMD decides.
5. You re-run a scan and the agent calls compare_scans. Verification covers the one check; the scan comparison shows what else moved: fixed, new, and still open. Scans are yours to start (request_scan only returns instructions for asking you).
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 still do steps 2, 3, and 5 on its own from get_issues and get_fix_prompts; it just has no request_verification to call, so the scan comparison is the only check on its work.

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.) so framework-specific fix steps apply

The fix prompts include enough context that the editor can act without asking you for the same info. “Fix the missing Content-Security-Policy header” comes with the actual headers your site is currently sending, the platform you’re deployed on, and where in your code you’d typically add headers for that platform.

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. You re-run the scan and the AI verifies.

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:

• The AI can’t start scans on its own. Scans are a user action. The AI can prompt you (“ready for me to verify? Run the scan in SiteCMD”), but it can’t push the button. This is on purpose: scans can take time and you should decide when they run.
• The AI can’t dismiss issues. Ignore, block, and verify are all desktop-app actions. The AI sees findings and proposes fixes; it doesn’t quietly mark things “not applicable.”
• The AI can’t change what SiteCMD knows. Findings, history, dismissals, and verification results are SiteCMD’s to manage. The one thing an agent writes is a verification request on its own fix attempt, and SiteCMD still re-runs the check and decides.

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 is verifying (in plain language)
• What was found (the actual evidence: the headers you’re missing, the page that’s slow, the dependency that’s bad)
• Framework-specific fix steps when SiteCMD detected your framework
• Verification path (what to check after the fix)
• Effort estimate (quick / moderate / involved)

The “involved” effort tag is the AI’s signal that the fix isn’t a one-line change. It might involve refactoring, new files, or a design decision. Treat those as conversation starters, not autonomous fixes.

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 wait for SiteCMD’s verdict.
2. Re-run the scan.
3. Have the AI call compare_scans and look at what got fixed, what didn’t, and what (if anything) broke.

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.