WordPress MCP vs Headless CMS MCP: ¿Cuál se adapta a los agentes de IA?

WordPress MCP ahora tiene una ruta oficial: la API de Abilities, que llegó en WordPress 6.9, más el MCP Adapter que convierte las habilidades en herramientas que un agente puede llamar. Bien. Los CMS headless llegaron a ese punto antes con servidores de primera parte propios, mientras que los sitios basados en git evitan gran parte del mismo problema al obligar a cada edición del agente a pasar por una solicitud de extracción antes de llegar a producción. Ninguna de estas pilas es segura por defecto. La verdadera diferencia es dónde vive la seguridad: en la caja o en el trabajo que haces alrededor de ella. Este artículo compara pilas en lugar de complemento contra complemento, y luego te da un cuadro de puntuación y una vista cautelosa sobre dónde pueden vivir los sitios dirigidos por agentes en 2027.

Lo que MCP cambia: tu sitio obtiene un agente que puede escribir

El MCP de solo lectura es una caja de búsqueda más educada. Un agente obtiene publicaciones, las resume y detecta brechas, y si el trabajo sale mal, el sitio no se daña. Nada se rompe.

El acceso de escritura es diferente. Una vez que un servidor expone las herramientas de crear, actualizar, publicar y eliminar, el agente se convierte en un usuario trabajador de tu sitio, con todos los derechos que lleva su token. Puede reescribir una página de precios a las 3 de la mañana. Puede publicar un borrador que nadie aprobó, y puede ser empujado hacia el error por el texto que lee en el camino. Más sobre eso en breve.

La elección del CMS por lo tanto deja de ser principalmente sobre editores y plantillas. Se convierte en una cuestión de permisos, y cuatro preguntas secundarias hacen la mayor parte del trabajo difícil.

1. ¿Qué tan finamente puedes limitar lo que el agente puede hacer?
2. ¿Puede permanecer en borrador o cada escritura se publica en vivo?
3. ¿Hay un registro de auditoría y puedes deshacer los cambios?
4. ¿Puede un humano ver el resultado antes de que el público lo haga?

Esto ya no es una preocupación de nicho. La AISI del Reino Unido contó herramientas MCP lanzadas públicamente aumentando de alrededor de 5.000 a 177.000 en un año, con descargas pasando de 80.000 a 14 millones. Son muchos servidores en los que confiar o rechazar. Si quieres una rutina para tomar esa decisión, escribí una en vetting Claude Code skills, plugins and MCP servers, y la imagen más amplia de ejecutar MCP en producción está en el post MCP servers production stack.

WordPress, la ruta oficial: la API de Abilities y el MCP Adapter

La API de Abilities llegó en WordPress 6.9. Proporciona al núcleo, temas y complementos una forma estándar de declarar lo que pueden hacer, con esquemas de entrada y devoluciones de llamada de permisos adjuntos. El MCP Adapter se sitúa por encima de esa capa. Se describe como el paquete oficial de WordPress para la integración de MCP, vive bajo la organización GitHub de WordPress y pertenece a la iniciativa AI Building Blocks for WordPress. Su trabajo es estrecho pero importante: exponer habilidades como herramientas, recursos e indicaciones de MCP.

Lo que documenta el README:

• Transportes HTTP y STDIO, más una McpTransportInterface para protocolos personalizados. Los clientes se conectan a través de WP-CLI sobre STDIO o apuntando un cliente HTTP a /wp-json/mcp/mcp-adapter-default-server.
• Una característica que llama permisos granulares: autenticación de transporte por servidor y verificaciones de permisos por habilidad.
• Las habilidades son privadas por defecto. Configurar meta.public (o meta.mcp.public) a true expone una.
• El servidor predeterminado ofrece tres meta-herramientas: mcp-adapter/discover-abilities, mcp-adapter/get-ability-info y mcp-adapter/execute-ability.
• Manejo de errores conectable y observabilidad a través de McpErrorHandlerInterface y McpObservabilityHandlerInterface.

Privado por defecto es el instinto correcto. Una habilidad que nadie marcó como pública no puede ser alcanzada por un agente, sin importar cuán ingenioso sea el prompt. Ahora observa qué falta en esa lista: sin rol de agente solo borrador, sin paso de aprobación integrado, sin registro de auditoría. Los hooks de observabilidad son un lugar donde construir uno. No son un registro de auditoría terminado.

