WordPress e IA: la Abilities API desde WordPress 6.9

#¿Qué es la WordPress Abilities API?

#El problema con los enfoques actuales

La WordPress REST API es potente pero orientada a recursos. Expone endpoints como /wp/v2/posts y /wc/v3/products, es decir, operaciones CRUD sobre objetos de datos. Un agente de IA puede usar esos endpoints, pero necesita estar preprogramado para saber qué hace cada uno, qué parámetros acepta y cómo encadenar varias llamadas para lograr un objetivo.

WPGraphQL mejora esto al permitir consultas flexibles, pero comparte la misma limitación de fondo: describe datos, no capacidades.

Consideremos este escenario: quieres que un agente de IA «escriba un artículo sobre jardinería primaveral, lo optimice para SEO, añada una imagen destacada y programe la publicación para el próximo martes.» Con la REST API, el agente necesita:

1. Conocer el endpoint /wp/v2/posts y sus parámetros
2. Saber que los datos SEO residen en un campo meta controlado por Yoast o RankMath
3. Saber cómo subir medios vía /wp/v2/media
4. Conocer el formato de fecha para programación
5. Encadenar estas llamadas en el orden correcto

Con la Abilities API, un plugin registra operaciones estrechas como contenido/crear-borrador o medios/adjuntar-imagen. Una integración autenticada lista las abilities publicadas por REST, lee sus esquemas y llama al endpoint /run. La planificación del flujo sigue siendo cosa de quien llama, salvo que el plugin registre una operación de nivel superior que lo resuelva por dentro.

#Visión general de la arquitectura

La API tiene cuatro piezas: la categoría agrupa operaciones relacionadas; la ability lleva identificador con forma espacio-de-nombres/nombre, etiqueta, descripción, esquemas y callbacks; el registro permite que el propio código PHP descubra lo disponible; la exposición REST es un transporte opcional para sistemas externos autenticados.

El registro ocurre en hooks dedicados, y el momento importa. Las categorías se declaran en wp_abilities_api_categories_init con wp_register_ability_category(); las abilities, en wp_abilities_api_init con wp_register_ability(). Registrar desde un hook genérico de carga del plugin se ejecuta antes de que los registros estén listos, y la llamada se pierde sin ruido.

El manual oficial documenta la API del lado servidor para WordPress 6.9 y posteriores. Los paquetes cliente de 7.0 cargan abilities del servidor en JavaScript dentro del administrador, pero no mueven la autorización: sigue en PHP.

#Descubrimiento y ejecución por REST

La exposición REST está desactivada por defecto y se activa por ability, mediante meta.show_in_rest. Cuando se activa, un cliente autenticado puede listar las abilities en /wp-json/wp-abilities/v1/abilities, recuperar una concreta por espacio de nombres y nombre, y llamar a su endpoint /run.

# Listar las abilities visibles para el usuario autenticado
curl -u "usuario:contraseña-de-aplicación" \
  https://ejemplo.com/wp-json/wp-abilities/v1/abilities

# Ejecutar una ability concreta
curl -X POST \
  -u "usuario:contraseña-de-aplicación" \
  -H "Content-Type: application/json" \
  -d '{"checks":["performance","security"]}' \
  https://ejemplo.com/wp-json/wp-abilities/v1/abilities/wppoland/estado-del-sitio/run

Ese comando solo funciona bajo un supuesto explícito: que wppoland/estado-del-sitio se registró con meta.show_in_rest en verdadero. Es la única ability del artículo que asume esa decisión. La de informes que aparece más abajo se registra en falso, así que no responde por REST hasta que se le añaden las dos claves que se muestran junto a su registro.

Se aplica la autenticación habitual de la REST API: cookies para el mismo origen, contraseñas de aplicación para acceso externo. Ver una ability en el listado no autoriza a ejecutarla: WordPress evalúa su permission_callback para el usuario actual.

Esa separación es útil en el día a día: una ability interna para otro código PHP se queda con show_in_rest en falso, una de solo lectura puede publicarse para una cuenta de servicio con capacidades limitadas, y una operación destructiva merece un permission callback más estrecho.

#Lo que cambia con WordPress 7.1

WordPress 7.1 se publica el 19 de agosto de 2026 y toca esta API en tres puntos: una clave nueva en el registro, una función de descubrimiento que acepta argumentos y dos filtros de PHP.

