El cambio agéntico: cómo los agentes de IA están cambiando la elección de plataforma, el diseño y la seguridad en WordPress

#Cómo eligen los agentes de IA una plataforma CMS

Elegir plataforma era antes una decisión humana, en manos de propietarios, agencias y CTO. Andy Peatling, que pasó 17 años en Automattic y ahora desarrolla Miles, un agente de diseño con IA para WordPress, sostiene que ese camino se está cerrando. En Ideas for WordPress in an agentic world (14 de septiembre de 2026) escribe que un agente elige plataforma a partir de sus datos de entrenamiento o de una búsqueda web, y que puede montar un sitio sencillo en unos 30 segundos. Su conclusión es tajante: “Si WordPress no está siendo elegido, el proyecto no va a crecer” (traducción propia).

Hace tres propuestas concretas:

• Dos recorridos de agente comprometidos. WordPress debería definir y comprometerse públicamente con dos recorridos completos que un agente pueda ejecutar de principio a fin, por ejemplo un sitio construido íntegramente por un agente de programación, desde la creación hasta la publicación y el alojamiento. Menciona Abilities, MCP, Agent Skills, los metadatos de temas y los metadatos de plugins como la infraestructura que esos recorridos deberían conectar, con permisos, aprobaciones, puntos de restauración y registros de auditoría definidos.
• Benchmarks públicos. Medir el éxito de los agentes en esos recorridos, registrar cuándo y por qué los agentes incluyen o descartan WordPress al elegir plataforma, y medir las habilidades nativas para agentes con herramientas como WP-bench.
• Un único recurso para agentes en WordPress.org. Explicar dónde WordPress es la opción adecuada y dónde no, marcar con claridad las API actuales y relegar las antiguas, y estructurar la documentación para que los agentes puedan procesarla.

La misma pregunta recorrió un episodio de WP Minute con Alex Panagis, Brian Coords, Andy Peatling y Mike McAlister, How do we get agents to use WordPress. Las notas del programa recogen que los agentes a los que se pide construir un sitio web no siempre recomiendan WordPress, que WordPress necesita opiniones más firmes sobre cómo deberían usarlo los agentes y que la Abilities API podría convertirse en la base del WordPress agéntico.

#Qué hace la beta del servidor MCP de Elementor en WordPress

Elementor abrió su beta MCP el 15 de septiembre de 2026. Expone capacidades de construcción de sitios a través de habilidades de WordPress, de modo que un cliente MCP puede construir y editar páginas como estructuras nativas de Elementor, en lugar de devolver HTML sin procesar que alguien tenga que pegar en una plantilla. Elementor menciona como clientes Claude Code, Claude Desktop, Codex y Cursor, además de cualquier otra herramienta que hable MCP.

El anuncio enumera nueve capacidades:

• construir páginas y diseños atómicos en un solo paso,
• editar o rediseñar páginas y diseños atómicos existentes,
• crear, aplicar y reordenar clases y variables, definir estados hover y ajustar los puntos de ruptura responsive,
• crear y gestionar partes del tema como cabeceras, pies de página, archivos y popups, con condiciones de visualización,
• colocar, rellenar o crear componentes,
• conectar datos dinámicos como campos de las entradas, campos personalizados y taxonomías,
• crear widgets personalizados y experiencias de administración,
• actualizar contenido en bloque, depurar errores y corregir carencias de SEO,
• acceder a todas las habilidades registradas con la WordPress Abilities API, incluidas las de plugins como WooCommerce, Yoast, WPForms, Jetpack y ACF.

Las tres últimas requieren Angie, un plugin independiente de Elementor. La beta tiene límites claros. El acceso está restringido a los administradores del sitio, la conexión es por sitio y todo lo que genera el MCP se guarda como borrador, sin publicarse. La configuración exige el canal de beta testers y el Atomic Editor. Elementor genera una contraseña de aplicación y la incluye en un prompt de configuración para la herramienta de IA, con una opción de configuración manual. Los elementos Pro siguen necesitando un plan Pro, y el editor estándar no cambia para quien no se conecte.

