Het probleem zat niet in de plugins
De plugins deden nuttig werk. Het zwakke punt was de route eromheen.
- Welke plugin moet eerst worden geïnstalleerd?
- Welke add-ons zijn optioneel?
- Welke pagina heeft de actuele release-informatie?
- Wat doet de core-plugin, en wat hoort in een add-on?
- Hoe weet je dat het ecosysteem nog wordt onderhouden?
Dat zijn geen kleine vragen voor iemand die MCP op een echte WordPress-site probeert. Als de installatieroute onduidelijk is, begint het nuttige deel te laat.
Wat we hebben veranderd
- We hebben de Devenia-pluginpagina’s opgeschoond, zodat de core-plugin en add-ons hetzelfde ecosysteem consequent uitleggen.
- We hebben verouderde aantallen, releaseverwijzingen en links bijgewerkt die oudere pagina’s nieuwer lieten klinken dan de hoofdpluginpagina.
- We hebben de pagina MCP Expose Abilities opnieuw opgebouwd als onderhoudbare Gutenberg-content.
- We hebben het installatiepad duidelijker gemaakt: eerst Abilities API en MCP Adapter, daarna MCP Expose Abilities, en vervolgens alleen de add-ons die de site echt nodig heeft.
- We hebben het ecosysteem beter scanbaar gemaakt door add-ons te groeperen rond het WordPress-werk dat ze aansturen.
Dat soort opruimwerk is niet cosmetisch. Het bepaalt of het project benaderbaar voelt, of als een stapel krachtige tools zonder duidelijke ingang.
De huidige vorm van het ecosysteem
De huidige pagina van MCP Expose Abilities documenteert 67 WordPress-native abilities in de core-plugin. De bredere onderhouden stack omvat nu 18 uitgebrachte add-ons en meer dan 450 gedocumenteerde abilities.
Dat betekent niet dat elke site alles moet installeren. Het punt is juist het tegenovergestelde. Een GeneratePress-site heeft geen Elementor-abilities nodig. Een site zonder Brevo heeft geen Brevo-abilities nodig. Een kleiner installatieoppervlak is makkelijker te begrijpen en veiliger te houden.
Core WordPress-werk
Editor- en builderwerk
Operationeel werk
Dat is de duidelijkere boodschap die we willen laten zien: begin met de core, voeg alleen toe wat bij de site past en houd elke vrijgegeven handeling benoemd en controleerbaar.
Waarom dit ook buiten de techniek telt
Goede automatisering begint niet met de langst mogelijke functielijst. Ze begint met vertrouwen: begrijp je wat de assistent mag doen, waarom die ability bestaat en of de juiste WordPress-rechten nog steeds gelden?
Daarom is het add-onmodel belangrijk. Het laat een site een gerichte set abilities beschikbaar maken, in plaats van elke WordPress-handeling te behandelen als één grote alles-of-nietsdeur.
Voor een site-eigenaar of ontwikkelaar betekent dat minder giswerk vóór de eerste nuttige test. Voor een agentworkflow betekent het duidelijkere tools, schonere rechten en minder toevallige omwegen.
Een betere eerste route
Als je het ecosysteem nu probeert, is dit de praktische route:
1
2
3
4
5
Zo krijgt de assistent nuttige WordPress-toegang zonder dat de configuratie moeilijker wordt dan het werk dat ze moet besparen.
Wat hierna komt
We blijven de onderdelen rond de plugins aanscherpen: duidelijkere onboarding, betere releasenotes, sterkere paginalinks en minder verschil tussen GitHub, WordPress en de Devenia-pagina’s.
Het werk is niet alleen documentatie. Het is productontwerp voor een automatiseringsstack. Krachtige tools worden nuttiger wanneer mensen zien waar ze moeten beginnen en wat veilig is om uit te voeren.
Begin met MCP Expose Abilities als je het actuele overzicht wilt.
