WordPress MCP senza plugin: all’agente AI basta la REST API

Nelle ultime settimane ho cercato di capire come funzionano i plugin che promettono di far lavorare un agente AI dentro il tuo sito come se fosse un maggiordomo instancabile, e con Claud.ia li ho analizzati riga per riga, partendo dal concetto di MCP di cui abbiamo parlato nel talk sui pericoli del client AI di WordPress che ho portato al Meetup di Padova.

Ne è uscita la convinzione che sta dietro questo articolo su WordPress MCP: per far fare cose a WordPress da un agente non serve nessun plugin MCP, e chi te lo propone sta cercando di venderti la soluzione a un problema che non esiste, oppure lo sta risolvendo dal lato sbagliato.

Qui ti spiego perché la penso così: che cos’è un server MCP, cosa sa già fare WordPress senza aggiungere nulla, perché un sito in una situazione normale dovrebbe occuparsi solo di gestire i contenuti e perché ogni plugin in più è codice da aggiornare e una porta in più da sorvegliare.

Alla fine ti racconto come lavoro io su questo blog, con la REST API, un’application password e, se serve, un WordPress MCP che gira sul mio computer e non sul server.

Che cos’è un server MCP, in breve

Un server MCP è un traduttore: prende le richieste dell’agente AI e le trasforma in chiamate a un servizio, spiegando al modello quali strumenti ha e come usarli.

Il Model Context Protocol è uno standard aperto che definisce come un’applicazione con un modello linguistico, per esempio Claude Code, scopre e usa degli strumenti esterni. Il server MCP è il pezzo che sta in mezzo: dichiara un elenco di tool, ognuno con un nome, una descrizione per il modello e lo schema dei parametri, e quando l’agente ne chiama uno lo traduce in qualcosa di concreto, che sia una query a un database, una chiamata a un’API o una sequenza di chiamate messe insieme da uno script.

Chi usa già qualche MCP è abituato a scaricarlo e a farlo girare sul proprio computer: io l’ho fatto per il gestionale che usiamo in ufficio, dove il server MCP parla con le API del gestionale e aggiunge un paio di tool che combinano più chiamate in un colpo solo, e un caso simile l’ho raccontato nell’articolo su Blender MCP e la stampa 3D. In questo schema il servizio non sa nemmeno che dall’altra parte c’è un agente, vede solo delle normali chiamate API autenticate, e nessuno si sogna di installare qualcosa sul server del gestionale.

Per questo, quando si parla di WordPress MCP, la prima domanda da farsi è la stessa: se WordPress espone già delle API, perché mai il traduttore dovrebbe vivere dentro il sito? Secondo me non c’è un buon motivo.

WordPress parla già con un agente

WordPress ha già tutto quello che serve a un agente: la REST API per contenuti e media, le application password per autenticarsi e, dalla 6.9, le abilities dei plugin raggiungibili via REST.

La REST API è nel core dal 2016 e copre quasi tutto quello che un agente deve fare su un sito: articoli e pagine, bozze, media con testi alternativi, categorie, tag, commenti, utenti e i meta dei plugin che li espongono. Per autenticarsi bastano le application password, presenti nel core dalla versione 5.6: password dedicate che crei dal profilo di un utente, che valgono solo per le API e che revochi con un clic senza toccare la password vera.

Il pezzo che mancava era un modo per far dire ai plugin cosa sanno fare, e da WordPress 6.9 c’è: è la Abilities API, presentata dal team del core come un registro unico delle capacità del sito. Un plugin registra una ability con un nome, una descrizione comprensibile anche per un modello, lo schema dei dati e una permission_callback, cioè il controllo su chi può usarla.

Il dettaglio che cambia tutto è che le abilities sono già raggiungibili via REST dal core, sotto /wp-json/wp-abilities/v1/, senza nessun plugin aggiuntivo (l’ho verificato sul mio blog). Un agente con un’application password può quindi chiedere al sito «che cosa sai fare?» e ricevere un catalogo sempre aggiornato, con i permessi già decisi da chi ha scritto il plugin.

# le abilities che il sito espone, con descrizione e schema
curl -u agente:"xxxx xxxx xxxx xxxx xxxx xxxx" https://tuosito.it/wp-json/wp-abilities/v1/abilities

# le ultime bozze, con la REST API di sempre
curl -u agente:"xxxx xxxx xxxx xxxx xxxx xxxx" "https://tuosito.it/wp-json/wp/v2/posts?status=draft&per_page=5"

