HomeFeaturesPricingDocumentationContactDOWNLOAD

AI editor setup overview

How SiteCMD's MCP server lets your AI editor read scan results, request fixes, and verify them.

If your AI editor speaks MCP (Model Context Protocol), it can talk to SiteCMD directly. Your AI sees your scan results, can pull fix prompts written specifically for the failing checks, and can verify its own fixes by comparing scans before and after.

This page covers what MCP is, what SiteCMD exposes through it, and the pieces that work the same across every supported editor. For per-editor setup commands, see the page for your editor:

What MCP is

Model Context Protocol is an open standard for letting AI tools talk to other tools. An MCP server exposes a set of named functions (called “tools”), each with a description and a parameter schema. The AI editor decides when to call which one based on what you’re asking it to do.

Three things make this useful:

  1. The AI doesn’t have to guess. When you say “fix the failing accessibility issues on this page,” it can call get_issues to see the real list, not invent plausible-looking ones.
  2. Permissions stay with the user. MCP servers run locally, on your machine, under your account. The AI can’t reach into SiteCMD’s data without your explicit consent to use the MCP integration.
  3. The protocol is the same across tools. Configure your editor once, and the same MCP server works whether you switch editors next month.

SiteCMD ships an MCP server (sitecmd-mcp) as part of the desktop app. When configured, your editor spawns it as a subprocess and talks to it over stdio.

What you need first

For Claude Code, Codex, and Cursor you need nothing: open SiteCMD, go to Integrations, and connect the editor. The app finds your Node, checks that it is new enough and that its built-in node:sqlite module works, copies the server into persistent application data, and writes the config itself. If your Node is too old it says so rather than writing a configuration that cannot start, and a stale path or changed argument later shows as Repair, never as connected.

For every other editor, or to wire one up by hand, you need two things:

  • Node 22.22.1 or newer on your PATH. The server reads SiteCMD’s local database through Node’s built-in node:sqlite module, and 22.22.1 is the first release whose node:sqlite passes the server’s own test suite. Check with node --version.
  • The persistent server script. The desktop app copies sitecmd-mcp.mjs into its application-data folder each time it starts, so point your editor at that copy, never at the app bundle or installation directory (an AppImage mount disappears when the app closes):
OS Persistent MCP script
macOS ~/Library/Application Support/com.sitecmd.app/sitecmd-mcp/sitecmd-mcp.mjs
Linux $XDG_DATA_HOME/com.sitecmd.app/sitecmd-mcp/sitecmd-mcp.mjs when set; otherwise ~/.local/share/com.sitecmd.app/sitecmd-mcp/sitecmd-mcp.mjs
Windows %LOCALAPPDATA%\com.sitecmd.app\sitecmd-mcp\sitecmd-mcp.mjs; %APPDATA% is used when %LOCALAPPDATA% is unavailable

Expand ~ and environment variables to an absolute path before pasting into JSON or TOML; editor config files do not expand them.

Every setup example passes one argument before the script path: --disable-warning=ExperimentalWarning. Node prints an ExperimentalWarning for node:sqlite on every start, and some editors surface anything on stderr as an error. No other sqlite feature flag is needed on Node 22.22.1 or newer, and the app’s own launcher does not pass one.

What SiteCMD exposes

The MCP server provides these tools to your AI editor:

Tool What it does
get_projects List every project tracked in SiteCMD, with URLs and detected frameworks.
get_scan_score Get the latest score and category breakdown for a specific site URL.
get_issues List failing issues from the latest scan. Can be filtered by status, severity, and category.
get_fix_prompts Return fix prompts for selected failing checks. These are written with enough context that the AI can act on them directly.
get_scan_history Return scan score history over time for a URL, useful for trend analysis.
get_dismissed_issues Return issues that have been dismissed or marked not applicable. The AI should skip these when suggesting fixes.
compare_scans Compare the two most recent scans for a URL. Shows what was fixed, what’s new, and what regressed. The right tool to call after the AI has made changes.
request_scan Return guidance to the AI about how to ask the user to run a scan. The actual scan still runs in the desktop app, not via MCP.
get_fix_brief Read the full fix brief for a fix attempt: the issue, where to fix it in the repository, and the acceptance criteria.
request_verification Tell SiteCMD a fix attempt is complete so it can re-run the check and verify it. This does not mark the issue fixed; SiteCMD verifies independently.
list_fix_attempts List fix attempts that are currently open (briefed, verify-requested, or verifying).

