Cómo hicimos más fácil de usar el ecosistema de plugins MCP

MCP hace que la automatización de WordPress sea más útil, pero el ecosistema ha crecido lo suficiente como para que los nuevos usuarios necesiten un punto de partida más claro.

Un solo plugin es fácil de explicar. Un plugin principal, un adaptador, una serie de add-ons, releases en GitHub, páginas de WordPress y pasos de configuración en el orden correcto pueden convertirse rápidamente en un rompecabezas. Esa es la fricción que hemos estado eliminando.

El objetivo es simple: que quede claro qué instalar primero, qué hace cada add-on y cómo exponer abilities útiles de WordPress sin dar a un asistente de IA una superficie de administración vaga y sin control.


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: entradas, páginas, medios, menús, usuarios, comentarios, taxonomías, plugins, opciones, widgets, depuración y operaciones cercanas a la caché.
  • Edición y construcción de páginas: Gutenberg, GeneratePress, GenerateBlocks, Elementor, plantillas, patrones y datos de diseño.
  • Operaciones e integraciones: Rank Math, Wordfence, Cloudflare, Cache Enabler, Broken Link Checker, Brevo, WPML, Toolset, Formidable, Advanced Ads, sistema de archivos, base de datos, revisiones de plugins y flujos de correo de Workspace.

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. Instala Abilities API.
  2. Instala MCP Adapter.
  3. Instala MCP Expose Abilities para las abilities nativas de WordPress del núcleo.
  4. Añade solo los plugins de abilities concretos que encajan con el stack del sitio.
  5. Empieza con operaciones de lectura sin riesgo antes de permitir que un asistente haga cambios.

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.

Deja una respuesta

Este sitio utiliza Akismet para reducir el spam. Aprenda cómo se procesan sus datos de comentario.