#Cómo valida Block Runner de Human Made los bloques de Gutenberg

Block Runner es una CLI y biblioteca JavaScript de código abierto de Human Made, con licencia GPL-2.0-or-later. Su README la describe como una herramienta que “convierte HTML compatible en bloques nativos de Gutenberg y comprueba el marcado generado con los paquetes de Gutenberg que usa el editor de WordPress” (traducción propia). El paquete se publicó por primera vez en npm el 24 de junio de 2026; la versión 0.9.10 apareció el 4 de octubre de 2026.

El problema que aborda lo conoce cualquiera que haya pegado marcado generado en el editor: el marcado que el editor no reconoce acaba como un bloque de HTML personalizado o como un bloque que pide recuperación. Block Runner ofrece cuatro vías, documentadas en el README:

• convert transforma HTML en marcado de bloques con reglas integradas,
• assemble construye el contenido de una página a partir de un árbol de bloques que ha planificado un agente,
• author genera el código fuente de un bloque registrado reutilizable, como un bloque de aviso, para un plugin,
• validate y fix comprueban o canonicalizan marcado de bloques existente.

El paquete no hace llamadas a ningún modelo de IA. Un agente externo puede interpretar un diseño y entregar a Block Runner un plan estructurado, y después un código determinista ensambla y valida el resultado. Una skill incluida para agentes de programación se instala con npx --no-install block-runner skill --install, que la escribe en .agents/skills/block-runner y .claude/skills/block-runner. La conversión básica necesita Node.js (20.19+, 22.13+ o 24+) y no requiere ningún sitio WordPress, Docker ni agente.

El README es explícito sobre los límites. Las estructuras no compatibles pueden quedarse como HTML personalizado con avisos, y --strict hace fallar la ejecución ante bloques de respaldo y medios sin resolver. En sus propias palabras: “Un marcado válido no demuestra fidelidad visual ni compatibilidad con todos los sitios” (traducción propia). El resultado sigue teniendo que comprobarse en la instalación de WordPress de destino. Para entender cómo encajan bloques, patrones y plantillas, consulta nuestra guía de bloques de Gutenberg y full site editing.

#Qué fallos corrigió WordPress 7.1.1 y quién los reportó

WordPress 7.1.1 se publicó el 17 de septiembre de 2026 como versión de mantenimiento y seguridad: 17 correcciones de errores del núcleo, 19 del editor de bloques y 11 correcciones de seguridad. El anuncio pide actualizar de inmediato e indica que las correcciones de seguridad se están portando, cuando es necesario, a todas las ramas que siguen recibiendo parches de seguridad. La lista completa con los créditos, tal como se publicó:

Anthropic figura en dos de los once problemas, y pwn.ai comparte un crédito con Paulos Yibelo. Los dos problemas de Anthropic requieren una cuenta autenticada, uno de ellos solo de nivel Contributor. Esto importa en las configuraciones con agentes: un agente conectado a un sitio actúa como un usuario de WordPress, así que el rol que le asignes decide a qué clases de fallos podría llegar en una instalación sin parchear. Nuestra guía de hardening de seguridad en WordPress trata los roles, las actualizaciones y la monitorización.

#Evento de WordPress sobre IA en Faro, octubre de 2026

La comunidad portuguesa de WordPress (Comunidade Portuguesa de WordPress) organiza WordPress Day for AI Faro 2026 el 24 de octubre de 2026 en el hotel AP Eva Senses de Faro. Según la web del evento, se celebra de 09:00 a 18:00 con 100 plazas, y las charlas son en portugués e inglés.

Hay dos tracks. El de desarrollo cubre el desarrollo asistido por IA, las herramientas de programación, las API, la automatización, las integraciones con LLM, MCP y los flujos de trabajo de desarrollo en WordPress. El de negocio está pensado para propietarios, agencias y profesionales, y trata la productividad, la automatización de flujos de trabajo y la experiencia del cliente.