El control de borradores vive dentro de las habilidades. Alguien tiene que escribirlas. Un plugin de terceros, MS WordPress Abilities, muestra bien la forma de ese trabajo. Registra 29 habilidades (26 personalizadas, más tres del core que optaron por visibilidad MCP) y ofrece una actualización staged de dos pasos, preview-post-update seguido de apply-post-update, mientras que patch-post-content no necesita staging. Diseño sensato. Sigue siendo la elección de ese autor, no la de WordPress. Según el mismo README, el core y el plugin de IA oficial solo envían un puñado de habilidades de serie.

También sigue asentándose. Un problema abierto el 18 de marzo de 2026 señaló que el README del adaptador aún hablaba de necesitar la API de Habilidades después de que se había fusionado en el core (issue 150). El 24 de junio de 2026 un colaborador comentó allí que las habilidades del core y del sitio nuevas pertenecen al plugin de IA y a la API de Habilidades, no al adaptador, y que muchos docs del adaptador aún enseñan el modelo más antiguo de registrar habilidades arbitrarias y establecer mcp.public. Luego, el 5 de febrero de 2026, un mantenedor de WordPress AI dijo que no conocía ningún directorio de plugins que implementaran la API de Habilidades o soporte MCP (discussion 204). La infraestructura es oficial. El catálogo de habilidades seguras y útiles sigue siendo delgado.

WordPress, la ruta del plugin: muchas opciones, un récord de seguridad delgado

La otra ruta de WordPress es un plugin que envía su propio servidor MCP. Los nombres que aparecen en páginas de comparación de proveedores incluyen Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server y AI Engine. Los estoy tratando como una categoría aquí. Sin clasificación. Tampoco estoy repitiendo sus afirmaciones de características como hechos. Una advertencia importa: las páginas de comparación populares son administradas por vendedores de plugins que se listan a sí mismos, así que léelas como marketing con una tabla adjunta.

Lo que ofrece la categoría es velocidad. Instala el plugin, pega un token en tu cliente de IA, y obtienes herramientas para posts, medios y a menudo usuarios y configuración. El costo es confianza. Estás dándole a un autor de terceros un endpoint que puede actuar como un usuario de WordPress, en un sitio PHP con un área de administrador completo detrás.

El único récord de seguridad público que cito aquí pertenece a un plugin, AI Engine:

• CVE-2025-11749. En versiones hasta 3.1.3, con la opción de URL sin autenticación habilitada, el token bearer de MCP se filtró a través de las rutas REST públicas del sitio. Los atacantes no autenticados podrían autenticarse en el endpoint de MCP y crear cuentas de administrador. Corregido en 3.1.4, y publicado en NVD el 5 de noviembre de 2025 (el análisis de SentinelOne, que coloca la fuga en el endpoint /mcp/v1/ y dice que no se ha confirmado código de exploit público verificado).
• CVE-2026-8719. Publicado el 17 de mayo de 2026, calificado como alto (CVSS 8.8). En la versión 3.4.9 la ruta del token bearer OAuth de MCP no verificaba capacidad de administrador, así que un usuario de nivel suscriptor con un token válido podría alcanzar herramientas MCP de nivel admin y convertirse en administrador (GitHub advisory).
• Una lista más larga. WPScan lista muchas más, incluyendo una toma de control de cuenta de herramientas de usuario MCP en multisitio (corregida en 3.6.1) y creación de cuenta de administrador vía CSRF (corregida en 3.6.6).

Sé justo sobre qué prueba esto. Es un plugin. Los plugins populares atraen escrutinio, lo cual es en parte por qué este tiene un récord, y un récord vacío en otros lados no es evidencia de seguridad. Aún así, el patrón importa. Ambos bugs titulares son fallos de autorización en la puerta MCP, exactamente donde un agente recibe su poder. Recuerda esa parte.

Servidores MCP de Headless CMS: Sanity, Strapi, Contentful y Payload

Las plataformas Headless construyeron sus servidores MCP alrededor del modelo de datos. No alrededor de un admin de PHP. Esa diferencia se ve en la documentación.

Sanity

Sanity ejecuta un servidor alojado en https://mcp.sanity.io sobre HTTP por streaming, con OAuth por defecto y autenticación por token como opción. Los agentes pueden ejecutar consultas GROQ, gestionar releases y parchear documentos con conocimiento de tu esquema. La configuración es npx sanity@latest mcp configure. El paquete @sanity/mcp-server local más antiguo está deprecado. Esa es la ruta actual.

