Connect Claude to WordPress: run WP-CLI and check every change with Relvato

Two halves: changing the site, and checking it

WP-CLI is WordPress's command line. It lists plugins, updates them, exports the database, checks core files against WordPress.org and more. It's how an assistant changes a site. What it can't show you is the site as a visitor sees it: whether checkout still takes a payment, whether the login form still submits, whether a page is still fast.

That's the gap behind most "an update broke my site" stories: the update itself reports success, and the break is somewhere else, in a form, a script or a template. Relvato checks exactly that, in a real browser, from outside. Through its connector an assistant can ask for a site's health (site_overview), run checks now (trigger_scan), read a run in detail (get_run), and get the brief behind a failure (get_fix_prompt).

Together they make a loop: change something with WP-CLI, check it with Relvato, and read the result before moving on, in the same conversation.

Which Claude can do what

Claude Code, in the terminal or inside Claude's desktop app, can run shell commands. It can run WP-CLI against a local site or, over SSH, a remote one. It's the most direct way to connect Claude to WordPress.

Claude on the web, on mobile and in the desktop chat can't run a shell. To change a site from there, use WordPress's MCP Adapter over HTTPS, or WordPress.com's own connector for sites hosted there. Relvato's connector works on every Claude surface.

Step 1: add the Relvato connector

In Claude, open Settings → Connectors, browse to Relvato (or open its directory page), click Connect and sign in to Relvato. On the consent screen you allow the assistant to read your sites and results and to make changes: add sites and checks, change schedules and run scans. If you belong to an organization, you pick which of its workspaces it can use.

In Claude Code, add the server with one command, then sign in when asked. Clients that can't sign in can use a Relvato API key instead. The developer page has both options.

# Claude Code: add Relvato, then run /mcp inside Claude Code and choose Authenticate
claude mcp add --transport http relvato https://app.relvato.com/api/mcp

Step 2: give it WP-CLI, over SSH

WP-CLI can run commands on a remote server over SSH. Put aliases for your sites in a wp-cli.yml in the folder where you start Claude Code, and each command names the site it's for. WP-CLI has to be installed on the server and reachable as wp for the SSH user, and your SSH key has to work without a password prompt.

Start with a staging copy. Check the connection with a harmless command first: wp @staging core version should print your WordPress version.

# wp-cli.yml
@staging:
  ssh: deploy@staging.example.com/var/www/html
@prod:
  ssh: deploy@example.com/var/www/html

# check the connection
wp @staging core version

Step 3: decide what it may run without asking

By default Claude Code asks before each new command. You can pre-approve the read-only ones, keep changes behind a prompt, and refuse the destructive ones outright, in .claude/settings.json. Deny rules always win over allow rules.

Two cautions. Rules match the command as written, so wp @staging plugin list and wp @prod plugin list are different rules. And Claude Code's own documentation calls rules that try to pin down a command's arguments fragile. Treat them as a seatbelt, not a lock: the real limit is what the SSH user can do on the server.

{
  "permissions": {
    "allow": [
      "Bash(wp @staging core version)",
      "Bash(wp @staging plugin list *)",
      "Bash(wp @staging plugin update * --dry-run)"
    ],
    "ask": [
      "Bash(wp @staging plugin update *)",
      "Bash(wp @staging db export *)"
    ],
    "deny": [
      "Bash(wp * db drop *)",
      "Bash(wp * db reset *)",
      "Bash(wp * eval *)",
      "Bash(wp * search-replace *)"
    ]
  }
}

A real workflow: update plugins without breaking checkout

Here is the loop in practice, on staging first. Ask Claude which plugins are out of date. It runs wp @staging plugin list --update=available. Then ask Relvato for the site's health before you touch anything (site_overview), so there's a baseline to compare against.

Take a backup (wp @staging db export) and preview the update (--dry-run). Update one plugin, then ask Relvato to run the site's checks now (trigger_scan) and read the results (get_run). If checkout, the login or a form fails, get_fix_prompt returns the same brief Relvato's own AI works from: the site's stack, what changed just before, and the exact error. Claude can reason about the cause, and roll the plugin back to the previous version with WP-CLI if needed.

Only when staging is clean do you repeat it on production. If the Relvato plugin is connected, Relvato also re-runs checks by itself after plugin updates. Asking in the conversation just gets you the answer while you're still there.

Finish with integrity checks WP-CLI can do on its own: wp core verify-checksums compares core files with WordPress.org, and wp plugin verify-checksums --all does the same for plugins from WordPress.org. Premium plugins can't be verified that way.

wp @staging plugin list --update=available
wp @staging db export
wp @staging plugin update woocommerce --dry-run
wp @staging plugin update woocommerce
#  → Relvato: trigger_scan, then get_run
#  → if something failed: get_fix_prompt, and roll back:
wp @staging plugin install woocommerce --version=<previous version> --force
wp @staging core verify-checksums
wp @staging plugin verify-checksums --all

Without a terminal: the WordPress MCP Adapter

WordPress 6.9 added the Abilities API, a standard way for plugins to describe what they can do. The MCP Adapter, an official plugin that is separate from core and still before its 1.0 release, exposes those abilities to AI assistants as an MCP server. Automattic's earlier wordpress-mcp plugin is archived in its favour.

The adapter speaks to local clients through WP-CLI (wp mcp-adapter serve) and to remote ones over HTTPS at /wp-json/mcp/mcp-adapter-default-server, signed in with a WordPress Application Password. Only abilities a plugin marks as public are exposed, so what the assistant can do depends on what your plugins publish. WooCommerce has a developer preview built on it for products and orders.

Give it a dedicated WordPress user with the least access it needs, not your admin account, and revoke the Application Password when you're done. Sites on WordPress.com can use WordPress.com's own MCP connector instead, on paid plans.

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# Claude Code, talking to a local site through WP-CLI
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

Guardrails that matter more than the prompt

An assistant is exactly as safe as the account it acts with. Use a staging copy first, a backup before every change, and an SSH user and WordPress user with only the access the job needs. Keep changes behind a prompt, and don't run Claude Code with permission prompts switched off on a live site: its documentation reserves that for isolated containers and virtual machines.

Check after every change, not just before. WP-CLI can tell you an update finished. Only a check from outside tells you the site still works for the people who use it. That's why the Relvato connector is built for this loop, and why it deliberately can't delete data, accept visual changes, apply fixes or touch API keys: those stay in the Relvato dashboard, with you looking.