Registrar una Ability en WordPress resuelve una parte del problema: define una unidad de funcionalidad con nombre, descripción, esquemas de entrada y salida, callback de ejecución y comprobación de permisos. Eso no convierte automáticamente esa Ability en una herramienta WebMCP que un agente del navegador pueda descubrir en la página externa de WordPress Playground. Son dos registros y dos rutas de exposición diferentes.
En Playground, la diferencia se ve con más claridad porque WordPress se ejecuta a través de una cadena de iframes. El agente observa la página de nivel superior, mientras que una herramienta del plugin se registra en el documento interno de WordPress. El proxy WebMCP incorporado en Playground existe precisamente para llevar la descripción de la tool fuera del iframe y reenviar la llamada hacia dentro cuando el agente decide ejecutarla. La implementación se integró en el proyecto el 3 de septiembre de 2026, y el equipo de Playground publicó la explicación del flujo el 5 de septiembre.
Ability, tool y proxy son tres piezas distintas
| Pieza | Dónde vive | Qué describe | Cómo llega al agente |
|---|---|---|---|
| WordPress Ability | Registro de la Abilities API en WordPress | Una capacidad reutilizable con esquema, ejecución y permisos | Mediante PHP interno o, cuando se expone, por la Abilities REST API y otros adaptadores |
| Tool WebMCP | document.modelContext del documento web | Una acción que el navegador puede presentar a agentes, con nombre, descripción, esquema de entrada y función de ejecución | Mediante descubrimiento WebMCP en el contexto de la página |
| Proxy de Playground | Página externa, cliente de Playground y puente entre frames | Replica tools registradas dentro de WordPress y reenvía llamadas | Vuelve a registrar esas tools en la página que el agente puede observar |
La consecuencia práctica es sencilla: una Ability puede ser la implementación de negocio que hay detrás de una tool, pero no es la tool en sí. El artículo oficial de Playground afirma explícitamente que registrar una Ability por sí sola no hace que aparezca automáticamente a través del proxy WebMCP.
El recorrido request → proxy → iframe → plugin
- El plugin registra una tool WebMCP dentro de WordPress. El documento interno pasa a tener un descriptor de herramienta con nombre, descripción y esquema de entrada, además de la función que se ejecutará.
- El puente del iframe detecta la lista de tools. La implementación de Playground sigue registros, eliminaciones y cambios de navegación del documento WordPress.
- El proxy vuelve a anunciar esas tools en la página externa. Esa página de nivel superior es la que el agente del navegador puede inspeccionar para descubrir las herramientas disponibles.
- El agente envía los argumentos de la tool. La llamada pasa por el cliente de Playground y por el puente entre frames.
- La ejecución ocurre en el documento WordPress. El plugin ejecuta la lógica local y el resultado vuelve por el mismo camino hasta el agente.
El pull request del proxy describe el flujo conceptual como: agente → contexto WebMCP de la página de Playground → cliente de Playground → frame remoto → documento WordPress → ejecución del plugin. Por eso el proxy no es solo un detalle de red: resuelve una frontera de descubrimiento y de ciclo de vida entre documentos.
Ejemplo conceptual: la misma acción en dos capas
Imagine un plugin de eventos que necesita crear un borrador. En la Abilities API, podría registrar algo como mi-plugin/crear-evento, definir una entrada con título y fecha, validar la salida y usar un permission_callback para exigir que el usuario actual tenga permiso para editar contenido.
Si la intención es que un agente del navegador vea una acción llamada “Crear borrador de evento” entre las Site tools de Playground, el plugin todavía necesita una tool WebMCP. Esa tool puede ser fina: recibe los mismos argumentos, llama a la Ability y devuelve el resultado. Este diseño mantiene reglas de negocio, validación y permisos centralizados en la Ability, mientras que la capa WebMCP se ocupa del descubrimiento y del contrato orientado al agente.
Dicho de otro modo, la Ability responde “qué sabe hacer WordPress y bajo qué reglas”; la tool responde “cómo se ofrece esa acción al agente en este documento web”.
La marca public no elimina la necesidad de una tool WebMCP
En WordPress 7.1, la documentación de la Abilities API usa el metadato de alto nivel public para indicar que una Ability está destinada a clientes externos como REST, MCP o agentes de IA. Esa señal establece valores predeterminados por canal; para REST, por ejemplo, influye en show_in_rest. Aun así, no crea por sí sola un registro en document.modelContext dentro de Playground.
El consumo por HTTP usa otra ruta. Las Abilities expuestas mediante la REST API aparecen bajo /wp-json/wp-abilities/v1/ y pueden descubrirse y ejecutarse mediante endpoints específicos. La documentación oficial también deja claro que esos endpoints requieren un usuario autenticado y que la ejecución sigue sujeta al permission_callback de la Ability.
Dentro de Playground, un agente puede usar la herramienta existente playground_request para realizar solicitudes a WordPress y, por esa vía, descubrir o ejecutar una Ability expuesta mediante la REST API. Esto es distinto de que la Ability aparezca directamente como una tool WebMCP con nombre propio descubierta por el agente en la página.
Cuándo usar una tool WebMCP y cuándo usar la Abilities REST API
| Necesidad | Ruta más directa | Motivo |
|---|---|---|
| La acción debe aparecer como herramienta explícita para el agente que trabaja en Playground | Tool WebMCP, posiblemente envolviendo una Ability | Ofrece descubrimiento nativo en el contexto de la página y una interfaz específica para el agente |
| La misma capacidad debe servir a integraciones HTTP, automatizaciones o clientes fuera del navegador | Ability expuesta mediante la REST API | Ofrece un endpoint estable, autenticación y ejecución independiente de una sesión WebMCP |
| Ya existe una Ability bien definida y también se quiere exponer como Site tool | Wrapper WebMCP fino sobre la Ability | Evita duplicar la lógica de negocio y separa transporte de implementación |
| El agente solo necesita acceso genérico a una Ability expuesta | playground_request + Abilities REST API | No hace falta crear una tool dedicada cuando una solicitud genérica es suficiente |
Esta última ruta es especialmente útil para experimentación o para capacidades administrativas que ya fueron diseñadas como API. Una tool dedicada gana valor cuando el nombre, la descripción y el esquema deben orientar claramente la elección del agente o cuando la acción debe formar parte de la experiencia de Site tools del navegador.
Límites actuales que afectan al diseño
- WebMCP sigue siendo una especificación en incubación. El informe de la Web Machine Learning Community Group publicado el 15 de septiembre de 2026 sigue indicando que WebMCP no es un estándar W3C ni está en la Standards Track. Las implementaciones y los nombres de API todavía pueden evolucionar.
- Se necesita soporte en el navegador o en el entorno del agente. El proxy puede atravesar la frontera del iframe, pero el descubrimiento final sigue dependiendo de una implementación de WebMCP que el agente pueda utilizar.
- Las tools pertenecen al documento que las registró. En el proxy de Playground, una navegación comienza con una lista nueva; el sistema sigue registros tardíos y retira tools que dejan de existir.
- No todas las rutas de WordPress producen un documento con tools. El pull request del proxy menciona respuestas REST, archivos estáticos y admin-ajax.php como ejemplos que no anuncian tools. La pantalla de inicio de sesión tampoco está cubierta por el flujo predeterminado actual.
- Los nombres reservados importan. Una tool de plugin que colisione con una tool interna playground_* es omitida por el proxy para impedir que sustituya una acción de Playground.
- La exposición no sustituye a la autorización. La Ability debe seguir protegiendo la ejecución con reglas de permiso adecuadas. Hacer algo público para descubrimiento no debe tratarse como autorización para cualquier operación.
Checklist para un plugin que quiere trabajar con agentes
- Modele la acción principal como Ability cuando tenga sentido como capacidad reutilizable de WordPress.
- Defina esquemas de entrada y salida y mantenga la comprobación de permisos en la capa de negocio.
- Decida si la capacidad necesita REST; si lo necesita, configure la exposición según la versión de WordPress y el canal deseado.
- Si la acción debe aparecer directamente al agente en Playground, registre una tool WebMCP que mapee a la Ability o a una lógica equivalente.
- Pruebe navegación, wp-admin y páginas públicas por separado, porque el ciclo de vida de las tools sigue al documento activo.
- Trate el proxy como parte de la arquitectura de descubrimiento: anuncia hacia fuera, reenvía hacia dentro y retira tools cuando cambia el contexto.
