Das Problem waren nicht die Plugins
Die Plugins haben sinnvolle Arbeit geleistet. Schwach war der Weg drumherum.
- Welches Plugin sollte zuerst installiert werden?
- Welche Add-ons sind optional?
- Welche Seite enthält die aktuelle Release-Information?
- Was übernimmt das Core-Plugin, und was gehört in ein Add-on?
- Woran erkennt man, dass das Ökosystem weiter gepflegt wird?
Das sind keine kleinen Fragen, wenn jemand MCP auf einer echten WordPress-Website testet. Wenn der Einrichtungsweg unklar ist, beginnt der nützliche Teil zu spät.
Was wir geändert haben
- Wir haben die Plugin-Seiten auf Devenia aufgeräumt, damit Core-Plugin und Add-ons dasselbe Ökosystem einheitlich erklären.
- Wir haben veraltete Zahlen, Release-Hinweise und Links aktualisiert, durch die ältere Seiten neuer wirkten als die Hauptseite.
- Wir haben die Seite MCP Expose Abilities als wartbaren Gutenberg-Inhalt neu aufgebaut.
- Wir haben die Installationsreihenfolge klarer gemacht: zuerst Abilities API und MCP Adapter, dann MCP Expose Abilities, danach nur die Add-ons, die die Website wirklich braucht.
- Wir haben das Ökosystem leichter scanbar gemacht, indem Add-ons nach der WordPress-Arbeit gruppiert werden, die sie steuern.
Diese Art von Aufräumen ist nicht kosmetisch. Sie entscheidet, ob ein Projekt zugänglich wirkt oder wie ein Stapel mächtiger Werkzeuge ohne klaren Einstieg.
So sieht das Ökosystem jetzt aus
Die aktuelle Seite zu MCP Expose Abilities dokumentiert 67 WordPress-native Abilities im Core-Plugin. Der breitere gepflegte Stack umfasst inzwischen 18 veröffentlichte Add-ons und mehr als 450 dokumentierte Abilities.
Das bedeutet nicht, dass jede Website alles installieren sollte. Das Gegenteil ist der Punkt. Eine GeneratePress-Website braucht keine Elementor-Abilities. Eine Website ohne Brevo braucht keine Brevo-Abilities. Eine kleinere Installationsfläche ist leichter zu verstehen und sicherer zu betreiben.
WordPress-Core-Arbeit
Editor- und Builder-Arbeit
Betrieb und Integrationen
Das ist die klarere Botschaft: mit dem Core beginnen, nur das hinzufügen, was zur Website passt, und jede freigegebene Operation benannt und prüfbar halten.
Warum das auch jenseits der Technik wichtig ist
Gute Automatisierung beginnt nicht mit der längstmöglichen Funktionsliste. Sie beginnt mit Vertrauen: Kann man verstehen, was der Assistent tun darf, warum diese Ability existiert und ob weiterhin die richtige WordPress-Berechtigung gilt?
Deshalb ist das Add-on-Modell wichtig. Eine Website kann einen fokussierten Satz an Abilities freigeben, statt alle WordPress-Operationen wie eine einzige Alles-oder-nichts-Tür zu behandeln.
Für Website-Betreiber oder Entwickler bedeutet das weniger Raten vor dem ersten nützlichen Test. Für einen Agent-Workflow bedeutet es klarere Werkzeuge, sauberere Berechtigungen und weniger unnötige Umwege.
Ein besserer erster Weg
Wenn Sie das Ökosystem jetzt testen möchten, ist das der praktische Weg:
1
2
3
4
5
So bekommt der Assistent nützlichen WordPress-Zugriff, ohne dass die Einrichtung schwerer wird als die Arbeit, die sie sparen soll.
Was als Nächstes kommt
Wir werden die Teile rund um die Plugins weiter straffen: klareres Onboarding, bessere Release Notes, stärkere Seitenverlinkung und weniger Drift zwischen GitHub, WordPress und Devenia-Seiten.
Diese Arbeit ist nicht nur Dokumentation. Sie ist Produktdesign für einen Automatisierungs-Stack. Mächtige Werkzeuge werden nützlicher, wenn Menschen erkennen, wo sie anfangen und was sicher auszuführen ist.
Beginnen Sie mit MCP Expose Abilities, wenn Sie die aktuelle Übersicht sehen möchten.