TL;DR: MCP rende più semplice far scoprire strumenti e contesto a un agente AI. La REST API resta però il confine più controllabile per pubblicare, aggiornare o cancellare dati in WordPress. Per una PMI sceglierei un’architettura ibrida: MCP per discovery e letture, REST per le scritture validate e approvate.
Il criterio: chi decide e dove vive il contratto
MCP e REST API non sono due versioni dello stesso oggetto. Il Model Context Protocol organizza il rapporto tra un’applicazione AI e i servizi che le forniscono strumenti, risorse e prompt. REST espone invece risorse e operazioni tramite URL, verbi HTTP, codici di stato e JSON.
Il criterio utile per confrontarli è questo: quanto controllo vuoi lasciare all’agente nella scelta dell’azione e quanto vuoi fissare nel codice dell’automazione? Se il sistema deve esplorare capacità diverse durante una conversazione, MCP parte avanti. Se deve eseguire una sequenza ripetibile, come creare una bozza WordPress, caricare un media e attendere un’approvazione, REST è più semplice da limitare e testare.
MCP: discovery nativa per gli agenti
La documentazione MCP del 28 luglio 2026 descrive un’architettura host-client-server basata su JSON-RPC. Un server può esporre tools eseguibili, resources da usare come contesto e prompts riutilizzabili. Il client scopre queste capacità e i relativi schemi prima di invocarle. Un assistente può quindi collegarsi a WordPress, analytics, CRM e documenti senza avere nel prompt una lista statica di endpoint.
Questo è il vantaggio concreto di MCP: riduce il lavoro di integrazione nel livello agentico. I tool hanno input descritti con JSON Schema; la lista può cambiare; l’applicazione può mostrare approvazioni e log delle chiamate. Per un consulente che usa lo stesso agente su siti diversi, la portabilità del contratto vale molto.
Il contro è nello stesso meccanismo. I tool MCP sono scelti dal modello in base al contesto e possono chiamare API, modificare file o scrivere su database. L’approvazione umana non compare per magia: deve essere implementata dall’host. Anche osservabilità, retry e idempotenza dipendono dal server e dall’applicazione che lo usa.
REST API: meno astrazione, più prevedibilità
La REST API di WordPress usa endpoint orientati alle risorse, verbi HTTP e risposte JSON. Un’automazione sa in anticipo che un post passa da /wp/v2/posts, che un media usa /wp/v2/media e che un errore arriva con un codice HTTP. Questa prevedibilità aiuta test, log, alert e procedure di rollback.
REST non è neppure priva di discovery. WordPress espone l’indice API e risponde a OPTIONS con le capacità degli endpoint. La Abilities API aggiunge un livello ancora più vicino agli agenti: sistemi esterni autenticati possono elencare ed eseguire abilità, ma ogni abilità resta nascosta per default finché show_in_rest non viene attivato e l’esecuzione passa da permission_callback().
Il limite di REST è il costo di integrazione. Devi conoscere gli endpoint, gestire versioni e trasformare le risposte nel formato atteso dal modello. Se aggiungi dieci servizi, costruisci dieci adapter. MCP standardizza proprio quel livello.
Sicurezza: il protocollo non sostituisce i permessi
Con WordPress, le Application Passwords sono credenziali revocabili legate a un utente e pensate per accesso programmatico via HTTPS. Vanno create per singola integrazione, conservate come secret e associate a un account con le sole capacità necessarie. Una chiave usata da un flusso editoriale non dovrebbe appartenere a un amministratore se deve soltanto caricare media e gestire post.
MCP aggiunge un altro confine di fiducia. La specifica di autorizzazione tratta OAuth per i trasporti HTTP, mentre i server locali su stdio recuperano normalmente le credenziali dall’ambiente. Le linee guida di sicurezza MCP vietano il token passthrough e richiedono di validare audience e consenso: un proxy mal configurato può confondere identità, log e responsabilità.
Tradotto: mettere REST dietro un server MCP non rende l’operazione più sicura. Aggiunge un livello che può applicare policy, ma che va progettato e verificato.
WordPress e automazioni: come li userei
Per un assistente che analizza contenuti, cerca pagine correlate o prepara un brief, MCP è adatto. Le operazioni sono prevalentemente in lettura, il contesto cambia e la discovery riduce configurazioni rigide.
Per pubblicazione e manutenzione userei invece una pipeline REST esplicita: payload validato, stato iniziale draft, media WebP controllato, gate SEO, approvazione e solo dopo promozione a publish. Lo stesso principio vale per un form, un CRM o un invio email. Il modello propone gli argomenti; il codice decide se l’azione è permessa. Ho applicato lo stesso confine nella guida su come validare un output JSON prima di WordPress.
Un’architettura ibrida può esporre via MCP solo letture e azioni preparatorie. Quando l’agente chiede una scrittura, il server inoltra una richiesta a un servizio REST con allowlist, validazione dello schema, chiave idempotente, audit log e approvazione per le operazioni irreversibili. Non è elegante come una demo in cui l’agente fa tutto. È molto più gestibile quando qualcosa va storto.
La mia take: REST per scrivere, MCP per orientarsi
Per una PMI non sostituirei una REST API funzionante con MCP. Aggiungerei MCP dove esiste un problema reale di discovery tra più strumenti o dove lo stesso servizio deve essere usato da client AI diversi.
La scelta netta è questa: REST deve restare il confine di produzione per ogni scrittura su WordPress, CRM, email e automazioni. MCP può diventare il livello di orientamento dell’agente, con tool stretti e permessi espliciti. Prima si costruisce un flusso deterministico che regge agli errori. Poi si concede flessibilità al modello, una capacità alla volta.