Los docs describen escritura draft-first: create_documents crea borradores a menos que pases un releaseId, patch_documents guarda en la versión de borrador o release, y el contenido publicado nunca se modifica directamente. La publicación es una herramienta separada. Los parches a cada documento se aplican como una sola transacción. Un token personal comparte tu rol y te vincula a cambios en el historial de revisiones, mientras que un token establecido en el encabezado Authorization actúa dentro de su propio rol y alcance. Hay dos advertencias. El servidor también expone desarrollo y administración de proyectos (despliegue de esquema, datasets, orígenes CORS), así que limita el token cuidadosamente. Y create_release no programa nada, lo cual debe suceder en Studio o la API de HTTP Actions.

Strapi

El servidor MCP de Strapi está integrado y se ejecuta dentro de tu propia instancia. Apareció por primera vez en v5.47.0 y alcanzó disponibilidad general en v5.49.0 (blog de Strapi, 3 de septiembre de 2026). Por defecto está desactivado: server.mcp.enabled es false. Se autentica con tokens de API de administrador y expone herramientas find, create, update, publish y unpublish por tipo de contenido. Un token nunca puede exceder los permisos de su propietario, y desactivar al propietario lo revoca. No crea tipos de contenido ni carga medios; esos aún van a través de la API REST (Strapi).

Contentful y Payload

Contentful publica un servidor MCP oficial de código abierto (licencia MIT, paquete npm @contentful/mcp-server) que permite a los agentes gestionar entradas y recursos, actualizar tipos de contenido y automatizar tareas como etiquetado y migraciones. Necesita un token de acceso de gestión y un ID de espacio (Contentful). Existe un servidor comunitario separado que apunta al oficial. Payload añade MCP a través de un complemento oficial en lugar de un servidor independiente. Hasta aquí llego con Payload en este contexto.

Si estás comparando Sanity contra WordPress en general, Sanity vs WordPress for enterprise cubre el lado que no es MCP. Empieza por ahí para esa parte de la decisión.

Jamstack basado en Git: la solicitud de extracción es la red de seguridad

El tercer patrón no tiene ningún servidor CMS. El contenido vive en el repositorio como Markdown, MDX o JSON tipado, y el sitio es Astro o Next.js. Un agente de codificación edita archivos. Abre una solicitud de extracción, el host construye un despliegue de vista previa, y una persona lee el diff antes de fusionar. Vercel y Netlify hacen despliegue basado en Git y despliegues de vista previa, que es todo lo que este patrón necesita de un host.

Ese flujo de solicitud de extracción no es exótico. Next.js documenta cómo soporta agentes de codificación de IA, y un tutorial de Microsoft Azure Static Web Apps muestra el cableado estándar: un flujo de trabajo de GitHub Actions que se activa cuando se abre, sincroniza, reabre y cierra una solicitud de extracción, con un trabajo separado para desmontar la vista previa. Es maquinaria de entrega ordinaria. Esa es parte del atractivo.

Por qué le conviene a los agentes es simple. Cada cambio es un diff revisable. Nada llega a producción hasta que una persona fusiona. La reversión es un git revert. El sitio público es salida estática, así que no hay login de administrador para que un token de agente robado alcance.

Los costos son reales, sin embargo. Los editores no técnicos encuentran fricción, porque git no es su herramienta. Nada aquí es un servidor MCP documentado con un historial de seguridad; el agente es un agente de codificación con acceso al repositorio, así que tu exposición es el alcance de su token de git y lo que su shell pueda tocar. La higiene de la cadena de suministro sigue siendo aplicable. Lo cubrí en Next.js, Astro and Nuxt security in 2026.

Riesgos de MCP en cualquier stack y los controles que los contienen

La NSA publicó una Hoja de Información de Ciberseguridad sobre seguridad de MCP en junio de 2026, y Microsoft escribió el estado de la seguridad de MCP en 2026. Descarta el vocabulario y cuatro riesgos siguen apareciendo.

