wp-mcp-gateway (versión para Cloudflare Workers)

La misma idea que la versión para Node: un único endpoint MCP, cada llamada de herramienta recibe un site_id, de modo que un solo conector de Claude cubre toda tu flota de WordPress. Esta versión se ejecuta en Cloudflare Workers en lugar de en un VPS — no hay servidor que parchear, el plan gratuito cubre esto cómodamente y estará en vivo en una URL workers.dev a los pocos minutos de ejecutar wrangler deploy.

Está construido sobre el enfoque recomendado actualmente por Cloudflare: un createMcpHandler sin estado del SDK agents (el enfoque anterior con estado McpAgent / Durable Objects está obsoleto para servidores nuevos — este gateway no necesita estado de sesión de todos modos, ya que cada llamada de herramienta es independiente).

Verificado localmente de principio a fin antes de la entrega: el Worker arranca, /health responde, el protocolo de inicio initialize de MCP funciona, la autenticación por token de portador rechaza correctamente tokens faltantes/incorrectos y permite el correcto, y list_sites devuelve datos reales de un SITES_JSON de prueba.

1. Requisitos previos

npm install -g wrangler   # or just use npx wrangler as shown below
wrangler login            # opens a browser to authenticate with your Cloudflare account

Si aún no tienes una cuenta de Cloudflare, regístrate gratis en https://dash.cloudflare.com/sign-up — el plan gratuito (100 000 peticiones/día) es más que suficiente para esto.

2. Instalar dependencias

cd wp-mcp-gateway-cf
npm install

3. Configura tus sitios

A diferencia de la versión para Node, los Workers no tienen sistema de archivos, por lo que el registro de sitios vive en un secreto (SITES_JSON) en lugar de en un archivo. Misma forma que antes — una entrada por sitio:

{
  "town-green": {
    "label": "Town Green",
    "baseUrl": "https://town-green.org",
    "username": "mcp-agent",
    "appPassword": "xxxx xxxx xxxx xxxx xxxx xxxx",
    "host": "wpengine"
  },
  "cra": {
    "label": "CRA",
    "baseUrl": "https://cra.com",
    "username": "mcp-agent",
    "appPassword": "xxxx xxxx xxxx xxxx xxxx xxxx",
    "host": "gridpane"
  }
}

Construye ese JSON para todos tus sitios (un script de hoja de cálculo a JSON es fácil de preparar una vez que hayas generado las contraseñas de aplicación para cada sitio — pregunta si quieres uno), luego configúralo como un secreto:

npx wrangler secret put SITES_JSON
# paste the whole JSON blob when prompted, then press Ctrl+D

Contraseñas de aplicación: en wp-admin, Users → your user → Application Passwords. Misma recomendación que antes: usa un usuario de WP dedicado y con pocos privilegios por sitio, en lugar de tu cuenta de administrador personal, para que un token filtrado no pueda hacer más de lo que permite ese rol.

4. Establece tu token de autenticación del gateway

npx wrangler secret put GATEWAY_TOKEN
# paste a long random value, e.g. output of: openssl rand -hex 32

Sin esto configurado, el endpoint funciona sin autenticación — aceptable para una primera prueba local, nunca para la versión desplegada.

5. Prueba localmente

npx wrangler dev

Esto inicia un servidor de desarrollo local (por defecto http://localhost:8787). Para pruebas locales, pon tus secretos en un archivo .dev.vars en su lugar (nunca lo subas al repositorio):

GATEWAY_TOKEN=some-local-test-token
SITES_JSON={"town-green":{"label":"Town Green","baseUrl":"https://town-green.org","username":"mcp-agent","appPassword":"xxxx"}}

Comprueba que está vivo:

curl http://localhost:8787/health

6. Desplegar

npx wrangler deploy

Wrangler muestra tu URL en producción, algo así como:

https://wp-mcp-gateway.<your-subdomain>.workers.dev

Tu endpoint MCP es https://wp-mcp-gateway.<your-subdomain>.workers.dev/mcp.

7. Añádelo como conector en Claude

Añade un conector personalizado que apunte a esa URL /mcp, con la cabecera Authorization: Bearer <GATEWAY_TOKEN> (el mismo valor que configuraste en el paso 4).

A partir de entonces, "listar borradores en cra.com" solo necesita que Claude llame a list_sites (o que ya sepa el id) y luego a list_posts con site_id: "cra" — el mismo comportamiento que la versión para Node, solo que alojado en el edge.

Actualizar sitios más tarde

Añade un nuevo sitio o cambia las credenciales volviendo a ejecutar:

npx wrangler secret put SITES_JSON

No es necesario redesplegar — los secretos se actualizan independientemente del código del Worker.

Notas específicas de este despliegue

• Sin sistema de archivos, sin proceso de larga duración — todo el registro vive en el secreto SITES_JSON, analizado de nuevo en cada petición. Coste trivial incluso con ~80 sitios.

• Sin estado por diseño — cada petición MCP crea una instancia de servidor nueva (según la guía actual de Cloudflare); no hay ninguna sesión entre peticiones que puedas perder.

• Avisos del WAF en hosts gestionados — la misma advertencia que en la versión para Node: WP Engine en particular puede marcar el tráfico de un rango de IP desconocido que llame a la API REST. Si un sitio devuelve 403 solo cuando se accede a través de este gateway, es lo primero que debes comprobar con el soporte de WP Engine — vale la pena incluir los rangos de salida de Cloudflare en la lista blanca si es necesario.

• Alcance de las herramientas — esto solo habla con la API REST principal de WP (/wp/v2/...). No hay operaciones de WP-CLI, SSH ni a nivel de base de datos — los Workers no pueden hacer SSH de todos modos, así que necesitarías algo completamente distinto si lo necesitas más adelante.

Lista de verificación de seguridad antes de conectar Claude a la URL desplegada

• GATEWAY_TOKEN configurado mediante wrangler secret put, largo y aleatorio

• SITES_JSON usa un usuario de WP dedicado y con pocos privilegios por sitio

• .dev.vars (si usaste uno localmente) está en .gitignore y nunca se sube al repositorio

• Has probado con 2–3 sitios antes de ampliar el secreto a todos los ~80