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 its monitors 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.

The chat in Claude's desktop app can't run a shell, but it can start local MCP servers from its configuration file, so it can use WordPress's MCP Adapter. Claude on the web and on mobile only connects to remote servers that sign in with OAuth, and the adapter signs in with a WordPress Application Password, so from there you can't change a self-hosted WordPress site; sites on WordPress.com can use WordPress.com's own connector. 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 monitors, 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 monitors 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 its monitors by itself after plugin updates. Asking in the conversation just gets you the answer while you're still there.

Finish with integrity tests 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 WordPress plugin that lives outside core and is still before its 1.0 release, turns those abilities into an MCP server an assistant can use. Automattic's earlier wordpress-mcp plugin is archived in its favour.

It isn't in the WordPress.org plugin directory: you download it from its GitHub releases, and WordPress won't update it for you. The steps below install it, prove it's running, give the assistant its own account, and connect Claude.

MCP Adapter, step 1: check the requirements

WordPress 6.9 or newer — the Abilities API is part of core, so there's no separate Abilities API plugin to install (older versions of the adapter needed one; it's no longer supported). PHP 7.4 or newer. Pretty permalinks: with Settings → Permalinks set to Plain, the adapter's REST address doesn't answer.

For a remote site you also need HTTPS: WordPress only offers Application Passwords over HTTPS (or on a site marked as a local environment), and the remote connection signs in with one.

MCP Adapter, step 2: download and install it

With WP-CLI, one command downloads the newest stable release from GitHub and activates it — the address below always points to the release GitHub marks as Latest. Run it against staging first, the way the WP-CLI steps above do.

Without WP-CLI: open the project's Releases page on GitHub, pick the release marked Latest, and under Assets download mcp-adapter.zip. Skip the release named CI Artifacts at the top of the list — it's a pre-release full of pull-request test builds, not something to install. Then in WordPress go to Plugins → Add New Plugin → Upload Plugin, choose the zip, click Install Now and then Activate Plugin.

Use 0.6.1 or later, never 0.6.0: that release's zip could cause a fatal error on normal page loads whenever another plugin checked for WP-CLI, and 0.6.1 exists only to fix it. To update later, run the same command with --force, or upload the newer zip the same way. Plugin developers who bundle the adapter can require it with Composer instead (composer require wordpress/mcp-adapter, with the Jetpack Autoloader); for running it on a site, the plugin is the simpler route.

# install and activate the latest stable release (0.6.1 on 1 Oct 2026)
wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# later: update to a newer release
wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --force

MCP Adapter, step 3: confirm it's running

The plugin creates its default server as soon as it's active. wp mcp-adapter list should show mcp-adapter-default-server, and its address is /wp-json/mcp/mcp-adapter-default-server on your site. In wp-admin, MCP Adapter appears as active under Plugins → Installed Plugins.

If the address answers with a 404, check the permalink setting first. If it answers that you aren't signed in, the server is up — it only talks to signed-in users, which is the next step.

wp plugin status mcp-adapter
wp mcp-adapter list
# → mcp-adapter-default-server, at /wp-json/mcp/mcp-adapter-default-server

MCP Adapter, step 4: a dedicated user and an Application Password

Don't connect your own admin account. Create a user for the assistant with the lowest role that can do the job — Editor for content work, Administrator only if it really has to manage plugins — because everything the assistant does runs with that user's capabilities.

Then give that user an Application Password: in wp-admin open Users, edit the user, find Application Passwords, enter a name such as “Claude” and click Add New Application Password. WordPress shows it once; copy it then. You can revoke it from the same place at any time, which disconnects the assistant without touching anything else.

# a user just for the assistant, with only the role it needs
wp user create ai-editor ai-editor@example.com --role=editor
# its Application Password (printed once)
wp user application-password create ai-editor "Claude" --porcelain

MCP Adapter, step 5: connect Claude Code

Claude Code, with the site on the same machine: Claude starts the adapter itself through WP-CLI, signed in as the user you name with --user (STDIO, no password needed).

Claude Code with a remote site, or the Claude desktop app: both go through @automattic/mcp-wordpress-remote, a small proxy from Automattic that runs on your computer (it needs Node.js) and talks to the site over HTTPS with the user's Application Password.

# Claude Code, site on this machine (STDIO through WP-CLI)
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

# Claude Code, remote site (HTTPS through Automattic's proxy; needs Node.js)
claude mcp add \
  -e WP_API_URL=https://example.com/wp-json/mcp/mcp-adapter-default-server \
  -e WP_API_USERNAME=ai-editor \
  -e WP_API_PASSWORD="xxxx xxxx xxxx xxxx xxxx xxxx" \
  wordpress -- npx -y @automattic/mcp-wordpress-remote@latest

MCP Adapter, step 6: connect the Claude desktop app

In the desktop app, open Settings → Developer → Edit Config, add the block below to claude_desktop_config.json and restart Claude. The password sits in that file in plain text, so keep it to your own machine.

{
  "mcpServers": {
    "wordpress": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "ai-editor",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

MCP Adapter, step 7: what Claude can do once connected

Claude sees three tools from the default server: mcp-adapter/discover-abilities lists what the site offers, mcp-adapter/get-ability-info describes one ability, and mcp-adapter/execute-ability runs it. Abilities are private by default — only the ones a plugin marks as public (meta.public) show up, and each still checks the user's permissions when it runs.

So what the assistant can do depends on the plugins you run: a fresh site exposes little, and WooCommerce's developer preview adds products and orders. Ask Claude to discover the abilities first, so you both know what it can touch — and after any change it makes, run your Relvato monitors in the same conversation, exactly as in the WP-CLI workflow above.

With the Relvato plugin (1.42.0 or newer) on the site, discover-abilities also lists Relvato's own: relvato/get-site-status, relvato/list-monitors, relvato/get-fix-brief and relvato/run-monitors. They need an administrator account, so with the Editor user from step 4 they stay hidden; use the Relvato connector from step 1 for that loop instead. What each one does is in the WordPress Abilities API doc.

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 test 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, approve file or script changes or touch API keys: those stay in the Relvato dashboard, with you looking. What it can change, like accepting a visual change, it does only after you confirm, and each of those decisions can be undone.

Using ChatGPT instead

Relvato is also a plugin in ChatGPT. Add it from that page and sign in to Relvato. The consent screen and the tools are the same as in Claude, so ChatGPT can ask for a site's health (site_overview), run its monitors now (trigger_scan), read a run in detail (get_run) and get the brief behind a failure (get_fix_prompt).

That covers the checking half of this guide. ChatGPT has no shell on your server, so the WP-CLI steps above stay with Claude Code or your own terminal: make the change there, then ask ChatGPT to run the site's Relvato monitors and explain what they found.