• Permisos heredados. El agente puede hacer lo que puedan hacer las credenciales de su servidor MCP. Un token de administrador significa un agente administrador.
• Envenenamiento de herramientas. Las descripciones de herramientas son leídas por el modelo, así que un servidor malicioso o comprometido puede esconder instrucciones en ellas. Por eso los servidores de terceros merecen una revisión antes de instalar.
• Inyección de indicación. El contenido que el agente lee (un comentario, una página rastreada, un ticket de soporte pegado en un borrador) puede llevar instrucciones. El agente puede obedecerlas con su propio acceso de escritura.
• Tokens sobreprivilegiados. La conveniencia empuja a la gente a entregar un token amplio. No lo hagas.

Los controles son mundanos. Funcionan. Dale al agente tokens de menos privilegios, prefiere alcances de solo lectura o solo borrador, y pon aprobación humana frente a publish y delete. Mantén registros de auditoría que realmente leerás. Rota tokens cuando alguien se va. Nada de esto es específico del stack, y ese es el punto. El stack solo decide cuánto del trabajo ya está hecho para ti.

La tarjeta de evaluación de disponibilidad del agente

Aquí está la comparación en un solo lugar. Las calificaciones provienen de características documentadas y del registro público, con las fuentes nombradas arriba. Nadie ejecutó estos stacks a través de una suite de pruebas para esta tabla. Trátala como una comparación documentada, no como un resultado de laboratorio.

Fuerte significa que la documentación lo cubre por defecto. Parcial significa documentado pero incompleto, o respaldado por solo un registro breve. Depende de la configuración significa que el stack no lo decide. Tu configuración lo hace. Débil significa problemas documentados.

Por qué cada calificación, brevemente.

WordPress + Adapter. Los permisos son fuertes porque cada capacidad tiene su propia verificación y las capacidades son privadas hasta marcarse como públicas. El control de borrador depende de las capacidades que instales, como mostró el ejemplo de actualización por etapas. Auditoría es parcial: existen interfaces de observabilidad, pero no hay un registro de auditoría nativo. Autenticación es parcial, con autenticación de transporte por servidor documentada a un nivel alto. El registro es parcial porque el paquete es joven y su documentación está visiblemente en migración.

Plugins de WordPress. Nada es uniforme en una categoría, así que la mayoría de celdas dependen del plugin. El registro es débil donde está documentado: las entradas de AI Engine arriba, y solo esas. Esa distinción importa.

Sanity. Los tokens con alcance de rol, escrituras por defecto en borrador, releases e historial de revisiones obtienen las calificaciones fuertes. Vista previa es parcial porque un release es un concepto de staging, pero el servidor MCP no puede programar ni publicar releases. El registro es parcial en el sentido de ser breve. No es malo.

Strapi. Las herramientas por tipo de contenido y los tokens vinculados al propietario son fuertes en permisos y autenticación. Publicar y despublicar son herramientas separadas, y el servidor se mantiene desactivado hasta que lo enciendas. Auditoría y vista previa dependen de cómo ejecutes tu instancia. El auto-alojamiento también significa que el parching es tu responsabilidad.

Contentful. El servidor oficial necesita un token de gestión e ID de espacio, lo que se lee como acceso amplio, así que calfico permisos y autenticación como parcial. El manejo de borradores, auditoría y vista previa dependen de cómo configures espacios y roles. El trabajo importante está en esa configuración.

Payload. Existe un plugin oficial. Más allá de eso, no tengo documentación primaria para calificar, así que cada celda se lee como depende de la configuración. Ese es un vacío en lo que puedo verificar. No es un veredicto.

Jamstack basado en Git. Fuerte en cuatro columnas porque el patrón mismo las proporciona: permisos de repositorio a nivel de rama, un pull request como puerta de publicación, historial de Git y reversiones, deploys de vista previa. La autenticación depende del agente de código y su token de Git. El registro es parcial porque no hay una superficie de admin de CMS para atacar. Las herramientas del agente siguen llevando los mismos riesgos de MCP que todo lo demás.

Cómo elegir hoy, según la situación

Tienes un WordPress existente

Mantente donde estás y sé estricto. Usa el adaptador oficial, marca solo las capacidades que necesitas como públicas, y escribe o elige capacidades que organicen cambios antes de aplicarlos. Un complemento de terceros amplio con un token capaz de admin es la configuración más riesgosa en toda esta comparación. Si quieres liberar WordPress desde el front end primero, el desarrollo de WordPress headless es un camino intermedio.

Estás iniciando una nueva construcción