That covers the core fix-loop tools. The server also exposes six correlation tools (Correlation Engine v3) that work from a project_id rather than a URL:

Tool What it does
get_active_correlations Return all active issue groups for a project with v3 enrichments: transitive causes, downstream effects, recent events, and more.
get_recent_events Return site events (deploys, traffic signals) tied to check IDs within the last N days.
get_likely_causes Return the direct and transitive likely causes for a specific check ID in a project.
get_causal_graph Return the active causal graph for a project as a node-link payload, suitable for visualization.
preview_deploy_risk Given a list of files about to change in a deploy, predict which active issues are likely to regress.
whatif_resolve Given a hypothetical set of resolved check IDs, return the downstream effects likely to also resolve.

The naming and behavior of these tools is identical across every editor. If the editor’s documentation says “this is what we’ll send to the MCP server,” that’s what SiteCMD will receive.

The typical workflow

A normal MCP-driven session looks like this:

  1. You pick an 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, and the acceptance criteria.
  2. The AI calls list_fix_attempts and get_fix_brief. It reads the brief, and get_issues or get_fix_prompts for context, instead of inventing a plausible-looking list.
  3. The AI makes edits. It modifies your source files with the changes the brief and prompts call for.
  4. The AI calls request_verification. SiteCMD re-runs that one check within a few seconds and records the verdict on the attempt. The AI never marks an issue fixed.
  5. You re-run the scan. Either by clicking Run Scan in SiteCMD, or by letting the AI prompt you to (request_scan returns the instructions). The AI does not start scans on its own.
  6. The AI calls compare_scans. It sees what its changes fixed, what they didn’t fix, and what (if anything) they broke.
  7. Iterate. If verification failed or something regressed, the AI sees that immediately and can address it.

This loop is the entire point of the integration. Without MCP, your AI is guessing at what’s wrong with your site. With MCP, it’s working from the actual scan output and SiteCMD checks the result.

What MCP does not do

  • Run scans by itself. Scans are a user action. The desktop app runs them. The AI can ask you to run one (via request_scan), but it can’t push the button.
  • Modify SiteCMD data. The server can’t dismiss issues, change issue statuses, or mark things fixed; those are user actions in the desktop app. Its one write is request_verification, which only signals that a fix attempt is ready to check. SiteCMD re-runs the check and decides the outcome itself.
  • Reach across projects. When the AI calls get_issues, it asks for a specific site URL. There’s no “give me everything” mode.

Auth model

The MCP server runs on your machine, as your user, against the same local database the desktop app uses. There is no separate API key for MCP. If the desktop app can see a project, the MCP server can read it. If you don’t want a specific editor to have access, don’t configure the MCP server in that editor.

This is intentionally simpler than the API-key model some MCP servers use. SiteCMD’s data is local; no remote endpoint needs to authenticate the call.

Multiple editors

If you use more than one AI editor (Cursor in the morning, Claude Code in the afternoon), they can all point at the same SiteCMD MCP server. You configure each one separately, but the underlying server and data are shared.

You don’t need to “switch” SiteCMD between editors. Each editor spawns its own subprocess copy of sitecmd-mcp and talks to it independently. Reads work with the desktop app closed, but verification needs it running: request_verification asks the app to re-run the check. With the app closed, results are only as fresh as the last time it was open.

When MCP isn’t enough

If your editor does not support MCP, open the finding in SiteCMD and copy its fix prompt into the tool you use. Reports and exports cover workflows where a person or another system needs a portable result.

The standalone CLI is available for scripts, pre-push hooks, and CI pipelines. It runs the live-site Web Scan and the free local Code Scan without the desktop UI. On a connected site, sitecmd gate and sitecmd connected --submit add shared baseline or deployment context. Core Web Vitals and the axe-core accessibility deep scan need a browser engine the CLI ships without; they run in the desktop app and in hosted scheduled scans on connected sites. See CLI reference.