Conectar Claude a WordPress: ejecuta WP-CLI y comprueba cada cambio con Relvato

Dos mitades: cambiar el sitio y comprobarlo

WP-CLI es la línea de comandos de WordPress. Lista plugins, los actualiza, exporta la base de datos, compara los archivos del núcleo con WordPress.org y mucho más. Es la forma en que un asistente cambia un sitio. Lo que no puede mostrarte es el sitio tal como lo ve un visitante: si el checkout sigue cobrando, si el formulario de inicio de sesión sigue enviándose, si una página sigue siendo rápida.

Ese es el hueco detrás de casi todas las historias de «una actualización me rompió el sitio»: la actualización informa de que todo ha ido bien, y el fallo está en otra parte, en un formulario, un script o una plantilla. Relvato comprueba exactamente eso, en un navegador real, desde fuera. A través de su conector, un asistente puede pedir el estado de un sitio (site_overview), lanzar sus monitores ahora (trigger_scan), leer una ejecución en detalle (get_run) y obtener el informe que explica un fallo (get_fix_prompt).

Juntos forman un ciclo: cambiar algo con WP-CLI, comprobarlo con Relvato y leer el resultado antes de seguir, en la misma conversación.

Qué puede hacer cada Claude

Claude Code, en el terminal o dentro de la app de escritorio de Claude, puede ejecutar comandos de shell. Puede ejecutar WP-CLI sobre un sitio local o, por SSH, sobre uno remoto. Es la forma más directa de conectar Claude a WordPress.

El chat de la app de escritorio de Claude no puede ejecutar una shell, pero sí arrancar servidores MCP locales desde su archivo de configuración, así que puede usar el MCP Adapter de WordPress. Claude en la web y en el móvil solo se conecta a servidores remotos que inician sesión con OAuth, y el adapter inicia sesión con una contraseña de aplicación de WordPress, así que desde ahí no puedes cambiar un WordPress autoalojado; los sitios en WordPress.com pueden usar el conector propio de WordPress.com. El conector de Relvato funciona en todas las versiones de Claude.

Paso 1: añade el conector de Relvato

En Claude, abre Settings → Connectors, busca Relvato (o abre su página en el directorio), haz clic en Connect e inicia sesión en Relvato. En la pantalla de consentimiento permites al asistente leer tus sitios y resultados y hacer cambios: añadir sitios y monitores, cambiar horarios y lanzar escaneos. Si perteneces a una organización, eliges cuál de sus espacios de trabajo puede usar.

En Claude Code, añade el servidor con un comando e inicia sesión cuando te lo pida. Los clientes que no pueden iniciar sesión pueden usar una clave de API de Relvato. La página para desarrolladores tiene ambas opciones.

# Claude Code: añade Relvato, luego ejecuta /mcp dentro de Claude Code y elige Authenticate
claude mcp add --transport http relvato https://app.relvato.com/api/mcp

Paso 2: dale WP-CLI por SSH

WP-CLI puede ejecutar comandos en un servidor remoto por SSH. Pon alias de tus sitios en un wp-cli.yml en la carpeta desde la que arrancas Claude Code, y cada comando indica el sitio al que va. WP-CLI tiene que estar instalado en el servidor y accesible como wp para el usuario SSH, y tu clave SSH tiene que funcionar sin pedir contraseña.

Empieza con una copia de staging. Comprueba primero la conexión con un comando inofensivo: wp @staging core version debería mostrar tu versión de WordPress.

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

# comprueba la conexión
wp @staging core version

Paso 3: decide qué puede ejecutar sin preguntar

Por defecto, Claude Code pregunta antes de cada comando nuevo. En .claude/settings.json puedes aprobar de antemano los de solo lectura, dejar los cambios detrás de una confirmación y prohibir del todo los destructivos. Las reglas deny siempre ganan a las allow.

Dos precauciones. Las reglas coinciden con el comando tal como está escrito, así que wp @staging plugin list y wp @prod plugin list son reglas distintas. Y la propia documentación de Claude Code califica de frágiles las reglas que intentan fijar los argumentos de un comando. Tómalas como un cinturón de seguridad, no como un candado: el límite real es lo que el usuario SSH puede hacer en el servidor.

{
  "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 *)"
    ]
  }
}

Un caso real: actualizar plugins sin romper el checkout

Así funciona el ciclo en la práctica, primero en staging. Pregunta a Claude qué plugins están desactualizados. Ejecuta wp @staging plugin list --update=available. Después pide a Relvato el estado del sitio antes de tocar nada (site_overview), para tener una referencia con la que comparar.