Esiste anche l’MCP Adapter ufficiale, un plugin che crea un WordPress MCP dentro il sito trasformando le abilities in tool, ma a questo punto dovrebbe essere chiaro che non serve neanche lui: le stesse abilities le raggiungi già via REST, e la traduzione in MCP la può fare benissimo un programma sul tuo computer.

Il mestiere di WordPress: i contenuti

In una situazione normale un agente su WordPress deve scrivere, correggere e organizzare contenuti, mentre installare e aggiornare cose, scrivere file e toccare il database sono lavori da sistemista, e non dovrebbero essere delegati a un plugin sul tuo sito.

Prova a fare l’elenco di quello che chiederesti davvero a un agente sul sito di un cliente: preparare una bozza, caricare le immagini con il testo alternativo, sistemare titoli e meta description, controllare i link interni, rispondere a un commento, magari aggiornare un prodotto di WooCommerce. Sono tutte operazioni sui contenuti, e sono esattamente quelle che la REST API e le abilities coprono già, con i permessi di un utente che decidi tu.

Le cose che i plugin MCP più «ambiziosi» aggiungono sono di un’altra natura: installare e aggiornare plugin, modificare i file del tema, lanciare comandi WP-CLI, scrivere nel database, eseguire codice PHP. Sono lavori che secondo me non devono passare da wp-admin: un sistemista li fa con un accesso al server, un repository git, uno staging e un backup, cioè con strumenti che vivono fuori da WordPress e che restano in piedi anche quando WordPress cade.

Il punto, in fondo, è di responsabilità: un CMS deve gestire contenuti, utenti e permessi, e farlo bene, mentre il compito di amministrare il server su cui gira spetta a qualcun altro. Un WordPress MCP installato come plugin che trasforma WordPress nel pannello di controllo del proprio server gli dà un mestiere che non è il suo, e lo fa nel posto più esposto di tutta l’infrastruttura, cioè un indirizzo HTTP pubblico.

Un plugin in più è codice da mantenere

Ogni plugin è codice di terzi che gira con i privilegi del sito: va aggiornato, seguito nelle release di sicurezza e tenuto compatibile, e a volte arriva dentro un altro plugin senza che tu l’abbia scelto.

Chi gestisce siti WordPress lo sa bene: ogni plugin in più è una voce in più nell’elenco degli aggiornamenti, una compatibilità da verificare a ogni versione del core e un autore di cui devi fidarti. Per i plugin che fanno cose utili ai visitatori è un prezzo che si paga volentieri, ma per un plugin di WordPress MCP che serve solo a far parlare l’agente con il sito il conto è difficile da giustificare, visto che la REST API fa già quel lavoro.

Poi c’è il caso più subdolo, che ho scoperto proprio controllando il mio blog: Rank Math incorpora una copia dell’MCP Adapter, alla versione 0.5.0 di aprile, e registra due rotte sotto /wp-json/mcp/, una per il server MCP e una per un server OAuth. Non l’ho mai installato e non l’ho mai chiesto, ma è lì, e risponde su un indirizzo pubblico del mio sito. Rank Math lo fa per offrire le sue abilities agli agenti e non ho motivo di dubitare delle sue intenzioni, però resta un ottimo esempio di codice che non hai scelto.

Il 16 ottobre il progetto ha pubblicato due release di sicurezza, la 0.7.1 e la 0.6.2, invitando ad aggiornare anche le copie incorporate negli altri plugin. Se quel problema tocchi anche la 0.5.0 non lo so, e il punto è proprio questo: non lo decido io, lo decide il ritmo con cui il plugin che la contiene si aggiorna. Esiste anche il server MCP di WordPress.com, che sul tuo server non aggiunge codice MCP, ma per raggiungere un sito self-hosted passa da Jetpack, che non è esattamente un plugin leggero.

Il plugin più sicuro da aggiornare è quello che non hai installato.

La superficie di attacco cresce

Un plugin MCP aggiunge un endpoint pubblico, una credenziale che il sito accetta via HTTP e degli strumenti che l’agente può usare: più potere metti dietro quell’indirizzo, più vale rubarlo o manipolarlo.

La superficie di attacco di un sito è la somma di tutti i punti da cui qualcuno può provare a entrare, e un WordPress MCP installato nel sito ne aggiunge uno nuovo, con una caratteristica particolare: è progettato per ricevere ordini. Se gli strumenti esposti riguardano solo i contenuti, chi ruba la credenziale può fare danni seri ma circoscritti; se tra gli strumenti c’è l’esecuzione di PHP, chiunque abbia il token esegue codice sul tuo server con una semplice richiesta HTTP.

