El problema no eran los plugins
Los plugins hacían un trabajo útil. El punto débil estaba en el recorrido alrededor de ellos.
- ¿Qué plugin se debe instalar primero?
- ¿Qué add-ons son opcionales?
- ¿Qué página tiene la información de release actual?
- ¿Qué gestiona el plugin principal y qué corresponde a un add-on?
- ¿Cómo se sabe que el ecosistema sigue mantenido?
No son preguntas menores para alguien que prueba MCP en un sitio WordPress real. Si el camino de configuración no está claro, la parte útil empieza demasiado tarde.
Qué cambiamos
- Ordenamos las páginas de plugins en Devenia para que el plugin principal y los add-ons expliquen el mismo ecosistema de forma coherente.
- Actualizamos cifras, referencias de release y enlaces obsoletos que hacían que páginas antiguas sonaran más nuevas que la página principal.
- Reconstruimos la página de MCP Expose Abilities como contenido Gutenberg mantenible.
- Aclaramos el orden de instalación: primero Abilities API y MCP Adapter, después MCP Expose Abilities y luego solo los add-ons que el sitio realmente necesita.
- Hicimos que el ecosistema fuera más fácil de revisar agrupando los add-ons según el trabajo de WordPress que controlan.
Ese tipo de limpieza no es cosmética. Cambia si el proyecto se siente accesible o como una pila de herramientas potentes sin una entrada clara.
La forma actual del ecosistema
La página actual de MCP Expose Abilities documenta 67 abilities nativas de WordPress en el plugin principal. El stack mantenido más amplio ya incluye 18 add-ons publicados y más de 450 abilities documentadas.
Eso no significa que todos los sitios deban instalarlo todo. El punto es justo el contrario. Un sitio con GeneratePress no necesita abilities de Elementor. Un sitio sin Brevo no necesita abilities de Brevo. Una superficie de instalación menor es más fácil de entender y de mantener segura.
Trabajo central de WordPress
Edición y construcción de páginas
Operaciones e integraciones
Ese es el mensaje más claro que queremos transmitir: empezar por el núcleo, añadir solo lo que encaja con el sitio y mantener cada operación expuesta nombrada e inspeccionable.
Por qué esto importa más allá de lo técnico
La buena automatización no empieza con la lista de funciones más larga posible. Empieza con confianza: ¿puedes entender qué puede hacer el asistente, por qué existe esa ability y si sigue aplicando el permiso correcto de WordPress?
Por eso importa el modelo de add-ons. Permite que un sitio exponga un conjunto enfocado de abilities en lugar de tratar todas las operaciones de WordPress como una sola puerta de todo o nada.
Para un propietario de sitio o un desarrollador, eso significa menos conjeturas antes de la primera prueba útil. Para un flujo de agente, significa herramientas más claras, permisos más limpios y menos desvíos innecesarios.
Un mejor primer camino
Si quieres probar el ecosistema ahora, este es el camino práctico:
1
2
3
4
5
Así el asistente obtiene acceso útil a WordPress sin que la configuración sea más pesada que el trabajo que pretende ahorrar.
Qué viene después
Seguiremos afinando lo que rodea a los plugins: onboarding más claro, mejores notas de release, enlaces de página más sólidos y menos desajuste entre GitHub, WordPress y las páginas de Devenia.
Este trabajo no es solo documentación. Es diseño de producto para un stack de automatización. Las herramientas potentes son más útiles cuando la gente entiende por dónde empezar y qué es seguro ejecutar.
Empieza por MCP Expose Abilities si quieres ver la visión general actual.