Hay una tendencia que creo que merece más atención dentro del mundo WordPress: el WordPress MCP Adapter. No porque sea otra sigla bonita para vender IA, sino porque cambia una pregunta bastante práctica: ¿y si un agente de IA pudiera hablar con tu WordPress de forma estructurada, con permisos claros y sin depender de apaños raros?
Te cuento por qué me parece importante. Hasta ahora, cuando alguien decía “voy a conectar ChatGPT con mi web”, muchas veces hablaba de automatizaciones a medias: un webhook, una API mal documentada, un plugin que hace tres cosas y un panel lleno de tokens. Funciona, sí, pero suele ser frágil. MCP, el Model Context Protocol, apunta a otra cosa: que las herramientas de IA puedan descubrir qué puede hacer tu sistema y ejecutar acciones concretas con contexto.
En WordPress esto encaja especialmente bien porque la plataforma ya vive rodeada de contenido, pedidos, usuarios, formularios, reservas, productos y plugins. Si todo eso puede exponerse como capacidades controladas, el salto no es “poner un chatbot en la home”. El salto es usar agentes IA para trabajar dentro del CMS.
Qué es exactamente el WordPress MCP Adapter
El WordPress MCP Adapter es una pieza pensada para que aplicaciones de IA compatibles con MCP puedan descubrir y llamar funcionalidades de WordPress. Dicho de forma más simple: permite que herramientas como Claude Desktop, Cursor, VS Code u otros clientes compatibles entiendan qué acciones puede ejecutar tu instalación.
La base está en la Abilities API, introducida en WordPress 6.9, que permite registrar funcionalidades de manera estandarizada, tipada, descubrible y ejecutable. Eso suena técnico, pero para una pyme tiene una traducción muy directa: en vez de darle a una IA acceso genérico a “todo WordPress”, puedes exponer acciones concretas.
Por ejemplo: consultar pedidos de WooCommerce, preparar un borrador, revisar el estado de actualizaciones, listar productos sin stock o generar un informe de formularios recibidos. No todo a la vez, no sin control, no como si la IA fuera un administrador humano con barra libre.
Por qué esto importa si tienes una web de empresa
Yo no lo miraría como una novedad para desarrolladores curiosos, aunque ahora mismo lo sea bastante. Lo miraría como una señal de hacia dónde va WordPress: menos panel manual, más operaciones asistidas por agentes.
Imagina una tienda online pequeña. Hoy, para saber qué productos se venden peor, qué pedidos tienen incidencias o qué páginas necesitan actualización, normalmente saltas entre WooCommerce, Analytics, Search Console, el CRM y quizá una hoja de cálculo. Con un enfoque tipo MCP, un agente podría consultar varias capacidades expuestas por WordPress y devolverte una lectura accionable.
La diferencia con una automatización clásica es que el agente no solo “recibe un evento y dispara una acción”. Puede razonar sobre una tarea, pedir datos, comparar información y ejecutar pasos definidos. Eso abre escenarios muy interesantes, sobretodo si el negocio no tiene equipo técnico interno.
Casos prácticos que sí tienen sentido
Donde yo veo más potencial a corto plazo no es en dejar que la IA publique sola, sino en tareas con supervisión humana. Algunos ejemplos razonables:
- Auditoría de contenido: pedir al agente que encuentre páginas antiguas, entradas sin actualizar o productos con descripciones pobres.
- Gestión de WooCommerce: consultar pedidos, detectar productos sin stock, revisar cupones activos o preparar informes de ventas.
- Soporte interno: convertir preguntas del equipo en acciones sobre datos reales de WordPress.
- Mantenimiento web: revisar plugins, versiones, incidencias básicas y generar un resumen antes de tocar nada.
- Flujos editoriales: preparar borradores, sugerir enlaces internos o comprobar si una entrada encaja con una categoría.
La clave está en que el agente tenga herramientas concretas, no acceso universal. Si la capacidad registrada es “crear borrador”, perfecto. Si es “borrar cualquier contenido publicado”, yo lo pensaría dos veces antes de exponerla.
El riesgo: confundir conexión con control
Esta parte me parece fundamental. MCP no elimina los problemas de seguridad; los ordena mejor si lo implementas bien. Si lo implementas mal, puedes tener un problema más elegante, pero problema al fin y al cabo.
Cuando conectas una IA a WordPress, tienes que decidir qué puede ver, qué puede ejecutar y bajo qué usuario. También necesitas logs, límites y una forma clara de revocar accesos. No basta con decir “lo conecto porque es moderno”. Si una tienda online expone pedidos, datos de clientes o endpoints de administración, la seguridad deja de ser un detalle técnico.
Mi recomendación sería empezar en local o en staging, no en producción. Primero probar capacidades inocuas: leer información pública, listar contenido, preparar borradores. Después, si todo está controlado, avanzar hacia acciones más delicadas con revisión humana.
Cómo empezaría yo sin liarla
Si tienes una web WordPress y quieres explorar esta tendencia, no empezaría instalando todo en la web principal. Haría una copia de pruebas y seguiría este orden:
- Identificar qué tareas repetitivas consumen más tiempo cada semana.
- Separar tareas de lectura, tareas de escritura y tareas peligrosas.
- Probar el MCP Adapter con capacidades de bajo riesgo.
- Definir qué acciones deben requerir aprobación humana.
- Documentar permisos, usuarios y tokens desde el primer día.
Esto no es glamour de IA, lo sé. Pero es lo que marca la diferencia entre una automatización útil y un experimento que nadie se atreve a mantener.
Conclusión
El WordPress MCP Adapter no significa que mañana tu web vaya a gestionarse sola. Y sinceramente, tampoco creo que eso sea deseable. Lo interesante es otra cosa: que WordPress empieza a prepararse para un entorno donde los agentes IA no solo escriben texto, sino que interactúan con sistemas reales mediante capacidades definidas.
Para una pyme, esto puede ser una ventaja si se usa con cabeza: menos tareas manuales, mejores informes, más automatización y un CMS que empieza a comportarse como una plataforma operativa. Pero el orden importa: primero permisos, luego pruebas y solo después automatización.
La pregunta que yo me haría antes de probarlo es muy concreta: ¿qué tres tareas de tu WordPress dejarías que un agente IA preparase por ti, pero no ejecutase sin tu aprobación?