La Abilities API de WordPress registra cada función de un plugin o del núcleo como una pieza con nombre, esquema y un permiso que decide quién puede ejecutarla. Desde la versión 6.9, esa pieza deja de ser un endpoint oculto en el código y pasa a ser algo que un agente de IA puede descubrir, leer y disparar sin que un desarrollador escriba una integración a medida. Para un equipo que gestiona el blog, la tienda o el CRM desde WordPress, esto cambia qué tareas puede delegar en un asistente y qué controles hay que revisar antes.
La Abilities API de WordPress, disponible desde la versión 6.9 (diciembre de 2025) y ampliada en la 7.0 y la 7.1, registra las funciones del sitio con nombre, esquema y permiso propio para que un agente de IA —vía el adaptador MCP— pueda descubrirlas y ejecutarlas sin acceso directo a la base de datos ni credenciales de administrador.
Así cambia la Abilities API tu WordPress
Cada ability se registra con un nombre en formato «espacio/acción» —como core/get-site-info—, un esquema en JSON Schema, una función que ejecuta el trabajo y un permission_callback que decide quién puede invocarla. WordPress 6.9, de diciembre de 2025, la incorporó como API nativa del núcleo con tres abilities de serie: datos del sitio, perfil del usuario y entorno de ejecución.
Una ability es una función de WordPress registrada con nombre, esquema de entrada y salida, y un permiso propio, de forma que un humano o un agente de IA puede descubrirla y ejecutarla sin conocer el código que hay detrás.
Antes, cada plugin exponía sus funciones con su propio criterio y un agente externo no sabía qué podía hacer sin una integración a mano. Ahora son interrogables: se listan por PHP, JavaScript o la REST API del sitio, con el mismo esquema sea quien sea el que pregunte. Un plugin de reservas o el catálogo de una tienda pueden anunciar sus abilities con esa forma, y cualquier cliente —humano o IA— las lee igual.
Permisos y seguridad de cada ability
No todas las abilities deberían estar al alcance de cualquier agente. El permiso se fija por capacidad de WordPress —read, edit_posts, manage_options— y el método HTTP lo asigna la propia API según la acción: lectura, escritura o borrado.
| Acción del agente | Método HTTP | Capacidad mínima | Riesgo |
|---|---|---|---|
| Consultar entradas o pedidos | GET | read | Bajo |
| Crear un borrador | POST | edit_posts | Medio |
| Publicar una entrada | POST | publish_posts | Medio-alto |
| Modificar un pedido o el stock | POST | manage_woocommerce | Alto |
| Eliminar contenido | DELETE | delete_posts | Alto |
| Cambiar ajustes del sitio | POST | manage_options | Crítico |
El permission_callback decide quién ejecuta qué
Cada ability lleva su propio permission_callback, una función que WordPress ejecuta antes del execute_callback y que puede negar la llamada aunque el agente esté autenticado. El adaptador MCP recomienda un usuario dedicado con un rol limitado para los agentes, en vez de una cuenta de administrador, autenticado con una application password o con OAuth 2.1 en WordPress.com. Un fallo habitual es dejar __return_true en una ability que borra o publica contenido: eso abre esa acción a cualquiera que tenga la clave.
Capacidades a evitar en una ability destructiva
Las abilities que borran o publican sin revisión deberían exigir siempre una capacidad específica —delete_posts, manage_woocommerce— y nunca la genérica read, pensada solo para consultas. El adaptador MCP recomienda registrar estas acciones como de solo lectura en los endpoints públicos y reservar las destructivas para transportes locales, como STDIO vía WP-CLI, donde el acceso ya está acotado a quien tiene el servidor. Es el mismo criterio que con cualquier acceso con privilegios: no se le da el usuario administrador a una agencia externa para una tarea puntual.
El adaptador MCP conecta WordPress con Claude y Cursor
El Model Context Protocol (MCP) es el estándar que Claude Desktop, Claude Code, Cursor o VS Code usan para hablar con herramientas externas. El adaptador MCP de WordPress traduce cada ability a ese lenguaje: la expone como herramienta si hace algo, o como recurso si solo da datos de lectura. Por defecto crea tres piezas de entrada:
- Una herramienta que descubre qué abilities existen en el sitio.
- Otra que explica el esquema y el permiso de una ability concreta.
- Una tercera que la ejecuta de verdad, con los parámetros del agente.
Así el asistente no necesita conocer de antemano el catálogo completo: lo pregunta en el momento. La conexión va por dos vías: en local, por STDIO vía WP-CLI, sin exponer nada a internet; en producción, por HTTP con un proxy remoto. Un agente conectado así podría consultar el estado de un pedido o redactar un borrador sin abrir el panel de WordPress.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Abilities del lado del cliente desde WordPress 7.0
WordPress 7.0 añadió la contraparte en JavaScript: abilities que viven en el navegador, sin pasar por el servidor, para acciones como navegar por el editor o insertar un bloque, según el anuncio oficial de WordPress 7.0. Se dividen en dos paquetes: uno gestiona solo el estado de las abilities, y otro las conecta con las ya registradas en el servidor vía la ruta /wp-abilities/v1/. Cada ability cliente lleva su esquema, su permissionCallback y una anotación —lectura, destructiva o idempotente— que decide si WordPress la trata como GET, POST o DELETE.
Esto importa para quien se plantea separar el editor del resto de la web: la misma lógica de abilities funciona fuera de WordPress, en un proyecto propio, lo que reduce el salto cuando una empresa decide pasar de WordPress tradicional a una arquitectura headless: el contrato de cada ability se mantiene igual aunque cambie dónde vive el frontend.
Sectores de Barcelona que ya pueden aprovecharla
Barcelona concentra ecommerce y despachos profesionales que ya gestionan su web desde WordPress o WooCommerce, y cada sector le da un uso distinto a estas abilities: no es la misma prioridad consultar stock que gestionar expedientes.
Ecommerce: catálogo y pedidos vía agente
Una tienda sobre WooCommerce puede registrar abilities para consultar stock, actualizar el precio de una referencia o revisar el estado de un pedido, y un agente las ejecuta en lenguaje natural en vez de que alguien entre al backend a buscarlo. Esto no sustituye la gestión diaria del equipo, pero sí el rato que se pierde contestando si ya se ha enviado un pedido mientras se intenta terminar otra tarea. El riesgo es el mismo que con cualquier integración: si la ability de actualizar stock no exige manage_woocommerce, una credencial filtrada podría tocar precios sin que nadie lo note.
Despachos e industria: datos que no deberían salir solos
Un despacho profesional o una empresa industrial con ficha de producto y formulario de contacto tienen más que perder si una ability de lectura devuelve, sin querer, datos de un cliente o un expediente: ahí el permission_callback separa un asistente útil de una filtración. Una inmobiliaria con cientos de fichas de propiedad, en cambio, es un caso donde las abilities de solo lectura —buscar por zona, filtrar por precio— dan más valor que riesgo, porque no tocan nada que no estuviera ya publicado. El criterio no es el sector: es qué dato maneja cada ability y quién puede pedirla.
Riesgos de abrir tu web a un agente de IA
El riesgo no es la Abilities API —es una capa de permisos más explícita que lo anterior—, sino los plugins que registran abilities sin pensar en quién va a invocarlas. Es el mismo problema de los paquetes npm maliciosos que amenazan una web: más código de terceros, más superficie que vigilar.
La documentación del proyecto recomienda tres medidas antes de activar el adaptador MCP en producción: revisar qué abilities registra cada plugin instalado, limitar los transportes HTTP a las que de verdad hace falta exponer fuera del servidor y mantener un registro de qué agente ejecutó qué, con marca de tiempo. Sin ese registro, un cambio inesperado en una entrada o un pedido no tiene forma de rastrearse hasta su origen. Mantener el núcleo y los plugins al día sigue siendo el primer filtro, y ahí conviene apoyarse en mantenimiento especializado.
Preguntas frecuentes sobre la Abilities API de WordPress
¿Qué versión de WordPress necesito para usarla?
Necesitas WordPress 6.9 o superior para el registro de abilities en el servidor. Si además quieres abilities en el navegador o el flujo completo con el adaptador MCP, conviene estar en la 7.0 o la 7.1 —publicada el 19 de agosto de 2026—, que añade el ciclo de ejecución filtrable y el control de qué abilities se exponen a clientes externos.
¿Un agente de IA puede publicar sin que nadie lo revise?
Solo si una ability lo permite expresamente: el permission_callback decide qué capacidad exige cada acción, y publicar sin revisión es una decisión de quien configura esa ability, no un comportamiento por defecto de la API. Lo prudente es dejar publish_posts fuera del alcance del agente y mandar sus borradores a revisión humana.
¿Sirve para WooCommerce o solo para contenido?
Sirve para cualquier función que un plugin decida registrar, y WooCommerce ya tiene abilities documentadas para consultar stock, pedidos y precios. No es exclusiva del contenido editorial: cualquier plugin —de reservas, de formularios, de un CRM conectado— puede exponer sus propias acciones con el mismo esquema.
¿Hace falta programar algo para empezar a usarla?
Para consultar las abilities que ya trae el núcleo, no: basta con instalar el adaptador MCP y conectar un cliente como Claude Desktop. Para que tu propio plugin o tu catálogo registren acciones nuevas, sí hace falta un desarrollador que defina el esquema y el permiso de cada una.
Fuente: WordPress.org (Make Core) — Abilities API in WordPress 6.9