#La clave meta.public declara una intención

La nota para desarrolladores del 4 de agosto añade public dentro del array meta. La descripción oficial es esta: «The flag provides a single, high-level way to indicate that an ability is intended to be available to external clients such as the REST API.» Es decir, una manera única y de alto nivel de declarar que la ability está pensada para clientes externos como la REST API.

Esa palabra, intención, hay que leerla literalmente. public deja constancia de que la operación puede alcanzarse desde fuera, sea por REST, por un adaptador MCP o por un agente. No construye ninguno de esos consumidores. El núcleo sigue sin servidor MCP, sin ámbitos OAuth pensados para agentes, sin límites de tasa, sin rastro de auditoría y sin cola de aprobación. Esa lista no se acorta en 7.1.

Tampoco sustituye a las banderas por canal: show_in_rest se mantiene y tiene prioridad. La resolución en el núcleo es exactamente esta:

$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;

Ante valores opuestos gana la específica. El registro completo de la nota:

wp_register_ability(
    'my-plugin/export-users',
    array(
        'label'               => __( 'Export users', 'my-plugin' ),
        'description'         => __( 'Exports user data as CSV.', 'my-plugin' ),
        'category'            => 'data-export',
        'execute_callback'    => 'my_plugin_export_users',
        'permission_callback' => function (): bool {
            return current_user_can( 'export' );
        },
        'meta'                => array(
            'public' => true,
        ),
    )
);

#wp_get_abilities() con argumentos

Antes de 7.1, quien necesitaba un subconjunto tenía que pedir el registro entero y filtrarlo a mano con array_filter(). La nota del 5 de agosto documenta un $args opcional:

• category, cadena, una categoría registrada
• namespace, cadena, las abilities de un plugin
• meta, array, claves de metadatos, public incluida
• item_include_callback, callable, decide ability por ability
• result_callback, callable, transforma lo devuelto

Las condiciones se combinan con AND y una ability tiene que cumplirlas todas para aparecer. Antes de usar esto como control de acceso, la nota avisa: «Filtering controls which abilities are returned during discovery. It does not determine whether the current user may execute an ability.» El filtrado decide qué se ve al descubrir, no quién puede ejecutar; eso sigue resolviéndolo el permission_callback en cada llamada.

Los dos filtros nuevos, wp_get_abilities_item_include y wp_get_abilities_result, permiten intervenir en la selección y en el resultado, y rest_abilities_collection_params amplía el esquema de argumentos de la colección REST.

#Qué hace falta para conectar un agente de IA

#La conexión con el Model Context Protocol (MCP)

El Model Context Protocol define cómo un agente descubre y utiliza herramientas externas. La Abilities API encaja bien como origen de esas herramientas, porque ya entrega nombre, descripción y esquemas. Lo que no ocurre es la conversión automática: el núcleo no publica un endpoint MCP, y ningún cliente compatible se conecta solo a una instalación limpia.

El puente hay que construirlo, y su diseño es donde se decide el riesgo real: se autentica con una identidad propia y acotada, elige qué abilities expone (menos de las que ese usuario puede ejecutar), traduce esquemas y errores, y aplica sus propios límites.

Un asistente de soporte, por ejemplo, puede recibir una consulta de producto de solo lectura y una operación para crear un borrador de ticket. Los reembolsos y los cambios de configuración se quedan fuera. Esa lista corta es más fácil de revisar que un agente generalista con cuenta de administrador.

#Otros formatos de herramientas

Con el formato de OpenAI o con llamadas a funciones genéricas ocurre lo mismo: los esquemas se proyectan bien sobre una definición de herramienta, pero la capa intermedia decide qué se publica y con qué credenciales. Cuanto más estrecho sea el esquema, mejor: enumeraciones en vez de cadenas libres, formatos declarados en las fechas y un required explícito. Una operación que acepta cualquier texto acaba siendo un canal de instrucciones sin supervisar.

#Casos de uso prácticos

#Flujos de trabajo de creación de contenido

El caso de uso más inmediato es la creación de contenido asistida. En lugar de que una IA genere texto bruto que un humano pega en WordPress, cada paso se registra como una operación con esquema y permisos:

