Le problème ne venait pas des extensions
Les extensions faisaient un travail utile. Le point faible se trouvait dans le parcours autour d’elles.
- Quelle extension faut-il installer en premier ?
- Quels add-ons sont optionnels ?
- Quelle page contient les informations de release à jour ?
- Que gère l’extension centrale, et qu’est-ce qui relève d’un add-on ?
- Comment voir que l’écosystème est toujours maintenu ?
Ce ne sont pas de petits détails pour quelqu’un qui teste MCP sur un vrai site WordPress. Si le parcours de configuration est flou, la partie utile arrive trop tard.
Ce que nous avons changé
- Nous avons nettoyé les pages d’extensions sur Devenia afin que l’extension centrale et les add-ons expliquent le même écosystème de manière cohérente.
- Nous avons mis à jour les chiffres, références de release et liens obsolètes qui faisaient paraître certaines anciennes pages plus récentes que la page principale.
- Nous avons reconstruit la page MCP Expose Abilities sous forme de contenu Gutenberg maintenable.
- Nous avons clarifié l’ordre d’installation : Abilities API et MCP Adapter d’abord, puis MCP Expose Abilities, puis uniquement les add-ons dont le site a réellement besoin.
- Nous avons rendu l’écosystème plus facile à parcourir en regroupant les add-ons autour du travail WordPress qu’ils contrôlent.
Ce nettoyage n’est pas cosmétique. Il modifie la perception du projet : accessible, ou au contraire rempli d’outils puissants sans entrée claire.
La forme actuelle de l’écosystème
La page actuelle de MCP Expose Abilities documente 67 abilities WordPress natives dans l’extension centrale. La pile maintenue au sens large couvre maintenant 18 add-ons publiés et plus de 450 abilities documentées.
Cela ne veut pas dire que chaque site doit tout installer. Le principe est inverse. Un site GeneratePress n’a pas besoin des abilities Elementor. Un site sans Brevo n’a pas besoin des abilities Brevo. Une surface d’installation plus petite est plus facile à comprendre et à sécuriser.
Travail WordPress central
Édition et construction de pages
Opérations et intégrations
Le message est plus clair ainsi : commencez par le cœur, ajoutez seulement ce qui correspond au site et gardez chaque opération exposée nommée et inspectable.
Pourquoi cela compte au-delà de la technique
Une bonne automatisation ne commence pas par la liste de fonctionnalités la plus longue possible. Elle commence par la confiance : pouvez-vous comprendre ce que l’assistant a le droit de faire, pourquoi cette ability existe et si la bonne permission WordPress s’applique toujours ?
C’est pourquoi le modèle par add-ons compte. Il permet à un site d’exposer un ensemble ciblé d’abilities au lieu de traiter toutes les opérations WordPress comme une seule porte tout-ou-rien.
Pour un propriétaire de site ou un développeur, cela signifie moins de devinettes avant le premier test utile. Pour un workflow agent, cela signifie des outils plus clairs, des permissions plus propres et moins de détours inutiles.
Un meilleur premier parcours
Si vous voulez tester l’écosystème maintenant, voici le parcours pratique :
1
2
3
4
5
L’assistant obtient ainsi un accès WordPress utile sans que la configuration devienne plus lourde que le travail qu’elle doit économiser.
La suite
Nous continuerons à resserrer ce qui entoure les extensions : onboarding plus clair, meilleures notes de release, liens de pages plus solides et moins d’écart entre GitHub, WordPress et les pages Devenia.
Ce travail n’est pas seulement de la documentation. C’est du design produit pour une pile d’automatisation. Les outils puissants deviennent plus utiles quand chacun voit où commencer et ce qu’il est sûr d’exécuter.
Commencez par MCP Expose Abilities si vous voulez voir la vue d’ensemble actuelle.