Il problema non erano i plugin
I plugin facevano già un lavoro utile. Il punto debole era il percorso attorno a loro.
- Quale plugin va installato per primo?
- Quali add-on sono opzionali?
- Quale pagina contiene le informazioni di release aggiornate?
- Cosa gestisce il plugin core, e cosa appartiene a un add-on?
- Come si capisce che l’ecosistema è ancora mantenuto?
Non sono domande piccole per chi prova MCP su un sito WordPress reale. Se il percorso di configurazione è poco chiaro, la parte utile arriva troppo tardi.
Che cosa abbiamo cambiato
- Abbiamo ripulito le pagine dei plugin Devenia, così il plugin core e gli add-on spiegano lo stesso ecosistema in modo coerente.
- Abbiamo aggiornato conteggi, riferimenti di release e link obsoleti che facevano sembrare alcune pagine più nuove della pagina principale del plugin.
- Abbiamo ricostruito la pagina MCP Expose Abilities in contenuto Gutenberg manutenibile.
- Abbiamo chiarito il percorso di installazione: prima Abilities API e MCP Adapter, poi MCP Expose Abilities, quindi solo gli add-on di cui il sito ha davvero bisogno.
- Abbiamo reso l’ecosistema più facile da scorrere, raggruppando gli add-on in base al lavoro WordPress che controllano.
Questo tipo di pulizia non è estetica. Cambia la sensazione del progetto: da una pila di strumenti potenti senza ingresso evidente a un sistema più facile da iniziare a usare.
La forma attuale dell’ecosistema
La pagina attuale di MCP Expose Abilities documenta 67 abilità WordPress native nel plugin core. Lo stack mantenuto nel suo insieme comprende ora 18 add-on rilasciati e più di 450 abilità documentate.
Questo non significa che ogni sito debba installare tutto. Il punto è l’opposto. Un sito GeneratePress non ha bisogno delle abilità Elementor. Un sito senza Brevo non ha bisogno delle abilità Brevo. Una superficie di installazione piccola è più facile da capire e da mantenere sicura.
Lavoro WordPress core
Lavoro su editor e builder
Lavoro operativo
Questo è il messaggio più chiaro che vogliamo far vedere: partire dal core, aggiungere solo ciò che corrisponde allo stack del sito e mantenere ogni operazione esposta nominata e ispezionabile.
Perché conta anche fuori dai dettagli tecnici
Una buona automazione non parte dall’elenco di funzioni più lungo possibile. Parte dalla fiducia: si capisce cosa l’assistente è autorizzato a fare, perché quell’abilità esiste e se il permesso WordPress giusto continua ad applicarsi?
Per questo il modello ad add-on conta. Permette a un sito di esporre un insieme mirato di abilità invece di trattare ogni operazione WordPress come un’unica porta tutto-o-niente.
Per chi possiede o sviluppa un sito, significa meno tentativi prima del primo test utile. Per un flusso con agenti, significa strumenti più chiari, permessi più puliti e meno deviazioni accidentali.
Un primo percorso migliore
Se provi l’ecosistema ora, il percorso pratico è questo:
1
2
3
4
5
Così l’assistente ottiene un accesso WordPress utile senza rendere la configurazione più difficile del lavoro che dovrebbe risparmiare.
Che cosa viene dopo
Continueremo a stringere le parti attorno ai plugin: onboarding più chiaro, note di release migliori, link di pagina più forti e meno deriva tra GitHub, WordPress e le pagine Devenia.
Il lavoro non è solo documentazione. È progettazione di prodotto per uno stack di automazione. Gli strumenti potenti diventano più utili quando le persone capiscono da dove partire e cosa è sicuro eseguire.
Inizia da MCP Expose Abilities se vuoi la panoramica aggiornata.