Problemet var ikke pluginsene
Pluginsene gjorde nyttigt arbejde. Det svage punkt var vejen rundt om dem.
- Hvilket plugin skal installeres først?
- Hvilke add-ons er valgfrie?
- Hvilken side har den aktuelle udgivelsesinformation?
- Hvad håndterer kernepluginet, og hvad hører hjemme i en add-on?
- Hvordan ser man, at økosystemet stadig bliver vedligeholdt?
Det er ikke små spørgsmål for nogen, der prøver MCP på et rigtigt WordPress-site. Hvis opsætningsvejen er uklar, starter den nyttige del for sent.
Hvad vi ændrede
- Vi ryddede op på plugin-siderne hos Devenia, så kernepluginet og add-ons forklarer det samme økosystem konsekvent.
- Vi opdaterede forældede tal, udgivelsesreferencer og links, der fik ældre sider til at lyde nyere end hovedsiden.
- Vi byggede siden for MCP Expose Abilities om som vedligeholdbart Gutenberg-indhold.
- Vi gjorde installationsrækkefølgen tydeligere: Abilities API og MCP Adapter først, derefter MCP Expose Abilities og så kun de add-ons, sitet faktisk har brug for.
- Vi gjorde økosystemet lettere at skimme ved at gruppere add-ons efter det WordPress-arbejde, de styrer.
Den slags oprydning er ikke kosmetik. Den afgør, om projektet føles tilgængeligt eller som en bunke stærke værktøjer uden tydelig indgang.
Sådan ser økosystemet ud nu
Den aktuelle side for MCP Expose Abilities dokumenterer 67 WordPress-native abilities i kernepluginet. Den bredere vedligeholdte stack består nu af 18 udgivne add-ons og mere end 450 dokumenterede abilities.
Det betyder ikke, at alle sites bør installere alt. Pointen er det modsatte. Et GeneratePress-site har ikke brug for Elementor-abilities. Et site uden Brevo har ikke brug for Brevo-abilities. En mindre installationsflade er lettere at forstå og lettere at holde sikker.
Kernearbejde i WordPress
Redigering og sidebygning
Drift og integrationer
Det er det tydeligere budskab: start med kernen, tilføj kun det, der passer til sitet, og hold hver eksponeret operation navngivet og mulig at inspicere.
Hvorfor det betyder noget uden for det tekniske
God automatisering begynder ikke med den længst mulige funktionsliste. Den begynder med tillid: kan man forstå, hvad assistenten må gøre, hvorfor den ability findes, og om den rigtige WordPress-tilladelse stadig gælder?
Derfor betyder add-on-modellen noget. Den lader et site eksponere et fokuseret sæt abilities i stedet for at behandle alle WordPress-operationer som én stor alt-eller-intet-dør.
For en siteejer eller udvikler betyder det mindre gætteri før den første nyttige test. For et agentflow betyder det tydeligere værktøjer, renere tilladelser og færre unødvendige omveje.
En bedre første vej
Hvis du vil prøve økosystemet nu, er dette den praktiske vej:
1
2
3
4
5
Så får assistenten nyttig WordPress-adgang, uden at opsætningen bliver tungere end det arbejde, den skal spare.
Hvad sker der nu?
Vi fortsætter med at stramme alt omkring pluginsene op: tydeligere onboarding, bedre udgivelsesnoter, stærkere sidelinks og mindre forskydning mellem GitHub, WordPress og Devenia-siderne.
Arbejdet er ikke kun dokumentation. Det er produktdesign for en automatiseringsstack. Stærke værktøjer bliver mere nyttige, når folk kan se, hvor de skal starte, og hvad der er sikkert at køre.
Start med MCP Expose Abilities, hvis du vil se den aktuelle oversigt.