Non serve rubare la chiave SSH dal tuo portatile, basta un file di configurazione dimenticato o un consenso dato di fretta a un client che si presenta con un nome rassicurante. E una volta che si può eseguire PHP, qualunque altra protezione del sito diventa una formalità, compresi i permessi dell’utente che hai creato con tanta cura.

E non dimentichiamoci dei danni causati da una prompt injection…
Un agente che legge un commento, il testo di un ordine o il contenuto di un modulo può trovarci dentro istruzioni scritte apposta per lui, e se tra i suoi strumenti ci sono l’installazione di plugin o l’esecuzione di codice, quelle istruzioni diventano azioni sul server. Con un agente che può solo gestire contenuti, lo stesso attacco produce al massimo una bozza strana da cestinare.

I plugin che partono dal lato sbagliato

I plugin che ho analizzato sono scritti con cura, ma partono entrambi dall’idea che WordPress debba amministrare sé stesso su richiesta dell’agente: è lì che sbagliano strada.

Alcuni dei plugin che offrono un WordPress MCP lo scrivono chiaramente nella documentazione: va usato solo su ambienti di sviluppo e di prova. Il codice è curato, con un’autenticazione seria e qualche paracadute per quando l’agente combina un guaio, ma tra gli strumenti offerti ci sono l’esecuzione di codice PHP arbitrario, WP-CLI con qualunque argomento e la lettura e scrittura dei file del sito. In pratica trasformano WordPress in una shell remota con un’interfaccia gentile.

Altri, più prudenti, non permettono l’esecuzione diretta di PHP e offrono punti di ripristino prima delle modifiche, un registro di cosa è stato fatto e una pagina di emergenza per quando WordPress non parte. Il lavoro che c’è dietro la reversibilità merita rispetto, però spesso le salvaguardie sono conferme che l’agente dà a sé stesso: se il «sì» del proprietario è un parametro che l’agente passa nella sua stessa chiamata, un agente manipolato lo passa senza esitazioni.

E quando tra gli strumenti ci sono la scrittura nel database, la modifica dei file di plugin e temi o l’installazione di un plugin da un archivio ZIP qualunque, l’esecuzione di codice non è più diretta, ma nella pratica non cambia molto.

Molti, insomma, rispondono con grande impegno alla domanda «come faccio a dare all’agente il controllo del server attraverso WordPress?», quando la domanda giusta sarebbe «perché dovrei farlo?».

La risposta è molto semplice: «less is more», cioè nessun plugin in più sul sito, visto che la REST API fa già «quasi» tutto quello che serve.

Le conferme che l’agente può darsi da solo proteggono dall’agente che sbaglia, non dall’agente manipolato.

Quando il sito non risponde più

Se il sito va in errore, un WordPress MCP che lavora dentro il sito cade con lui: il canale per riparare vive nella stessa scatola che si è rotta.

Facciamo un esperimento mentale, lo stesso che propongo spesso a chi mi chiede di questi plugin. L’agente scrive una modifica al tema, installa un plugin o aggiorna una funzione, e qualcosa va storto: errore fatale, pagina bianca, «Si è verificato un errore critico». In quel momento wp-admin non risponde, e non risponde nemmeno l’endpoint MCP del plugin, perché è codice che gira dentro lo stesso WordPress che è appena caduto. L’agente perde le mani esattamente quando ti servirebbero.

Non è vero che non resta nulla: WordPress ha dal 2019 il recovery mode, che in molti casi ti manda un’email con un link per entrare e disattivare il colpevole, e i plugin più seri prevedono una loro modalità di emergenza. Ma sono reti di sicurezza previste da altri, che funzionano se l’errore è del tipo che si aspettavano, se l’email arriva e se la pagina di emergenza non è stata toccata proprio dall’agente.

Con un accesso diretto al server, magari via SSH, invece, il canale di riparazione non dipende da WordPress. Leggi il log degli errori, spegni il plugin colpevole con WP-CLI chiedendogli di non caricare gli altri, rimetti il database salvato prima della sessione o riporti il tema all’ultimo commit buono. Sono quattro comandi da tenere sempre a portata di mano:

tail -n 50 wp-content/debug.log
wp plugin deactivate plugin-difettoso --skip-plugins --skip-themes
wp db import backup-prima-della-sessione.sql
git checkout -- wp-content/themes/mio-tema

È lo stesso principio di tutto l’articolo applicato al momento peggiore: gli strumenti per amministrare il sito devono stare fuori dal sito, nelle mani di chi lo gestisce, e non dentro il CMS che potrebbero dover rimettere in piedi.