Usuario: "Crea una guía completa sobre control biológico de plagas para nuestro blog de jardinería"

Composición por la capa de orquestación:
1. investigar_temas          → subtemas en tendencia y brechas de la competencia
2. generar_contenido         → artículo con encabezados y referencias de imágenes
3. optimizar_seo             → meta descripción, palabra clave foco, enlaces internos
4. generar_imagen_destacada  → imagen hero
5. crear_borrador            → guarda como borrador con todos los metadatos
6. notificar_editor          → aviso de revisión al equipo editorial

Cada ability puede venir de un plugin distinto: el SEO de RankMath, la imagen de un plugin de medios, el aviso de un plugin de flujos. La Abilities API aporta el contrato común, no el planificador: qué hacer si el paso 4 falla después de que el 3 haya escrito metadatos es decisión de tu capa de orquestación.

#Gestión de tienda WooCommerce

Para sitios de e-commerce, las operaciones candidatas son fáciles de enumerar:

• Gestión de inventario: monitorizar niveles de stock, generar sugerencias de reabastecimiento, actualizar cantidades
• Optimización de precios: analizar precios de la competencia, sugerir ajustes, aplicar cambios masivos
• Descripciones de productos: generar y actualizar descripciones basadas en atributos y objetivos SEO
• Servicio al cliente: consultar pedidos, actualizar estados, generar etiquetas de envío
• Análisis de ventas: generar informes, identificar tendencias, sugerir promociones

La parte de lectura encaja bien en abilities expuestas. La que escribe conviene partirla: una ability que propone cambios y devuelve una lista, y otra distinta que los aplica tras revisión. Un reembolso no debería compartir permission callback con una consulta de stock.

#Automatización de SEO

Las tareas de SEO que antes requerían trabajo manual encajan casi literalmente en el modelo:

• analizar_seo_pagina retorna puntuación, meta tags faltantes y densidad de palabras clave
• sugerir_enlaces_internos encuentra contenido relacionado para cross-linking
• revisar_enlaces_rotos escanea 404 y sugiere reemplazos
• generar_marcado_schema crea datos estructurados JSON-LD
• optimizar_imagenes comprime y añade texto alternativo
• auditar_frescura_contenido marca contenido desactualizado para revisión

Las cuatro primeras son de solo lectura y buenas candidatas para show_in_rest. Las dos últimas escriben en la base de datos o en los archivos del sitio, y merecen una capacidad más restrictiva y una ejecución por lotes reversible.

#Implementar abilities personalizadas en tu plugin

#Registro básico de una ability

Una ability necesita identificador único, categoría, metadatos legibles por humanos, esquemas, callback de ejecución y callback de permisos. La categoría se registra primero, en su propio hook.

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category(
        'analitica',
        array(
            'label'       => __( 'Analítica', 'wppoland' ),
            'description' => __( 'Informes de tráfico y ventas del sitio.', 'wppoland' ),
        )
    );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability(
        'wppoland/generar-informe',
        array(
            'label'               => __( 'Generar informe analítico', 'wppoland' ),
            'description'         => __( 'Crea un informe de analítica para un período determinado.', 'wppoland' ),
            'category'            => 'analitica',
            'input_schema'        => array(
                'type'       => 'object',
                'properties' => array(
                    'start_date' => array( 'type' => 'string', 'format' => 'date' ),
                    'end_date'   => array( 'type' => 'string', 'format' => 'date' ),
                    'metric'     => array(
                        'type' => 'string',
                        'enum' => array( 'sesiones', 'pedidos', 'ingresos' ),
                    ),
                ),
                'required'   => array( 'start_date', 'end_date' ),
            ),
            'output_schema'       => array(
                'type'       => 'object',
                'properties' => array(
                    'report_url' => array( 'type' => 'string', 'format' => 'uri' ),
                    'summary'    => array( 'type' => 'string' ),
                ),
            ),
            'execute_callback'    => 'wppoland_generar_informe',
            'permission_callback' => function () {
                return current_user_can( 'edit_others_posts' );
            },
            'meta'                => array(
                'show_in_rest' => false,
            ),
        )
    );
} );

Este ejemplo se queda dentro del sitio: con show_in_rest en falso, otro código PHP la obtiene con wp_get_ability() y la ejecuta. Cuando exista un consumidor externo real, bastan dos claves más:

