Abilities API WordPress: qué es y cómo usarla

En pocas palabras: WordPress muestra qué sabe hacer a través de la Abilities API, incluida desde WordPress 6.9: un registro central donde plugins, themes y el core declaran cada función con entradas, salidas y permisos, para que PHP, la REST API o un agente de IA la descubran y ejecuten.

La Abilities API de WordPress es un registro central, incluido desde WordPress 6.9, donde plugins, themes y el core declaran sus funciones con entradas, salidas y permisos definidos. Así PHP, la REST API o un agente de IA pueden descubrirlas y ejecutarlas igual. La charla de Piotrek Niewiadomski en WordCamp Wrocław 2026 la volvió a poner en agenda.

La Abilities API es un sistema de WordPress que permite a plugins, themes y al core registrar sus capacidades en un formato estandarizado y legible por máquinas. Cada ability es una unidad de funcionalidad con entradas, salidas, permisos y lógica de ejecución definidas. Sirve a desarrolladores que quieren exponer funciones de forma predecible, y a herramientas de automatización y agentes de IA que necesitan saber qué puede hacer un sitio.

Una aclaración de entrada: la fuente de esta nota es el resumen de la charla (publicado el 9 de octubre de 2026, en polaco), no un anuncio de producto. No vi el video ni las diapositivas. El código de abajo sale de la documentación de core, no de la presentación.

¿Qué problema resuelve la Abilities API de WordPress?

Resuelve que, fuera del código de cada plugin, nadie sabe qué puede hacer un sitio. La ficha de la charla en WordPress.tv lo plantea así: WordPress hace mucho, pero otros plugins, aplicaciones o un agente de IA no tienen cómo enterarse de qué hay disponible ni cómo usarlo. La Abilities API es la forma estandarizada de definir y exponer esas capacidades.

Ejemplo hipotético, para bajarlo a tierra: tenés un plugin de reservas y un cliente quiere que un asistente consulte turnos libres. Hoy eso termina en un handler AJAX propio o en una ruta REST a medida, y cada integración descubre a mano cómo se llama. Con abilities, la función se declara una vez con su esquema y queda en el registro. Complementá con todo sobre la comunidad de WordPress Core.

Eso sí: la ficha es un resumen de unas pocas líneas. Dice que la charla incluye código y ejemplos prácticos, pero no los muestra.

¿Desde qué versión de WordPress está disponible la Abilities API?

Desde WordPress 6.9. Según la nota del equipo de core del 10 de noviembre de 2025, esa versión introduce la API como sistema base y la ubica dentro de la iniciativa AI Building Blocks for WordPress. La referencia de la API PHP vive en el repositorio WordPress/abilities-api. Si tu sitio está en una versión anterior, chequeá antes de llamar a wp_register_ability(), porque son funciones nuevas de la 6.9.

¿Cómo se registra una ability en WordPress?

Con wp_register_ability() dentro del hook wp_abilities_api_init, después de registrar una categoría en wp_abilities_api_categories_init. Si registrás fuera de ese hook, WordPress dispara un aviso _doing_it_wrong() y el registro falla, según la nota de core. El nombre sigue el formato namespace/nombre-de-la-ability, en minúsculas.

La documentación de la API PHP marca estos argumentos:

• label y description (obligatorios): textos traducibles. La descripción importa de verdad: la doc dice que es clave para que un agente de IA entienda cuándo usar la ability.
• category (obligatorio): el slug de una categoría ya registrada.
• output_schema (obligatorio): JSON Schema de lo que devuelve.
• execute_callback y permission_callback (obligatorios): la lógica y el chequeo de permisos.
• input_schema (opcional): solo si la ability recibe datos.
• meta (opcional): acá van show_in_rest y las annotations (readonly, destructive, idempotent).

Un ejemplo mínimo, adaptado de los ejemplos de esa documentación (el nombre del plugin es inventado):

add_action( 'wp_abilities_api_categories_init', 'mi_plugin_registrar_categorias' );
function mi_plugin_registrar_categorias() {
 wp_register_ability_category( 'data-retrieval', array(
 'label' => __( 'Data Retrieval', 'mi-plugin' ),
 'description' => __( 'Abilities that retrieve and return data from the WordPress site.', 'mi-plugin' ),
 ) );
}