Haz una copia de seguridad (wp @staging db export) y previsualiza la actualización (--dry-run). Actualiza un plugin, pide a Relvato que lance ahora los monitores del sitio (trigger_scan) y lee los resultados (get_run). Si falla el checkout, el inicio de sesión o un formulario, get_fix_prompt devuelve el mismo informe con el que trabaja la IA de Relvato: el stack del sitio, qué cambió justo antes y el error exacto. Claude puede razonar sobre la causa y, si hace falta, devolver el plugin a la versión anterior con WP-CLI.

Solo cuando staging está limpio lo repites en producción. Si el plugin de Relvato está conectado, Relvato también vuelve a lanzar sus monitores por sí solo tras las actualizaciones de plugins. Preguntar en la conversación te da la respuesta mientras sigues ahí.

Termina con pruebas de integridad que WP-CLI puede hacer por sí mismo: wp core verify-checksums compara los archivos del núcleo con WordPress.org, y wp plugin verify-checksums --all hace lo mismo con los plugins de WordPress.org. Los plugins premium no se pueden verificar así.

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, luego get_run
#  → si algo falló: get_fix_prompt, y vuelve atrás:
wp @staging plugin install woocommerce --version=<versión anterior> --force
wp @staging core verify-checksums
wp @staging plugin verify-checksums --all

Sin terminal: el WordPress MCP Adapter

WordPress 6.9 añadió la Abilities API, una forma estándar de que los plugins describan lo que saben hacer. El MCP Adapter, un plugin oficial de WordPress que vive fuera del núcleo y aún no ha llegado a la 1.0, convierte esas capacidades en un servidor MCP que un asistente puede usar. El antiguo plugin wordpress-mcp de Automattic está archivado en su favor.

No está en el directorio de plugins de WordPress.org: lo descargas de sus releases de GitHub y WordPress no lo actualiza por ti. Los pasos de abajo lo instalan, comprueban que funciona, dan al asistente su propia cuenta y conectan Claude.

MCP Adapter, paso 1: revisa los requisitos

WordPress 6.9 o posterior: la Abilities API forma parte del núcleo, así que no hay que instalar un plugin aparte (las versiones antiguas del adapter lo necesitaban y ya no está soportado). PHP 7.4 o posterior. Enlaces permanentes «bonitos»: con Ajustes → Enlaces permanentes en «Simple», la dirección REST del adapter no responde.

Para un sitio remoto también necesitas HTTPS: WordPress solo ofrece contraseñas de aplicación por HTTPS (o en un sitio marcado como entorno local), y la conexión remota inicia sesión con una.

MCP Adapter, paso 2: descárgalo e instálalo

Con WP-CLI, un comando descarga de GitHub la versión estable más reciente y la activa: la dirección de abajo apunta siempre a la release que GitHub marca como Latest. Ejecútalo primero en staging, como los pasos de WP-CLI de arriba.

Sin WP-CLI: abre la página Releases del proyecto en GitHub, elige la release marcada como Latest y, en Assets, descarga mcp-adapter.zip. Sáltate la release llamada CI Artifacts que aparece arriba: es una versión previa llena de compilaciones de prueba de pull requests, no algo para instalar. Luego, en WordPress, ve a Plugins → Añadir nuevo plugin → Subir plugin, elige el zip, pulsa Instalar ahora y después Activar plugin.

Usa la 0.6.1 o posterior, nunca la 0.6.0: el zip de esa versión podía provocar un error fatal en cargas de página normales cuando otro plugin comprobaba si existía WP-CLI, y la 0.6.1 existe solo para corregirlo. Para actualizar más adelante, ejecuta el mismo comando con --force o sube el zip nuevo de la misma forma. Los desarrolladores de plugins que lo incluyen pueden requerirlo con Composer (composer require wordpress/mcp-adapter, con el Jetpack Autoloader); para usarlo en un sitio, el plugin es el camino más sencillo.

# 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, paso 3: confirma que funciona

El plugin crea su servidor por defecto en cuanto está activo. wp mcp-adapter list debería mostrar mcp-adapter-default-server, y su dirección es /wp-json/mcp/mcp-adapter-default-server en tu sitio. En wp-admin, MCP Adapter aparece activo en Plugins → Plugins instalados.

Si la dirección responde con un 404, revisa primero los enlaces permanentes. Si responde que no has iniciado sesión, el servidor funciona: solo habla con usuarios identificados, que es el paso siguiente.

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

MCP Adapter, paso 4: un usuario propio y una contraseña de aplicación