'meta' => array(
    'show_in_rest' => true,
    'annotations'  => array( 'readonly' => true ),
),

En producción, la capacidad debe corresponderse con los datos devueltos y hay que probar con un usuario autorizado y con otro que no lo esté. Si esa segunda prueba nunca se hace, el permission_callback es decorativo.

#La composición es responsabilidad de quien llama

El núcleo aporta registro, descubrimiento, validación y ejecución. No hay planificador de flujos ni un campo que declare prerrequisitos entre abilities. Si varias operaciones deben ejecutarse en un orden fijo, hay dos caminos honestos: una ability del lado servidor que sea dueña de la transacción completa, o una capa de orquestación revisada que llame a las abilities por separado.

function wppoland_publicar_articulo_optimizado( array $input ) {
    $contenido = wppoland_generar_contenido( $input );
    if ( is_wp_error( $contenido ) ) {
        return $contenido;
    }

    $seo = wppoland_optimizar_seo( $contenido );
    if ( is_wp_error( $seo ) ) {
        return $seo;
    }

    return wppoland_crear_borrador( $contenido, $seo );
}

La opción del servidor es más segura cuando los cambios están acoplados: un único callback valida la entrada completa, se detiene en el primer error y devuelve un resultado estructurado. La composición del lado cliente sirve para lecturas independientes, pero deja los fallos parciales en manos de quien llama.

#Controles operativos explícitos

No existen hooks de middleware documentados alrededor de la invocación, así que no conviene inventarlos. La validación de dominio va dentro del execute_callback, y los límites de tasa en la pasarela, el proxy inverso o la capa de aplicación.

function wppoland_estado_del_sitio( array $input ) {
    if ( wppoland_supera_limite( get_current_user_id(), 'estado-del-sitio' ) ) {
        return new WP_Error( 'rate_limited', 'Demasiadas solicitudes', array( 'status' => 429 ) );
    }

    wppoland_registrar_llamada( get_current_user_id(), 'estado-del-sitio' );

    return wppoland_ejecutar_comprobaciones( $input['checks'] ?? array() );
}

#Consideraciones de seguridad para el acceso externo

#Autenticación y autorización

Los endpoints REST de abilities usan la autenticación de la REST API de WordPress: cookies para el mismo origen, contraseñas de aplicación para acceso externo, o un plugin de autenticación propio. Si necesitas ámbitos por agente, esa es una capa que instalas o construyes, no algo que la Abilities API traiga de fábrica.

La autenticación responde a quién llama; el permission_callback, a si ese usuario puede ejecutar esa operación. Hay que mantener las dos comprobaciones: una credencial de administrador compartida entre integraciones anula el sentido de un contrato de operaciones estrechas. La visibilidad REST es la tercera frontera y merece una línea propia en la revisión de código.

#Aprobación humana para cambios de riesgo

El núcleo no ofrece una cola de aprobación genérica; si un reembolso o un cambio de configuración necesita confirmación humana, esa cola se construye en la aplicación de dominio. El patrón habitual: la ability crea una solicitud pendiente y devuelve su identificador, y una acción de administración separada la aprueba.

El registro de aprobación debería identificar el cambio propuesto, quién lo revisó, cuándo caduca y un resumen criptográfico exacto del input. Reutilizar una aprobación para un input modificado abre precisamente el hueco que el flujo pretendía cerrar.

#Rastro de auditoría

La API no genera un rastro de auditoría por sí sola. Para cada operación expuesta al exterior hay que decidir qué se registra:

• usuario de WordPress o cuenta de servicio autenticada
• nombre de la ability e identificador de correlación de la petición
• categoría del resultado y duración
• referencia de aprobación en los cambios sensibles
• marca temporal y versión relevante de la aplicación

Evita registrar secretos, prompts completos o datos personales innecesarios. La retención necesita un responsable, no solo una tabla.

#Sanitización de input

La Abilities API valida los inputs contra el esquema JSON declarado antes de ejecutar el callback. Pero el esquema comprueba la forma, no convierte una cadena en segura para cualquier destino: aplica las funciones de sanitización y escape según el contexto real (sanitize_text_field(), wp_kses_post(), esc_url_raw()) y usa consultas preparadas al tocar la base de datos.