add_action( 'wp_abilities_api_init', 'mi_plugin_registrar_abilities' );
function mi_plugin_registrar_abilities() {
 wp_register_ability( 'mi-plugin/get-site-info', array(
 'label' => __( 'Get Site Information', 'mi-plugin' ),
 'description' => __( 'Retrieves the site name and URL.', 'mi-plugin' ),
 'category' => 'data-retrieval',
 'output_schema' => array(
 'type' => 'object',
 'properties' => array(
 'name' => array( 'type' => 'string' ),
 'url' => array( 'type' => 'string', 'format' => 'uri' ),
 ),
 ),
 'execute_callback' => function () {
 return array(
 'name' => get_bloginfo( 'name' ),
 'url' => home_url(),
 );
 },
 'permission_callback' => function () {
 return current_user_can( 'read' );
 },
 'meta' => array(
 'show_in_rest' => true,
 'annotations' => array( 'readonly' => true, 'destructive' => false ),
 ),
 ) );
}

Para ejecutarla desde PHP, en el hook init o uno posterior, hacés wp_get_ability( ‘mi-plugin/get-site-info’ )->execute(). No probé este snippet en un sitio real; lo armé siguiendo la doc. Corrélo en staging antes de confiar en él. Para más detalles técnicos, mirá cómo crear una landing page en WordPress.

¿Cómo se conectan las abilities con la REST API y los agentes de IA?

Poniendo meta.show_in_rest en true, WordPress expone la ability bajo el namespace wp-abilities/v1. Por defecto es false: la ability queda oculta de los listados REST y no se puede ejecutar por esa vía, aunque sigue disponible para PHP interno. Los endpoints que lista la nota de core son estos:

• GET /wp-abilities/v1/abilities: lista todas las abilities.
• GET /wp-abilities/v1/abilities/{name}: devuelve una sola.
• GET|POST|DELETE /wp-abilities/v1/abilities/{name}/run: la ejecuta.
• GET /wp-abilities/v1/categories: lista las categorías (y /categories/{slug} trae una).

Todos requieren usuario autenticado. La nota de core menciona cookie (mismo origen), application passwords (la opción recomendada para acceso externo) y plugins de autenticación propios. Para listar desde afuera: curl -u ‘USUARIO:APPLICATION_PASSWORD’ https://example.com/wp-json/wp-abilities/v1/abilities.

Del lado de la IA, la nota de core describe la API como la base para que agentes y herramientas de automatización entiendan WordPress «de forma predecible». Es el punto donde los esquemas pagan la entrada: un agente que lee input_schema y description sabe qué mandar sin leer tu código.

Sobre el MCP Adapter, que traduce abilities a Model Context Protocol para que asistentes de IA las descubran: ninguna de las fuentes de esta nota lo cubre, así que no te puedo confirmar su estado actual. Revisá su repositorio oficial antes de depender de él. Ya lo cubrimos antes en probar cambios en un entorno de staging.

¿Qué diferencia hay entre una ability y un endpoint de la REST API?

Un endpoint es una ruta HTTP; una ability es una función declarada con esquema y permiso, y la REST API es una de las formas de llegar a ella. Esto último es lectura mía a partir de la documentación, no una frase de la fuente. La prueba está en que una ability con show_in_rest en false sigue ejecutándose desde PHP. Un endpoint clásico, en cambio, nace atado a HTTP y cada plugin documenta (o no) su contrato a su manera.

¿Qué límites y cuidados tiene la Abilities API?

El principal: los permisos son tuyos. La API ejecuta lo que declaraste en permission_callback y nada más.

• Validación con límites: WordPress valida con un subconjunto de JSON Schema versión 4. Si la entrada no valida contra el input_schema, el permission_callback ni se llama y vuelve un WP_Error.
• Acciones sensibles: las annotations son pistas sobre el comportamiento (por defecto, destructive es true y readonly es false), no un sistema de seguridad.
• Alcance: la API sirve en la medida en que los plugins registren abilities. ¿Hay cifras de adopción? En estas fuentes, ninguna, y no pienso inventarlas.
• Nivel de la charla: el resumen la presenta como introductoria, así que no esperes un análisis de producción.

Si lo tuyo es endurecer qué se expone y a quién, ese tema es del blog hermano seguridadenwordpress.com. Acá me quedo con lo funcional.

