WordPress apre le sue funzioni agli agenti AI con MCP Adapter

Un agente AI capace di lavorare con un sito Web non deve limitarsi a leggere pagine o suggerire testi. Può, almeno in teoria, interrogare funzioni disponibili nel CMS, capire quali operazioni può eseguire, recuperare dati strutturati, creare contenuti, modificare impostazioni o avviare automazioni. Il Model Context Protocol (MCP) apre possibilità interessanti anche per WordPress: diventa possibile trasformare le funzionalità del CMS in capacità descrivibili e utilizzabili da software esterni.

Anziché costringere ogni sviluppatore a creare API specifiche per Claude, ChatGPT, Cursor, Visual Studio Code o altri strumenti, WordPress può esporre le proprie capacità usando proprio MCP.

Perché WordPress ha bisogno di MCP Adapter

Il problema che il pacchetto ufficiale WordPress per l’integrazione di MCP, MCP Adapter, cerca di risolvere diventa evidente immaginando un plugin che sappia, per esempio, creare una bozza, leggere una configurazione oppure analizzare i contenuti pubblicati.

La logica PHP esiste già, ma un agente esterno non conosce quella funzione e non sa come eseguirla. Lo sviluppatore potrebbe creare un endpoint REST dedicato, definirne l’autenticazione, documentare input e output e scrivere una seconda integrazione per ogni client AI.

La Abilities API di WordPress descrivono che cosa il CMS sa fare; MCP fornisce l’interfaccia per un client AI affinché possa individuare e usare quelle abilità.

I tool MCP rappresentano operazioni richiamabili: pubblicare un articolo, recuperare statistiche, rigenerare dati, modificare impostazioni. Le resource forniscono invece informazioni che un modello può leggere; un esempio potrebbe essere la configurazione del sito o un report. I prompt rappresentano modelli di istruzioni riutilizzabili dal client.

Le Abilities non diventano automaticamente accessibili all’AI

Esporre funzioni di WordPress a software esterni solleva immediatamente un problema di sicurezza. Il progetto MCP Adapter adotta per questo un modello opt-in: un’Ability non appare automaticamente sul server MCP: lo sviluppatore deve indicare esplicitamente meta.public = true, oppure utilizzare meta.mcp.public = true quando vuole renderla accessibile soltanto tramite MCP.

Un’Ability resa pubblica per altri canali può essere esclusa da MCP impostando meta.mcp.public = false.

La granularità è utile perché, almeno fino a WordPress 7.0 compreso, la relazione tra meta.public e l’esposizione REST non coincide completamente con quella MCP.

Va detto, inoltre, che “pubblica” non significa “eseguibile da chiunque“: ogni Ability mantiene il proprio permission_callback. Una funzione che modifica gli articoli può quindi verificare current_user_can('edit_posts') oppure current_user_can('publish_posts'); una funzione amministrativa può richiedere manage_options.

MCP Adapter aggiunge un’altra barriera: il server MCP stesso possiede un controllo di accesso a livello di trasporto: di default usa is_user_logged_in(), ma lo sviluppatore può sostituirlo con una callback personalizzata e verificare ruoli, capacità di WordPress, chiavi API o altre condizioni.

HTTP oppure STDIO: due modi molto diversi di collegare l’agente

Per capire la differenza tra HTTP e STDIO conviene partire da una domanda molto semplice: dove si trova WordPress rispetto al client MCP?

Se il sito gira su un server remoto, per esempio su un normale hosting, il client deve raggiungerlo attraverso la rete; se invece WordPress gira sulla stessa macchina dello sviluppatore, si può evitare del tutto la comunicazione HTTP e far dialogare direttamente i due processi.

Nel primo caso MCP Adapter usa HTTP. Il plugin espone un endpoint del server MCP all’interno della REST API di WordPress e il client invia lì le proprie richieste. Il percorso è simile a quello di una normale integrazione Web: il software che usa MCP apre una connessione verso il sito, invia il comando e riceve la risposta. È la soluzione naturale quando WordPress si trova su Internet oppure su una macchina diversa da quella sulla quale gira il client AI.

Immaginiamo, per esempio, un sito raggiungibile come https://example.com. MCP Adapter può esporre il proprio server attraverso un indirizzo del tipo https://example.com/wp-json/mcp/mcp-adapter-default-server. Il client MCP comunica con quell’URL, WordPress autentica la richiesta e l’adapter traduce i messaggi MCP nelle Abilities disponibili sul sito.

La modalità STDIO segue invece una logica diversa. Non c’è un server Web da contattare e non c’è un URL. Il client avvia direttamente un processo locale e gli parla attraverso i suoi canali standard di input e output, cioè stdin e stdout. MCP usa in questo caso messaggi JSON-RPC 2.0 che viaggiano avanti e indietro tra i due processi.

Con MCP Adapter il processo può essere avviato tramite wp mcp-adapter serve. Significa che un programma come Cursor o Claude Code può lanciare WP-CLI, collegarlo a una determinata installazione WordPress locale e usare quella sessione come server MCP. Non serve aprire una porta TCP e non serve pubblicare un endpoint sulla rete: il client parla direttamente con il processo wp che sta girando sullo stesso computer.

Non è un pulsante per consegnare WordPress all’intelligenza artificiale

Installare il plugin MCP Adapter non significa permettere automaticamente a un modello linguistico di amministrare il sito. Non configura da solo un provider AI, non assegna poteri amministrativi a ChatGPT e non rende pubbliche tutte le funzioni PHP presenti nell’installazione.

Perché un agente possa eseguire qualcosa servono diversi passaggi: deve esistere una Ability, l’Ability deve essere resa disponibile a MCP, il server deve accettare la richiesta, il client deve autenticarsi quando previsto e il controllo dei permessi della singola funzione deve autorizzare l’utente corrente. Infine, naturalmente, l’agente deve decidere di richiamare quel tool con argomenti conformi allo schema.

Proprio per questo la qualità dell’integrazione dipenderà molto dagli sviluppatori dei plugin. Esporre indiscriminatamente funzioni potenti con callback dei permessi troppo permissive sarebbe pericoloso anche se MCP Adapter funzionasse perfettamente.

Al contrario, Abilities molto granulari, con schemi precisi e capability WordPress appropriate, permettono di mantenere una superficie operativa più controllabile.

Perché MCP Adapter può diventare importante anche oltre l’AI

È facile leggere MCP Adapter esclusivamente come un ponte verso i chatbot, ma la parte più interessante potrebbe essere la standardizzazione delle funzioni di WordPress.

Un’Ability ben definita non nasce necessariamente per un modello generativo: può essere utilizzata dal codice PHP, dalla REST API quando prevista, dal JavaScript lato client e, tramite l’adapter, da strumenti MCP.

Funzioni quali “ottieni lo stato SEO dell’articolo“, “svuota questa cache“, “crea una bozza“, “elenca i prodotti sotto scorta” oppure “recupera gli errori dell’ultima elaborazione” potrebbero diventare richiamabili anche da automazioni e agenti.

Fino a ieri un’integrazione WordPress avanzata richiedeva quasi sempre che qualcuno conoscesse gli endpoint REST, i parametri e la logica specifica del plugin. Con le Abilities e MCP, un agente può prima chiedere quali operazioni sono disponibili e successivamente scegliere quella adatta a ciascuna attività.

Sta insomma delineandosi all’orizzonte un nuovo livello di interazione, parallelo alla UI e alle API tradizionali: MCP Adapter è il componente che rende tale livello accessibile agli agenti compatibili con uno standard che ormai supportano numerosi strumenti di sviluppo e assistenti AI.