#Qué es la Abilities API de WordPress y cómo se registra una habilidad

La Abilities API es la capa sobre la que construye Elementor. Su parte de servidor llegó con WordPress 6.9. Una habilidad es una unidad de funcionalidad con nombre, en la forma namespace/ability-name, que se registra con wp_register_ability() dentro de un callback en el hook wp_abilities_api_init. Cada habilidad pertenece exactamente a una categoría, registrada con wp_register_ability_category() en wp_abilities_api_categories_init.

Los argumentos obligatorios son label, description, category, output_schema, execute_callback y permission_callback. input_schema es opcional y solo hace falta cuando la habilidad recibe datos de entrada. Ambos esquemas son JSON Schema, y una entrada que no supera la validación nunca llega al callback de permisos. El array meta lleva indicaciones de comportamiento en annotations: readonly, destructive e idempotent.

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/get-site-title', array(
		'label'               => __( 'Get site title', 'my-plugin' ),
		'description'         => __( 'Returns the title of this site.', 'my-plugin' ),
		'category'            => 'site',
		'output_schema'       => array( 'type' => 'string' ),
		'execute_callback'    => fn() => get_bloginfo( 'name' ),
		'permission_callback' => fn() => current_user_can( 'read' ),
		'meta'                => array(
			'annotations'  => array( 'readonly' => true ),
			'show_in_rest' => true,
		),
	) );
} );

Conviene conocer dos valores por defecto. Las habilidades no se exponen por REST salvo que show_in_rest valga true, y los endpoints REST bajo /wp-json/wp-abilities/v1 exigen un usuario autenticado y respetan el callback de permisos de cada habilidad. El propio núcleo registra tres habilidades en 6.9: core/get-site-info, core/get-user-info y core/get-environment-info. El repositorio independiente de GitHub se archivó tras la integración en el núcleo. Para ver ejemplos prácticos de habilidades en flujos editoriales, consulta flujos de trabajo con IA en WordPress con la Abilities API.

#Cómo expone el MCP Adapter de WordPress las habilidades a los clientes MCP

El MCP Adapter es el paquete oficial de WordPress que convierte las habilidades en herramientas, recursos y prompts MCP. La versión 0.7.0, publicada el 2 de octubre de 2026, lo convierte en un plugin canónico. Los plugins deberían declarar Requires Plugins: mcp-adapter en su cabecera en lugar de incluir una copia; las copias incluidas siguen funcionando, pero registran un aviso de obsolescencia.

Actualización, 28 de octubre de 2026. La versión actual es la 0.7.1, publicada el 16 de octubre de 2026. Añade una guía de configuración paso a paso para propietarios de sitios: conectar un cliente de IA, crear una contraseña de aplicación, probar la conexión y resolver problemas habituales. Cuando un cliente pide una habilidad que no existe, el adaptador sugiere habilidades disponibles parecidas o remite al cliente al descubrimiento.

Las habilidades son privadas por defecto. Una habilidad llega a MCP solo cuando meta.public (o meta.mcp.public) vale true. El servidor por defecto, en /wp-json/mcp/mcp-adapter-default-server, expone tres meta-herramientas en lugar de una herramienta por habilidad: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info y mcp-adapter-execute-ability. El agente lista lo disponible, obtiene el esquema que necesita y después ejecuta. Así la respuesta de tools/list se queda en tres esquemas, por muchos plugins que registren habilidades. Un servidor personalizado creado en el hook mcp_adapter_init hace lo contrario y lista cada habilidad elegida como herramienta propia.

Hay dos formas de conectar un cliente:

• STDIO mediante WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin. El flag --user decide como qué usuario de WordPress se ejecutan las comprobaciones de permisos; sin él, la sesión no está autenticada.
• HTTP mediante el proxy @automattic/mcp-wordpress-remote, que se autentica con una contraseña de aplicación.

La seguridad funciona en dos capas. Un callback de permisos del transporte protege todo el servidor y por defecto es is_user_logged_in(), y cada habilidad sigue ejecutando su propio permission_callback. El adaptador admite las revisiones del protocolo MCP 2025-11-25 y 2026-07-28; los clientes más antiguos se atienden con el esquema 2025-11-25.