¿Qué cambia en la práctica para quienes desarrollan en WordPress?

Mi postura: conviene registrar como abilities las dos o tres funciones clave de tu plugin en lugar de seguir sumando integraciones ad hoc. Costo bajo, y si mañana un cliente pide conectar un agente, ya tenés el contrato escrito. Ahora bien, no hace falta migrar todo: empezá por lecturas. Lo complementamos en medidas para proteger la API REST.

Un criterio de verificación, propuesta editorial mía y no de la fuente:

• Listado: registrá una ability de solo lectura con show_in_rest en true y confirmá que aparece en /wp-abilities/v1/abilities con sus esquemas.
• Permisos: llamala con un usuario sin la capacidad requerida y verificá que la rechace.
• Ocultamiento: poné show_in_rest en false y comprobá que desaparece del listado REST pero sigue ejecutándose desde PHP.

Hacé todo en un entorno de staging, por ejemplo en un hosting WordPress de Donweb, antes de tocar producción.

Errores comunes al trabajar con la Abilities API

• Registrar fuera del hook: llamar a wp_register_ability() en el cuerpo del plugin o en init dispara _doing_it_wrong() y la ability no se registra. Va en wp_abilities_api_init.
• Categoría inexistente: la category es obligatoria y tiene que estar registrada antes, en wp_abilities_api_categories_init. El slug admite solo minúsculas, números y guiones (nada de guiones bajos).
• Nombre sin namespace: usá mi-plugin/mi-ability, con minúsculas, números y guiones, para no pisarte con otro plugin.
• Copiar el permiso permisivo: la doc usa __return_true en un ejemplo de lectura de datos públicos del sitio. Lo copiás a la siguiente ability, esa sí modifica opciones, y ahora cualquiera con acceso autenticado puede escribir. Para eso usá una capacidad real, como manage_options.
• Dejar las annotations por defecto: si no marcás readonly en una ability de lectura, el valor por defecto dice que no lo es y que puede ser destructiva.

Preguntas Frecuentes

¿Qué es la Abilities API de WordPress?

Es un sistema del core que permite a plugins, themes y WordPress registrar sus capacidades en un formato estandarizado y legible por máquinas. Cada ability define entradas, salidas, permisos y lógica de ejecución, y se guarda en un registro central. Relacionado: cómo corregir los enlaces rotos del sitio.

¿Desde qué versión de WordPress está disponible la Abilities API?

Desde WordPress 6.9. La nota de desarrollo de core del 10 de noviembre de 2025 la presenta como una de las novedades de esa versión. Más sobre esto en la vulnerabilidad sin autenticación de CAFEHAUS API.

¿Cómo se crea una ability personalizada en WordPress?

Registrás una categoría con wp_register_ability_category() en wp_abilities_api_categories_init, y después la ability con wp_register_ability() en wp_abilities_api_init. Necesitás label, description, category, output_schema, execute_callback y permission_callback.

¿Qué diferencia hay entre una ability y un endpoint de la REST API?

Un endpoint es una ruta HTTP; una ability es una función declarada con esquemas y permisos que además se puede exponer por REST. Con show_in_rest en false, la ability sigue disponible para PHP interno.

¿Cómo se relaciona la Abilities API con la REST API y los agentes de IA?

Con show_in_rest en true, las abilities salen bajo wp-abilities/v1 y requieren autenticación. La nota de core las presenta como base para que agentes de IA y herramientas de automatización entiendan WordPress de forma predecible.

Conclusión

Lo confirmado: desde WordPress 6.9 hay un registro oficial de capacidades con esquemas, permisos y salida opcional por REST. Lo que sigue abierto es cuánto se va a usar, porque depende de que los plugins las registren y las fuentes no traen datos de adopción.

Mi sugerencia: registrá una ability de lectura de tu propio plugin, probala con el criterio de verificación de arriba y recién ahí decidí si vale la pena migrar más. Y si el tema te toca, mirá la charla de Niewiadomski (está en polaco, con subtítulos pendientes de comunidad).

Fuentes

• Make WordPress Core – Abilities API in WordPress 6.9 (10/11/2025)
• GitHub WordPress/abilities-api – Documentación de la API PHP
• WordPress.tv – WordPress, pokaż co potrafisz! (WordCamp Wrocław 2026, 9/10/2026)