Si los agentes te ayudarán a ejecutarla, comienza con headless o basado en Git. Sanity o Strapi te dan borradores y tokens scoped de serie. Astro o Next.js en un repositorio te dan diffs y vistas previas. Ese es un buen estándar para trabajo nuevo.

Tu equipo de contenido es grande o no técnico

Un equipo de editores que viven en una interfaz visual no disfrutará los pull requests. Headless con un estudio de edición adecuado les conviene más, siempre que el agente esté confinado a borradores. El editor de WordPress sigue siendo genuinamente bueno aquí. Ese es un punto a su favor.

Tienes necesidades de cumplimiento

Pregunta dónde vive el historial de auditoría y quién es su propietario. El historial de Git es una respuesta fuerte. El historial de revisiones de Sanity es otra. Para WordPress, tendrás que construir el logging tú mismo. Las opciones auto-hospedadas (Strapi, WordPress) mantienen datos en tu infraestructura pero ponen los parches sobre ti, mientras que un servidor hospedado traslada esa carga al proveedor.

Hacia 2027: por qué Jamstack puede ser el mejor hogar para sitios dirigidos por IA

Esta sección es opinión, no un hallazgo, y la sostengo con soltura.

Por qué Jamstack puede adelantarse. El contenido está estructurado y tipado. Cada cambio del agente puede ser un diff que un humano revise. Los deploys de vista previa muestran el resultado antes de que se publique. La reversión es un revert de Git. El sitio público no tiene una superficie de admin para que un token de agente robado alcance. Los agentes son buenos editando archivos y malos siendo de confianza, y esta configuración está construida para exactamente esa combinación.

Por qué WordPress puede no perder. Tiene la base de instalación más grande y un pool de talento más amplio. La API de Abilities ahora está en core, con un adaptador oficial a su lado. Los proveedores de complementos iteran rápido. La iteración rápida arregla mucho, aunque haya creado los CVEs anteriores.

Lo que WordPress necesitaría. MCP en core, con capacidades mapeadas a abilities por defecto. Roles de agente solo-borrador. Un registro de auditoría nativo. Un mejor historial de seguridad para complementos MCP. Esa es una lista corta, y nada de eso es imposible.

Si esa visión te tiene pesando una mudanza, la guía para dejar WordPress es por dónde empezar.

Línea práctica: para un sitio nuevo que los agentes ayudarán a ejecutar, comienza con Jamstack o headless. Para un WordPress existente, usa el adaptador oficial con capacidades de menor privilegio en lugar de un complemento de terceros amplio. Sé aburrido aquí.

FAQ

¿Puedo ejecutar WordPress MCP en modo solo lectura?

Sí, en principio. Las capacidades son privadas por defecto, así que expone solo las capacidades que leen datos y deja cualquier cosa que escriba sin registrar o sin marcar. El adaptador no tiene un único interruptor de solo lectura. La disciplina se sienta en qué capacidades registras.

¿Cuál AI clientes pueden conectar?

Para WordPress, cualquiera que hable MCP sobre HTTP o STDIO (vía WP-CLI). La documentación de Sanity enumera Claude Code, Cursor, VS Code, Lovable, Replit y v0 como clientes compatibles, y las sesiones OAuth allí típicamente expiran después de 7 días. La elección del cliente no es la parte difícil.

¿Es un servidor MCP hospedado más seguro que uno auto-hospedado?

Cambia un riesgo por otro. Un servidor hospedado como el de Sanity mueve los parches al proveedor, pero dependerás de su scoping e higiene de tu token. Un servidor dentro de tu instancia, como el de Strapi, mantiene todo en tu infraestructura. Las actualizaciones son tu responsabilidad.

¿Debería construir mi propio servidor MCP en su lugar?

Solo si necesitas un conjunto estrecho de herramientas que las oficiales no ofrecen. Un servidor pequeño y construido para un propósito específico con tres herramientas es más fácil de razonar que uno amplio. Hay un tutorial sobre cómo construir un servidor MCP con Supabase y TypeScript. Mantén la superficie pequeña.

La advertencia más importante es la obvia: un agente hereda todo lo que su token puede hacer, y el único registro de seguridad MCP público en esta comparación es la lista de CVE de un plugin de WordPress, lo cual es razón suficiente para limitar el alcance de los tokens antes de elegir una pila. Las calificaciones anteriores provienen de la documentación y avisos públicos, no de pruebas. Trata la elección de la pila como secundaria al modelo de permisos.