No conectes tu propia cuenta de administrador. Crea un usuario para el asistente con el rol más bajo que sirva para la tarea —Editor para contenido, Administrador solo si de verdad debe gestionar plugins—, porque todo lo que hace el asistente se ejecuta con los permisos de ese usuario.

Después dale a ese usuario una contraseña de aplicación: en wp-admin abre Usuarios, edita el usuario, busca Contraseñas de aplicación, escribe un nombre como «Claude» y pulsa Añadir nueva contraseña de aplicación. WordPress la muestra una vez; cópiala en ese momento. Puedes revocarla desde ahí cuando quieras, lo que desconecta al asistente sin tocar nada más.

# 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, paso 5: conecta Claude Code

Claude Code con el sitio en la misma máquina: Claude arranca el adapter por su cuenta a través de WP-CLI, con la sesión del usuario que indicas con --user (STDIO, sin contraseña).

Claude Code con un sitio remoto, o la app de escritorio de Claude: ambos pasan por @automattic/mcp-wordpress-remote, un pequeño proxy de Automattic que se ejecuta en tu ordenador (necesita Node.js) y habla con el sitio por HTTPS con la contraseña de aplicación del usuario.

# 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, paso 6: conecta la app de escritorio de Claude

En la app de escritorio, abre Settings → Developer → Edit Config, añade el bloque de abajo a claude_desktop_config.json y reinicia Claude. La contraseña queda en ese archivo en texto plano, así que mantenlo en tu propio equipo.

{
  "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, paso 7: qué puede hacer Claude una vez conectado

Claude ve tres herramientas del servidor por defecto: mcp-adapter/discover-abilities lista lo que ofrece el sitio, mcp-adapter/get-ability-info describe una capacidad y mcp-adapter/execute-ability la ejecuta. Las capacidades son privadas por defecto: solo aparecen las que un plugin marca como públicas (meta.public), y cada una sigue comprobando los permisos del usuario al ejecutarse.

Así que lo que puede hacer el asistente depende de tus plugins: un sitio recién instalado ofrece poco, y la vista previa para desarrolladores de WooCommerce añade productos y pedidos. Pide primero a Claude que liste las capacidades, para que ambos sepáis qué puede tocar, y tras cada cambio que haga ejecuta tus monitores de Relvato en la misma conversación, igual que en el flujo de WP-CLI de arriba.

Con el plugin de Relvato (1.42.0 o posterior) en el sitio, discover-abilities también lista las de Relvato: relvato/get-site-status, relvato/list-monitors, relvato/get-fix-brief y relvato/run-monitors. Necesitan una cuenta de administrador, así que con el usuario Editor del paso 4 no aparecen; para ese ciclo usa entonces el conector de Relvato del paso 1. Qué hace cada una está en la documentación de la API de Abilities de WordPress.

Salvaguardas que importan más que el prompt

Un asistente es exactamente tan seguro como la cuenta con la que actúa. Usa primero una copia de staging, una copia de seguridad antes de cada cambio y un usuario SSH y de WordPress con solo el acceso que la tarea necesita. Deja los cambios detrás de una confirmación, y no uses Claude Code con las confirmaciones desactivadas en un sitio en producción: su documentación lo reserva para contenedores y máquinas virtuales aislados.

Comprueba después de cada cambio, no solo antes. WP-CLI puede decirte que una actualización ha terminado. Solo una prueba desde fuera te dice que el sitio sigue funcionando para quienes lo usan. Por eso el conector de Relvato está hecho para este ciclo, y por eso deliberadamente no puede borrar datos, aprobar cambios de archivos o scripts ni tocar claves de API: eso se queda en el panel de Relvato, donde lo revisas tú. Lo que sí puede cambiar, como aceptar un cambio visual, lo hace solo después de que lo confirmes, y cada una de esas decisiones se puede deshacer.

Usar ChatGPT en lugar de Claude

Relvato también es un plugin en ChatGPT. Añádelo desde esa página e inicia sesión en Relvato. La pantalla de consentimiento y las herramientas son las mismas que en Claude: ChatGPT puede pedir el estado de un sitio (site_overview), lanzar sus monitores ahora (trigger_scan), leer una ejecución en detalle (get_run) y obtener el informe que explica un fallo (get_fix_prompt).

Eso cubre la mitad de esta guía que comprueba el sitio. ChatGPT no tiene una terminal en tu servidor, así que los pasos de WP-CLI de arriba siguen siendo cosa de Claude Code o de tu propia terminal: haz el cambio allí y luego pide a ChatGPT que lance los monitores de Relvato del sitio y te explique lo que encontraron.