#Qué exige la especificación MCP a las herramientas y a los hosts

La especificación del Model Context Protocol define mensajes JSON-RPC 2.0 entre hosts (las aplicaciones LLM), clientes (conectores dentro del host) y servidores (servicios que aportan contexto y capacidades). Los servidores pueden ofrecer recursos, prompts y herramientas. La revisión actual, 2026-07-28, define dos transportes estándar: stdio, para un subproceso lanzado por el cliente, y Streamable HTTP, en el que cada mensaje es un POST a un único endpoint.

El capítulo de herramientas fija las reglas que importan cuando un agente escribe en WordPress. Siempre debería haber una persona en el circuito capaz de denegar invocaciones de herramientas. Los servidores deben validar todas las entradas de las herramientas, aplicar controles de acceso, limitar la frecuencia de las invocaciones y sanear las salidas. Los clientes deberían pedir confirmación en las operaciones sensibles, mostrar las entradas de la herramienta antes de llamarla, fijar tiempos de espera y registrar el uso de herramientas. Las anotaciones de las herramientas deben tratarse como no fiables salvo que procedan de un servidor de confianza.

Las piezas de WordPress encajan con estas reglas. La validación con JSON Schema de la Abilities API cubre la comprobación de entradas, permission_callback cubre el control de acceso, las anotaciones readonly y destructive indican al cliente qué llamadas necesitan confirmación, y el comportamiento de Elementor de guardar solo borradores mantiene a una persona entre el agente y la página publicada. El adaptador no incluye limitador de frecuencia (su guía de observabilidad solo enumera un código de error ability_rate_limit que una habilidad puede devolver), así que la limitación de frecuencia queda en manos de la capa de alojamiento o de la propia habilidad.

#Cómo funcionan las server cards de MCP para el descubrimiento

Los agentes también necesitan encontrar un servidor antes de conectarse. SEP-2127, que alcanzó el estado Final como extensión, define las MCP Server Cards: documentos estáticos de metadatos que describen la identidad de un servidor remoto, sus endpoints de transporte y las versiones del protocolo que admite. Una card puede estar en cualquier URI no reservada, y streamable-http-url/server-card queda reservada como ubicación recomendada. Para el descubrimiento a nivel de dominio, un AI Catalog publicado en /.well-known/ai-catalog.json puede enlazar las cards o incrustarlas.

Las cards dejan fuera a propósito las herramientas, los recursos y los prompts. La SEP explica que lo que expone un servidor puede variar según el usuario, la sesión y la configuración, por lo que los clientes deben usar la llamada en vivo a tools/list. Las cards no deben contener credenciales ni datos específicos de un usuario, y son opcionales: los servidores sin card siguen funcionando. En WordPress, la URL del endpoint del adaptador es la base natural para una card. Nuestra guía del servidor MCP en vivo de WPPoland muestra en la práctica un servidor público de solo lectura.

#Cómo construir sitios WordPress para agentes de IA y GEO

wppoland.com funciona con Astro 7 sobre Cloudflare Pages, con datos Schema.org generados desde el frontmatter en cada página. Nuestra regla de trabajo es que una página debe ser tan fácil de leer para una máquina como para una persona. Para los sitios WordPress, la ruta documentada es corta: registra habilidades con esquemas y anotaciones honestos, publica mediante el MCP Adapter solo las que quieras hacer públicas, da al agente un usuario de WordPress con el rol más restringido que cumpla la tarea y mantén los cambios de contenido como borradores hasta que una persona los apruebe. Los mismos datos estructurados sirven también para la Generative Engine Optimization (GEO). Cuándo basta el Agent y MCP write alojados en WordPress.com frente a un adaptador self-hosted lo cubrimos en WordPress.com Agent y MCP write.

Si quieres ayuda con ello, consulta nuestro servicio de desarrollo de servidores MCP o solicita una auditoría.