Il mio WordPress MCP sta in locale

Gestisco questo blog con Claud.ia senza nessun plugin per l’AI: REST API con un’application password, abilities via REST per l’analisi SEO e, quando serve un’interfaccia più comoda, un MCP che gira sul mio computer.

Questo blog lo gestisco con Claud.ia, la mia versione personalizzata di Claude Code, e sul sito non c’è nessun plugin installato per farla lavorare. Le bozze, le immagini con i loro testi alternativi e i meta SEO passano dalla REST API con un’application password; per controllare un articolo prima di consegnarlo uso le abilities che Rank Math registra sul sito, chiamate anche loro via REST del core. Lo stesso schema lo uso con gli automatismi raccontati nell’articolo su n8n e WordPress, dove a chiamare le API è un workflow invece di un agente.

Oggi Claud.ia usa direttamente dei piccoli script che avvolgono quelle chiamate, e funziona benissimo. Se vuoi un’interfaccia più comoda per l’agente, il passo successivo è un WordPress MCP in locale: un server MCP che gira sul tuo computer, espone qualche tool su misura (crea una bozza, carica un’immagine, imposta i meta) e dietro le quinte chiama la REST API, esattamente come quello che ho scritto per il gestionale dell’ufficio. Il sito non sa nemmeno che esiste.

I vantaggi di un WordPress MCP fatto così si vedono subito: nessun codice in più da aggiornare sul server, nessun nuovo endpoint pubblico e una credenziale che sta sul mio disco e che revoco dal profilo dell’utente in un secondo. Quando invece serve fare il sistemista, lo faccio con un terminale che non dipende da WordPress.

Le regole che seguo (e ti consiglio)

Poche regole pratiche per collegare un agente a WordPress senza consegnargli il server: niente plugin MCP, utente dedicato, credenziali revocabili e backup prima di ogni sessione.

Queste sono le regole che seguo io e che consiglio a chi collega un agente al sito di un cliente, qualunque WordPress MCP tu scelga di usare dal tuo computer:

• Nessun plugin MCP sul sito: l’agente parla con la REST API e con le abilities del core, e l’eventuale server MCP gira sul tuo computer.
• Un utente per l’agente, con il ruolo minimo necessario: Editore se deve scrivere contenuti, mai amministratore per abitudine.
• Un’application password per ogni agente o servizio, così ne chiudi una senza fermare le altre.
• Controlla cosa portano gli altri plugin: apri /wp-json/ e cerca «mcp» nell’elenco dei namespace, potresti avere un endpoint MCP che non hai mai chiesto.
• Abilities con permessi veri: se registri operazioni tue, ogni permission_callback controlla una capability precisa.
• Backup prima della sessione, verificato, e tema e plugin su misura sotto git.
• Il transcript dell’agente conservato sul tuo computer: è il registro più affidabile di cosa è stato fatto.

Se gestisci tanti siti, queste regole si sposano bene con un controllo centralizzato degli aggiornamenti e dello stato, come quello che racconto nell’articolo su Fleet: l’agente lavora sui contenuti del singolo sito, mentre la manutenzione resta un lavoro tuo, fatto da un punto solo.

A ciascuno il suo mestiere

WordPress gestisce i contenuti, l’agente li scrive attraverso le API e il server lo amministri tu: con questa divisione dei compiti un plugin MCP non ha più niente da fare.

Ricapitolando, l’idea che mi porto via da questa analisi è che il problema non sta in MCP, che anzi è uno standard comodo e ben pensato, ma nel metterlo dentro WordPress e nel caricare il CMS di responsabilità che non deve avere. Con la REST API, un’application password, le abilities del core e, se ti piace, un WordPress MCP sul tuo computer, l’agente fa tutto quello che serve sui contenuti, il sito resta leggero e la chiave resta nel tuo cassetto.

Se vuoi approfondire, parti dalla documentazione della Abilities API e dalla guida alle application password, dai un’occhiata alle release dell’MCP Adapter per capire quanto si muove in fretta quel codice e leggi il mio articolo sugli harness per agenti AI, che spiega perché conta tanto l’ambiente in cui l’agente lavora.

Se invece vuoi capire come portare questo modello sul tuo sito, sui siti della tua azienda o dei tuoi clienti, possiamo parlarne in una call conoscitiva.

Adesso, mentre non ti vede nessuno, vai a disinstallare tutti ‘sti plugin inutili e pericolosi e scrivi «fatto» nei commenti, così i mostri di Halloween sanno che non devono venire ad hackerarti il sito.

Domande frequenti su WordPress MCP