Problemet var inte tilläggen
Tilläggen gjorde nytta. Den svaga punkten var vägen runt dem.
- Vilket tillägg ska installeras först?
- Vilka add-ons är valfria?
- Vilken sida har aktuell versionsinformation?
- Vad hanterar kärntillägget, och vad hör hemma i en add-on?
- Hur ser man att ekosystemet fortfarande underhålls?
Det är inte små frågor för någon som testar MCP på en riktig WordPress-webbplats. Om installationsvägen är otydlig börjar den användbara delen för sent.
Vad vi ändrade
- Vi städade upp tilläggssidorna på Devenia så att kärntillägget och add-ons förklarar samma ekosystem konsekvent.
- Vi uppdaterade gamla siffror, versionsreferenser och länkar som fick äldre sidor att låta nyare än huvudsidan.
- Vi byggde om sidan för MCP Expose Abilities som underhållbart Gutenberg-innehåll.
- Vi gjorde installationsordningen tydligare: Abilities API och MCP Adapter först, sedan MCP Expose Abilities, och därefter bara de add-ons webbplatsen faktiskt behöver.
- Vi gjorde ekosystemet lättare att skanna genom att gruppera add-ons efter det WordPress-arbete de styr.
Den sortens städning är inte kosmetik. Den avgör om projektet känns tillgängligt eller som en hög kraftfulla verktyg utan tydlig ingång.
Så ser ekosystemet ut nu
Den aktuella sidan för MCP Expose Abilities dokumenterar 67 WordPress-native abilities i kärntillägget. Den bredare underhållna stacken omfattar nu 18 släppta add-ons och mer än 450 dokumenterade abilities.
Det betyder inte att varje webbplats ska installera allt. Poängen är motsatsen. En GeneratePress-webbplats behöver inte Elementor-abilities. En webbplats utan Brevo behöver inte Brevo-abilities. En mindre installationsyta är lättare att förstå och lättare att hålla trygg.
Kärnarbete i WordPress
Redigering och sidbygge
Drift och integrationer
Det är budskapet vi vill göra tydligare: börja med kärnan, lägg bara till det som passar webbplatsen och håll varje exponerad operation namngiven och möjlig att granska.
Varför detta spelar roll även utanför det tekniska
Bra automatisering börjar inte med den längsta möjliga funktionslistan. Den börjar med förtroende: går det att förstå vad assistenten får göra, varför den abilityn finns och om rätt WordPress-behörighet fortfarande gäller?
Därför spelar add-on-modellen roll. Den låter en webbplats exponera en fokuserad uppsättning abilities i stället för att behandla alla WordPress-operationer som en enda allt-eller-inget-dörr.
För en webbplatsägare eller utvecklare betyder det mindre gissning före det första användbara testet. För ett agentflöde betyder det tydligare verktyg, renare behörigheter och färre onödiga omvägar.
En bättre första väg
Om du vill testa ekosystemet nu är detta den praktiska vägen:
1
2
3
4
5
Då får assistenten användbar WordPress-åtkomst utan att installationen blir tyngre än arbetet den ska spara.
Vad händer härnäst?
Vi fortsätter att strama upp allt runt tilläggen: tydligare onboarding, bättre versionsanteckningar, starkare sidlänkar och mindre glapp mellan GitHub, WordPress och Devenias sidor.
Arbetet är inte bara dokumentation. Det är produktdesign för en automatiseringsstack. Kraftfulla verktyg blir mer användbara när människor ser var de ska börja och vad som är tryggt att köra.
Börja med MCP Expose Abilities om du vill se den aktuella översikten.