Problemet var ikke innstikkene
Innstikkene gjorde nyttig arbeid. Det svake punktet var veien rundt dem.
- Hvilket innstikk bør installeres først?
- Hvilke tillegg er valgfrie?
- Hvilken side har oppdatert utgivelsesinformasjon?
- Hva håndterer kjerneinnstikket, og hva hører hjemme i et tillegg?
- Hvordan ser du at økosystemet fortsatt vedlikeholdes?
Dette er ikke små spørsmål for noen som prøver MCP på et ekte WordPress-nettsted. Hvis oppsettet er uklart, starter den nyttige delen for sent.
Hva vi endret
- Vi ryddet i innstikkssidene på Devenia, slik at kjerneinnstikket og tilleggene forklarer det samme økosystemet konsekvent.
- Vi oppdaterte utdaterte tall, utgivelsesreferanser og lenker som gjorde at eldre sider virket nyere enn hovedsiden.
- Vi bygde om siden for MCP Expose Abilities i vedlikeholdbart Gutenberg-innhold.
- Vi gjorde installasjonsrekkefølgen tydeligere: Abilities API og MCP Adapter først, deretter MCP Expose Abilities, og så bare tilleggene nettstedet faktisk trenger.
- Vi gjorde økosystemet lettere å skanne ved å gruppere tilleggene rundt WordPress-arbeidet de kontrollerer.
Slik opprydding er ikke kosmetikk. Den avgjør om prosjektet føles tilgjengelig, eller som en bunke kraftige verktøy uten tydelig inngang.
Slik ser økosystemet ut nå
Den nåværende siden for MCP Expose Abilities dokumenterer 67 WordPress-native evner i kjerneinnstikket. Den bredere vedlikeholdte stacken består nå av 18 publiserte tillegg og mer enn 450 dokumenterte evner.
Det betyr ikke at alle nettsteder bør installere alt. Poenget er det motsatte. Et GeneratePress-nettsted trenger ikke Elementor-evner. Et nettsted uten Brevo trenger ikke Brevo-evner. En mindre installasjonsflate er lettere å forstå og lettere å holde trygg.
Kjernearbeid i WordPress
Redigering og sidebygging
Drift og integrasjoner
Det er budskapet vi vil gjøre tydeligere: start med kjernen, legg bare til det som passer nettstedet, og hold hver eksponerte operasjon navngitt og mulig å inspisere.
Hvorfor dette betyr noe også utenfor det tekniske
God automatisering starter ikke med den lengste mulige funksjonslisten. Den starter med tillit: kan du forstå hva assistenten får gjøre, hvorfor evnen finnes, og om riktig WordPress-tilgang fortsatt gjelder?
Derfor betyr tilleggsmodellen noe. Den lar et nettsted eksponere et fokusert sett med evner i stedet for å behandle alle WordPress-operasjoner som én stor alt-eller-ingenting-dør.
For en nettstedseier eller utvikler betyr det mindre gjetting før den første nyttige testen. For en agentflyt betyr det tydeligere verktøy, renere tilganger og færre unødvendige omveier.
En bedre første vei
Hvis du vil prøve økosystemet nå, er dette den praktiske veien:
1
2
3
4
5
Da får assistenten nyttig WordPress-tilgang uten at oppsettet blir tyngre enn arbeidet det skal spare.
Hva skjer videre?
Vi fortsetter å stramme opp alt rundt innstikkene: tydeligere onboarding, bedre utgivelsesnotater, sterkere sidelenker og mindre sprik mellom GitHub, WordPress og Devenia-sidene.
Arbeidet er ikke bare dokumentasjon. Det er produktdesign for en automatiseringsstack. Kraftige verktøy blir mer nyttige når folk ser hvor de skal starte og hva som er trygt å kjøre.
Start med MCP Expose Abilities hvis du vil se den oppdaterte oversikten.