In questo articolo Indice dei contenuti 2 sezioni
Con MCP Adapter, il pacchetto ufficiale dedicato all’integrazione del Model Context Protocol, WordPress apre le proprie funzioni agli agenti AI. Un assistente collegato a un sito non deve più limitarsi a leggere pagine o suggerire qualche testo. Almeno in teoria può interrogare le funzioni del CMS, capire quali operazioni ha a disposizione, recuperare dati strutturati, creare contenuti, modificare impostazioni o far partire automazioni. Le funzionalità della piattaforma diventano così capacità descrivibili e utilizzabili da software esterni, senza costringere ogni sviluppatore a scrivere API specifiche per Claude, ChatGPT, Cursor, Visual Studio Code o altri strumenti.
Il problema che il progetto vuole risolvere si capisce bene pensando a un plugin capace di creare una bozza, leggere una configurazione o analizzare i contenuti già pubblicati. La logica PHP esiste, ma un agente esterno non la conosce e non sa come eseguirla. Lo sviluppatore dovrebbe allora preparare un endpoint REST apposito, definirne l’autenticazione, documentare input e output e ripetere il lavoro per ogni client AI. Qui entra in gioco la Abilities API di WordPress, che descrive cosa il CMS sa fare, mentre MCP offre al client l’interfaccia per individuare e usare quelle abilità. I tool rappresentano operazioni richiamabili come pubblicare un articolo, recuperare statistiche o cambiare impostazioni. Le resource sono informazioni che il modello può leggere, ad esempio la configurazione del sito o un report, e i prompt sono modelli di istruzioni riutilizzabili.
Permessi, controlli e nessuna esposizione automatica
Aprire funzioni del sito a programmi esterni pone subito una questione di sicurezza. Per questo il progetto segue un modello ad adesione esplicita e un’Ability non compare da sola sul server MCP. Lo sviluppatore deve indicare meta.public = true, oppure meta.mcp.public = true se vuole renderla accessibile soltanto tramite MCP. Al contrario, un’Ability pubblica per altri canali può essere esclusa impostando meta.mcp.public = false. Una granularità utile, visto che almeno fino a WordPress 7.0 compreso il legame tra meta.public e l’esposizione REST non coincide del tutto con quello MCP.
Va chiarito poi che pubblica non vuol dire eseguibile da chiunque. Ogni Ability conserva il proprio permissioncallback, quindi una funzione che modifica gli articoli può verificare currentusercan(‘editposts’) o currentusercan(‘publishposts’), mentre una funzione amministrativa può richiedere manageoptions. A questo si somma un controllo a livello di trasporto sul server MCP stesso, che di default usa isuserlogged_in() ma può essere sostituito con una callback personalizzata basata su ruoli, capacità, chiavi API o altre condizioni.
Installare il plugin, insomma, non consegna il sito a un modello linguistico. Non configura un provider AI, non dà poteri amministrativi a ChatGPT e non rende pubbliche tutte le funzioni PHP presenti. Serve una catena precisa: l’Ability deve esistere ed essere disponibile per MCP, il server deve accettare la richiesta, il client deve autenticarsi quando previsto e il controllo dei permessi deve autorizzare l’utente corrente. Infine l’agente deve richiamare quel tool con argomenti conformi allo schema. Molto dipenderà dagli sviluppatori dei plugin, perché callback troppo permissive su funzioni potenti resterebbero pericolose anche con un adattatore impeccabile.
HTTP o STDIO e l’uso oltre i chatbot
La scelta tra le due modalità di collegamento dipende da dove si trova WordPress rispetto al client. Se il sito gira su un hosting remoto o su un’altra macchina, MCP Adapter usa HTTP ed espone un endpoint del server MCP dentro la REST API, all’interno del percorso wp-json. Il client invia lì le richieste, WordPress le autentica e l’adattatore traduce i messaggi nelle Abilities disponibili. Con STDIO invece non esistono URL né server Web da contattare. Il client avvia un processo locale e dialoga attraverso stdin e stdout, scambiando messaggi JSON RPC 2.0. Strumenti come Cursor o Claude Code possono lanciare la riga di comando di WordPress, collegarla a un’installazione locale e usare quella sessione come server MCP, senza aprire porte TCP né pubblicare nulla in rete.
La parte forse più interessante però riguarda la standardizzazione delle funzioni. Un’Ability ben definita può servire al codice PHP, alla REST API quando prevista, al JavaScript lato client e agli strumenti MCP. Operazioni come ottenere lo stato SEO di un articolo, svuotare la cache, creare una bozza, elencare i prodotti sotto scorta o recuperare gli errori dell’ultima elaborazione potrebbero diventare richiamabili da automazioni e agenti. Finora un’integrazione avanzata richiedeva di conoscere endpoint, parametri e logica di ogni plugin, mentre ora un agente può prima chiedere quali operazioni esistono e poi scegliere quella adatta. Prende forma così un nuovo livello di interazione, parallelo all’interfaccia e alle API tradizionali, e MCP Adapter è il componente che lo rende accessibile agli agenti compatibili con uno standard ormai supportato da numerosi strumenti di sviluppo e assistenti AI.
Fonte: TecnoAndroid