#Comparación con enfoques existentes

#REST API frente a Abilities API

#WPGraphQL frente a Abilities API

WPGraphQL destaca en consultas flexibles: los clientes solicitan exactamente lo que necesitan en una única petición. La Abilities API no lo reemplaza; de hecho, una ability puede usar GraphQL internamente y exponer una interfaz de nivel superior.

Simplificando: GraphQL responde a «¿qué datos tienes?» mientras la Abilities API responde a «¿qué operaciones ofreces?».

#Cuándo usar qué

• REST API: integraciones servidor a servidor, aplicaciones móviles, frontend tradicional
• WPGraphQL: obtención compleja de datos, frontends headless, arquitecturas Jamstack
• Abilities API: contratos de operaciones para automatización e integración con agentes

#El futuro de los flujos de trabajo impulsados por IA

#Orquestación multi-agente

A medida que los sistemas de IA maduran, veremos agentes especializados colaborando: uno para contenido, otro para SEO, otro para revisión. La Abilities API puede ser el vocabulario común de esa coordinación, pero el coordinador vive fuera de WordPress, y depurar tres agentes que se pisan entre sí es bastante peor que depurar un script.

#Implicaciones para el marketplace

El ecosistema evolucionará para incluir bundles de abilities: extensiones que existen sobre todo para publicar operaciones, a veces sin interfaz alguna. Y un buen bundle se juzgará por lo estrechos que sean sus esquemas y sus permission callbacks, no por cuántas operaciones expone.

#WordPress como backend orquestable

Esto es útil incluso sin ningún agente de por medio: un plugin puede descubrir operaciones de otro, leer su esquema y ejecutarlas a través del mismo registro, en lugar de acoplarse a funciones internas que pueden desaparecer en la siguiente versión.

#Integración con servicios de IA externos

No existe una función genérica del tipo invoke_external_ability(). Lo que sí puedes hacer es llamar a un servicio externo con la HTTP API de WordPress y envolver esa llamada en tu propia ability, asumiendo la responsabilidad de credenciales, tiempos de espera, reintentos, control de coste y validación de la respuesta.

function wppoland_generar_variante_aprobada( array $input ) {
    $respuesta = wp_remote_post(
        'https://api.proveedor.example/v1/images',
        array(
            'timeout' => 20,
            'headers' => array( 'Authorization' => 'Bearer ' . wppoland_obtener_clave() ),
            'body'    => wp_json_encode( array( 'prompt' => $input['prompt'] ) ),
        )
    );

    if ( is_wp_error( $respuesta ) ) {
        return $respuesta;
    }

    return wppoland_validar_y_guardar_imagen( $respuesta );
}

Mantén la llamada externa detrás de una operación de dominio estrecha. Una ability llamada medios/crear-variante-aprobada es más fácil de revisar que un relé de prompts genérico que acepta instrucciones arbitrarias y escribe el resultado en los metadatos de una entrada.

#Empezar hoy

Si trabajas sobre WordPress 6.9 o posterior, el camino corto es este:

1. Elige una sola operación, de solo lectura y con poco alcance
2. Registra su categoría en wp_abilities_api_categories_init
3. Registra la ability con wp_register_ability() en wp_abilities_api_init
4. Define los esquemas de entrada y salida, lo más estrechos posible
5. Comprueba los permisos con un usuario autorizado y con otro que no lo esté
6. Mantén REST cerrado por defecto y activa show_in_rest solo para un consumidor externo real
7. Añade los controles que faltan: límites de tasa, auditoría y aprobaciones son arquitectura de tu proyecto

El beneficio práctico es un contrato estable entre los componentes de WordPress y la automatización externa, aunque no haya ningún agente de IA en la ecuación. Y si construyes el puente, revisa la lista de operaciones publicadas como revisarías los permisos de un usuario nuevo, porque es exactamente eso.

Para servicios de mantenimiento WordPress y desarrollo a medida que incorporen este modelo, escríbenos desde la página de contacto indicando la versión de WordPress, la operación que quieres exponer y quién va a llamarla.

Verificado contra el manual oficial de la WordPress Abilities API y las notas para desarrolladores de WordPress 7.0 y 7.1 el 9 de agosto de 2026.