Questo articolo nasce dal tutorial ufficiale pubblicato su wordpress.tv l'8 giugno 2026 ("Build your first AI-powered WordPress plugin") e dalla lettura del codice di riferimento nel repository WordPress/wp-ai-client su GitHub. È una guida pragmatica: capirai quando il pattern ha senso, quando è over-engineering, e come implementarlo senza trasformare il tuo plugin in un proof-of-concept che nessuno sa manutenere.

Cos'è il pattern abilities + MCP + WP AI Client

Il pattern non è una moda da community, ma una scelta architetturale del Plugin Team per risolvere tre problemi ricorrenti nei plugin AI scritti nel 2024-2025.

I tre problemi che il pattern risolve

1. Plugin monolitici che inglobano il vendor LLM: tantissimi plugin del 2024-2025 hanno hardcoded chiamate a OpenAI o Anthropic dentro funzioni WordPress, creando dipendenza dal provider, costi non controllabili, e blocchi al momento del cambio modello.
2. Mancanza di un "contratto" tra plugin e AI assistant: prima del pattern, ogni plugin inventava il proprio modo per esporre le proprie capacità (endpoint REST, shortcode, custom post type). Risultato: l'AI assistant non sa mai cosa può fare davvero su quel sito.
3. Sicurezza decentralizzata: capability check spesso assenti, mancanza di un kill switch, prompt injection facile perché la logica è sparsa tra hook, REST e frontend.

Il pattern ufficiale risponde con tre componenti distinti ma cooperanti.

Le tre componenti in sintesi

• Abilities API (inclusa nel core da WP 6.9, matura in WP 7.0): un modo standard per dichiarare cosa sa fare il tuo plugin. Ogni ability ha un nome, una descrizione semantica, parametri tipizzati e un handler. È il "contratto".
• Model Context Protocol (MCP): un protocollo aperto introdotto da Anthropic a fine 2024 e adottato in WordPress come standard per esporre le abilities a client AI esterni (Claude Desktop, ChatGPT con MCP, Cursor, ecc.). Il plugin pubblica un server MCP; l'AI client lo scopre e lo consuma.
• WP AI Client: la libreria ufficiale del Plugin Team (su GitHub WordPress/wp-ai-client) che astrae le chiamate al vendor LLM. Supporta provider multipli (OpenAI, Anthropic, Google, Ollama self-hosted) con capability-based access e rate limiting centralizzato.

Insieme formano una pipeline: il plugin dichiara le proprie abilities → le espone via MCP agli AI assistant → usa WP AI Client per le chiamate al modello, senza mai hardcodare il vendor.

Quando adottare il pattern (e quando evitarlo)

Non tutti i plugin AI devono adottare questo stack. Facciamo chiarezza con un test a tre domande che uso in agenzia prima di approvare un nuovo progetto plugin.

Test delle tre domande

Adotta il pattern se rispondi sì ad almeno due di queste:

1. Il plugin interagisce con un AI assistant esterno (Claude Desktop, ChatGPT MCP, agent custom)?
2. Prevedi di supportare più provider LMO (OpenAI, Anthropic, Ollama, self-hosted) o di poter cambiare provider in futuro senza riscrivere il plugin?
3. Il plugin deve rispettare policy di sicurezza enterprise (capability check, audit log, kill switch)?

Se rispondi no a due su tre, stai over-engineering. Un plugin AI semplice - ad esempio uno che genera excerpt automaticamente - può usare direttamente WP AI Client saltando abilities e MCP, oppure restare su wp_remote_post() per una singola API key fissa.

Profili tipici di adozione

• Agenzia che sviluppa per clienti enterprise: pattern obbligatorio. Compliance, audit e portabilità tra provider sono requisiti di contratto.
• Freelance con 5-10 clienti piccoli: pattern consigliato. Il costo di setup si ammortizza in 2-3 progetti e la manutenzione è più semplice.
• Hobbista con un solo progetto: pattern eccessivo. Meglio una funzione custom in functions.php.
• Plugin commerciale in vendita su .org: pattern raccomandato dal Plugin Team. La review del 2026 premia i plugin che adottano standard aperti.

Anatomia di un'ability WordPress

Un'ability è un'unità dichiarativa: nome, descrizione, parametri, handler. Vediamo l'implementazione minima tratta dal tutorial wordpress.tv.

Registrare un'ability

add_action( 'abilities_api_init', 'mia_registra_ability_post_summary' );
function mia_registra_ability_post_summary() {
    wp_register_ability( 'content/summarize-post', array(
        'label'       => __( 'Riassumi post WordPress', 'mio-plugin' ),
        'description' => __( 'Genera un riassunto di 60 parole di un post pubblicato.', 'mio-plugin' ),
        'category'    => 'content',
        'input_schema' => array(
            'type' => 'object',
            'properties' => array(
                'post_id' => array( 'type' => 'integer', 'minimum' => 1 ),
                'max_words' => array( 'type' => 'integer', 'default' => 60 ),
            ),
            'required' => array( 'post_id' ),
        ),
        'output_schema' => array(
            'type' => 'object',
            'properties' => array(
                'summary' => array( 'type' => 'string' ),
                'tokens_used' => array( 'type' => 'integer' ),
            ),
        ),
        'permission_callback' => function ( $input ) {
            return current_user_can( 'edit_post', $input['post_id'] );
        },
        'execute_callback' => 'mia_execute_summarize_post',
    ) );
}

Tre dettagli che fanno la differenza rispetto a un custom endpoint REST: la description è leggibile dall'AI assistant (è il campo che popola la MCP tool list), input_schema e output_schema rendono l'ability validabile senza scrivere validator custom, e permission_callback è valutato prima dell'esecuzione. Niente più capability check duplicati in cinque punti del codice.

L'handler: cosa non fare

function mia_execute_summarize_post( $input ) {
    $post = get_post( $input['post_id'] );
    if ( ! $post ) {
        return new WP_Error( 'post_not_found', __( 'Post non trovato.', 'mio-plugin' ) );
    }
    // delega al client AI, non alla chiamata vendor
    $client = wp_ai_client();
    $response = $client->generate_text( array(
        'model' => 'auto',
        'system' => 'Sei un editor tecnico che riassume in italiano corretto.',
        'prompt' => wp_strip_all_tags( $post->post_content ),
        'max_tokens' => (int) ( $input['max_words'] * 1.5 ),
    ) );
    if ( is_wp_error( $response ) ) {
        return $response;
    }
    return array(
        'summary' => $response['text'],
        'tokens_used' => $response['usage']['total_tokens'] ?? 0,
    );
}

Nota: nessuna API key nel codice, nessuna chiamata diretta a un endpoint vendor. wp_ai_client() è la factory ufficiale introdotta dal Plugin Team, e l'argomento model => 'auto' lascia al client la scelta del modello in base a policy, costo e disponibilità. Questo è il punto: cambiare provider significa cambiare una costante di config, non riscrivere l'handler.

Esposizione MCP: dal plugin al desktop AI

Una volta registrate le abilities, esporle via MCP richiede il secondo mattoncino. Il Plugin Team mantiene un adapter (wp-abilities-mcp-adapter) che pubblica le abilities come MCP tools.

Setup dell'adapter MCP

add_action( 'mcp_adapter_init', 'mia_registra_mcp_server' );
function mia_registra_mcp_server() {
    $adapter = wp_mcp_adapter();
    $adapter->register_server( 'mio-plugin', array(
        'name'         => 'Mio Plugin AI',
        'version'      => '1.0.0',
        'abilities'    => array( 'content/summarize-post' ),
        'capabilities' => array( 'tools' ),
    ) );
}

Da questo momento, un client MCP (Claude Desktop, Cursor, Continue.dev, ChatGPT con supporto MCP) può connettersi al sito via STDIO o streamable HTTP e vedere summarize-post come tool disponibile. L'AI assistant può decidere autonomamente di chiamarlo quando l'utente chiede "riassumi l'ultimo post pubblicato".

Tre guardrail operativi non negoziabili

Quando esponi abilities via MCP, la superficie d'attacco aumenta: un client compromesso potrebbe chiamare strumenti con input malevoli. Tre regole ferree.

1. Whitelist di ability id: non esporre mai tutte le abilities registrate. Decidi tu quali sono "esterne".
2. Rate limit per ability: aggiungi un token bucket. Il Plugin Team consiglia wp_ai_client_rate_limit() con scope per user_id e ability_id.
3. Log audit obbligatorio: ogni chiamata MCP deve loggare user_id, ability_id, input_hash, tokens_used, timestamp. Il log non è opzionale, è la base del GDPR compliance.

WP AI Client: il collante tra plugin e provider

WP AI Client è la libreria che rende il pattern portabile. Vediamo le tre feature che lo distinguono da una semplice wp_remote_post() custom.

Feature 1: provider abstraction con capability matrix

$client = wp_ai_client();
$capabilities = $client->get_capabilities();
// output:
// array(
//   'text_generation' => array( 'openai', 'anthropic', 'ollama' ),
//   'image_generation' => array( 'openai' ),
//   'embeddings' => array( 'openai', 'ollama' ),
// )

Il plugin può scegliere dinamicamente un provider in base a cosa deve fare. Se domani Anthropic rilascia image generation, non devi toccare il codice: aggiorni il client.

Feature 2: capability-based access e kill switch

// disabilitare globalmente l'AI per manutenzione
add_filter( 'wp_ai_client_enabled', '__return_false' );
// oppure per singola ability
add_filter( 'wp_ai_client_ability_enabled', function( $enabled, $ability_id ) {
    if ( $ability_id === 'content/summarize-post' && ! current_user_can( 'manage_options' ) ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Il kill switch wp_ai_client_enabled è fondamentale per chi gestisce flotte di siti: un command injection nel prompt o un breach del provider si bloccano modificando un constant in wp-config.php.

Feature 3: cost tracking integrato

$response = $client->generate_text( array( ... ) );
update_option( 'mio_plugin_ai_cost_june', ( get_option( 'mio_plugin_ai_cost_june' ) ?: 0 ) + $response['cost_usd'] );

$response['cost_usd'] è calcolato dal client conoscendo il pricing del modello usato. Niente più fogli Excel per riconciliare le fatture OpenAI a fine mese.

Caso reale: agenzia con 12 siti clienti

Un'agenzia milanese con cui lavoro ha adottato il pattern su un plugin interno di content brief. Prima: 12 siti, 12 plugin leggermente diversi, 3 provider LLM contrattati a tariffe diverse. Dopo sei mesi col pattern:

• Tempo medio di sviluppo di una nuova ability: passato da 4 ore a 1,5 ore (l'abilità è dichiarativa, l'AI client è condiviso).
• Costo medio mensile AI: sceso del 32% grazie al routing automatico Ollama per task semplici e GPT-4o solo per task complessi.
• Audit GDPR: tempo di generazione report passato da 2 giorni a 4 ore, perché i log sono strutturati e non sparsi in 12 codebase diverse.
• Provider lock-in: eliminato. Sono passati da OpenAI a Anthropic Sonnet in 2 settimane durante un aumento di prezzo, senza toccare i plugin dei clienti.

Roadmap di adozione in 5 step

Una sequenza realistica per adottare il pattern in produzione, basata sull'esperienza con clienti di taglia diversa.

Step 1: audit del plugin esistente

Identifica le funzioni AI attuali. Per ognuna chiediti: usa una API key hardcoded? Ha capability check? Logga le chiamate? Se la risposta è "no" a due su tre, è un candidato alla migrazione.

Step 2: installa WP AI Client

# richiede WP-CLI 2.10+ e PHP 8.1+
wp plugin install wp-ai-client --activate
wp ai-client provider add openai --api-key="$OPENAI_KEY"
wp ai-client provider add ollama --endpoint="http://localhost:11434"

Il comando wp ai-client provider add è la novità 2026: permette di configurare i provider da CLI senza editare costanti a mano.

Step 3: converti una ability esistente

Parti da una singola ability a basso rischio (es. "genera meta description"). Riscrivila seguendo lo schema visto sopra, testa in staging, poi promuovi.

Step 4: esponi via MCP

Installa wp-abilities-mcp-adapter, registra il server MCP, testa la connessione da Claude Desktop o Cursor. Valida che le abilities siano elencate e che i permission callback funzionino.

Step 5: monitora e itera

Imposta un cron giornaliero che aggrega mio_plugin_ai_cost_<mese>, mio_plugin_ai_calls_<mese>, e invia report via email. Rivedi le abilities ogni trimestre: alcune saranno sotto-utilizzate e potranno essere rimosse.

Errori comuni che vedo nelle review

Dopo aver revisionato una dozzina di plugin AI nel 2026, ecco gli errori ricorrenti da evitare.

Errore 1: ability troppo generica

Creare un'ability do_anything($instruction) che accetta un prompt libero e decide lei cosa fare. Sembra flessibile, ma distrugge la capability matrix dell'AI client e rende impossibile il rate limiting. Un'ability deve fare una cosa sola, bene.

Errore 2: permission_callback ingenuo

# esempio codice
'permission_callback' => '__return_true',

Sembra assurdo, ma l'ho visto in due plugin pubblicati nel 2025. Mai. Sempre capability check basato su current_user_can() e validazione dell'input.

Errore 3: log solo in debug.log

Scrive in wp-content/debug.log è comodo ma non è un audit trail. Serve un log strutturato (custom table o rotazione file) con campi indicizzati: user_id, ability_id, cost, timestamp.

Errore 4: dimenticare la deprecazione

Il Plugin Team 2026 rilascia WP AI Client con API che evolvono rapidamente. Un'ability deprecata va marcata con 'status' => 'deprecated' e mantenuta per almeno 6 mesi. Non rimuovere mai silenziosamente.

FAQ

Il pattern funziona anche con plugin gratuiti pubblicati su .org?

Sì, anzi: il Plugin Team 2026 lo raccomanda esplicitamente nei criteri di review. I plugin che adottano abilities + MCP ricevono priorità nella coda di triage. Il tutorial wordpress.tv dell'8 giugno 2026 è nato proprio per supportare gli sviluppatori indipendenti in questa transizione.

Devo abbandonare wp_remote_post() per le chiamate LLM?

Non necessariamente. Se il tuo plugin fa una singola chiamata a una singola API, wp_remote_post() resta valido. Il pattern diventa necessario quando hai più di un'ability, più di un provider, o requisiti di compliance. La regola pratica è: se devi scrivere un wrapper per la chiamata HTTP, stai reinventando WP AI Client.

MCP è compatibile con il vecchio WP 6.x?

No. MCP richiede almeno WP 6.9 per le abilities, e il plugin adapter è testato solo su WP 7.0+. Se il tuo plugin deve supportare WP 6.5, devi restare su REST API classica. Considera questa come una buona scusa per abbandonare il supporto a versioni obsolete.

Posso mischiare abilities registrate e REST endpoint tradizionali?

Tecnicamente sì, concettualmente no. Ogni endpoint REST non mappato su un'ability è una superficie d'attacco non documentata per l'AI assistant. Meglio migrare tutto al pattern, o tenere il legacy fuori dal server MCP.

Il self-hosted LLM (Ollama) è production-ready con questo pattern?

Sì, con cautele. Ollama è supportato da WP AI Client da aprile 2026, e il pattern di routing "Ollama per task semplici, cloud per task complessi" è quello che uso di default. Vedi la mia guida a WordPress e LLM self-hosted per i dettagli di setup.

Quanto pesa in performance il pattern rispetto a una chiamata diretta?

Misurato su un sito staging: +12ms per chiamata a causa del layer di astrazione. Su un endpoint REST chiamato 100 volte al minuto è trascurabile. Se hai un carico anomalo (es. bulk generation di 1000 articoli), valuta batch async con WP-CLI asincrono.

Conclusione: il pattern è il futuro, ma adottalo con criterio

Il pattern abilities + MCP + WP AI Client non è una moda passeggera. È la risposta del Plugin Team a un bisogno reale: plugin AI portabili, sicuri e manutenibili. Detto questo, adottalo solo se il tuo caso d'uso lo giustifica. Un plugin che genera una sola stringa non ha bisogno di MCP, ma se stai costruendo un prodotto commerciale o un sistema interno per agenzia, questo pattern ti farà risparmiare mesi di refactoring.

Checklist operativa pre-pubblicazione

• Almeno un'ability registrata con input_schema e output_schema documentati
• Permission callback su ogni ability
• Rate limit configurato per ability e per user
• Log audit attivo con campi user_id, ability_id, cost, timestamp
• Kill switch wp_ai_client_enabled testato e funzionante
• Server MCP in staging con test da Claude Desktop o Cursor
• Cost tracking aggregato su base mensile
• Policy di deprecazione scritta per le abilities

Se la checklist è verde, il tuo plugin è pronto per la review 2026 del Plugin Team. Se è rossa su più di due punti, vale la pena rivedere l'architettura prima di pubblicare.

Riferimenti utili per approfondire

• Tutorial ufficiale "Build your first AI-powered WordPress plugin" su wordpress.tv - il video di riferimento da cui è nato l'articolo
• Repository GitHub WordPress/wp-ai-client - codice della libreria ufficiale del Plugin Team
• Specifica Model Context Protocol di Anthropic - documento tecnico del protocollo MCP
• WordPress 7.0 AI Connectors: guida operativa - come i Connectors dialogano con WP AI Client
• WPVibe e MCP per WordPress - caso commerciale di adozione MCP lato utente finale
• Repository WordPress/wp-abilities - reference implementation della Abilities API
• Documentazione Plugin Team su review 2026 - criteri aggiornati per plugin AI
• Esempio completo di plugin MCP-based - codice di partenza pronto all'uso
• OpenCode per temi WordPress con MCP - integrazione lato IDE di MCP per sviluppatori
• Creare plugin WordPress con AI: metodo completo - workflow completo per chi parte da zero
• AI workflow agenzia WordPress 2026 - come le agenzie adottano il pattern su più progetti
• WP-CLI nel 2026 con AI - automazione CLI del pattern abilities

L'angolo è architetturale e operativo, non promozionale. Vediamo il protocollo MCP in dettaglio, il plugin Vibe AI che lo implementa su WordPress, e forniamo snippet di codice per chi vuole costruire un proprio MCP server custom. È complementare alla panoramica WordPress 7.0 e AI Connectors e al metodo per creare plugin con AI.

Cos'è il Model Context Protocol e perché riguarda WordPress

MCP è uno standard aperto, rilasciato da Anthropic a fine 2024 e diventato rapidamente il protocollo di riferimento per connettere modelli AI a strumenti esterni. L'analogia corretta è USB-C per l'AI: invece di scrivere un'integrazione diversa per ogni coppia (modello × tool), chi sviluppa il tool espone un server MCP, e qualsiasi modello compatibile (Claude, ChatGPT, Cursor, Cline) può consumarlo.

Prima di MCP, l'integrazione funzionava così:

• L'utente copia un prompt da ChatGPT
• Lo incolla in WordPress
• L'AI restituisce un testo
• L'utente lo incolla di nuovo nell'editor

Con MCP, il flusso diventa:

• L'utente dice a Claude: "Crea un articolo sul mio ultimo prodotto, aggiungi un'immagine da Unsplash, schedulalo per venerdì"
• Claude parla con il server MCP di WordPress esposto dal plugin
• Il server MCP traduce le istruzioni in chiamate WordPress reali (wpinsertpost, wpmediasideloadimage, wpupdate_post)
• Claude conferma e l'utente vede il draft nell'admin

È la differenza tra "AI che genera testo" e "AI che esegue azioni".

WPVibe: il plugin che porta MCP su WordPress

WPVibe (disponibile gratuitamente su WordPress.org come Vibe AI) è un plugin sviluppato dal team di SeedProd (il page builder usato da oltre 1 milione di siti) che implementa un server MCP completo per WordPress. Una volta installato e configurato, espone un endpoint HTTPS che può essere collegato a Claude, ChatGPT, Cursor, o qualsiasi client compatibile MCP.

Cosa può fare concretamente

Il plugin espone una serie di "tools" che il modello AI può invocare. Ecco l'elenco ufficiale al momento del lancio.

• wpvibe_create_post: crea un nuovo post (status bozza di default, titolo, contenuto, categorie, tag)
• wpvibe_update_post: aggiorna un post esistente
• wpvibe_list_posts: elenca post recenti con filtri (status, data, autore)
• wpvibe_upload_media: carica un'immagine da URL o da prompt Unsplash nella libreria media
• wpvibe_set_featured_image: imposta la featured image di un post
• wpvibe_list_plugins: elenca plugin attivi con versione e stato aggiornamento
• wpvibe_health_check: esegue controlli diagnostici (versione PHP, spazio disco, plugin outdated)
• wpvibe_search_unsplash: cerca foto stock tramite query testuale
• wpvibe_edit_theme_file_sandboxed: modifica file del tema in ambiente sandbox (mai scritto direttamente su disco)
• wpvibe_run_wpcli: esegue un sottoinsieme limitato di comandi WP-CLI (whitelist)

L'elenco è in crescita. Il team SeedProd ha annunciato che aggiungeranno strumenti per WooCommerce (gestione ordini, prodotti, inventario) e per i custom post type nei prossimi mesi.

Setup in 60 secondi

L'installazione è volutamente semplice.

1. Installa il plugin: Bacheca → Plugin → Aggiungi nuovo → cerca "Vibe AI" → Installa → Attiva
2. Genera il token di accesso: il plugin crea automaticamente un'application password WordPress (sistema nativo introdotto in WP 5.6) con scope limitato alle capability MCP
3. Copia l'endpoint MCP: si trova in Impostazioni → Vibe AI → Connection. È un URL tipo https://tuosito.it/wp-json/wpvibe/v1/mcp
4. Collega il client AI: in Claude/ChatGPT/Cursor, apri la sezione "Connectors" o "MCP Servers", incolla l'endpoint, autenticati con la application password
5. Testa la connessione: digita "Elenca i miei ultimi 5 articoli pubblicati"

Da quel momento il modello può eseguire i task elencati sopra. La prima connessione richiede circa 60 secondi, le successive sono istantanee.

Architettura di sicurezza: perché i guardrail contano

Un server MCP che può modificare il tuo sito è un'arma a doppio taglio. SeedProd ha implementato una serie di guardrail espliciti, documentati pubblicamente. Vediamoli uno per uno.

Guardrail 1: nuovi post in draft di default

Ogni post creato via WPVibe va in stato draft, mai pubblicato direttamente. Questo significa che un'AI che decide di "sbagliare tono" su un articolo importante richiede un'azione umana esplicita per andare online. È il guardrail più semplice e più importante.

Guardrail 2: cancellazioni vanno nel cestino

Quando l'AI elimina un contenuto, va nel cestino di WordPress (dove resta recuperabile per 30 giorni), non viene rimosso definitivamente. Doppio livello di safety: l'AI può solo spostare, non cancellare.

Guardrail 3: modifiche ai temi in sandbox

Questo è il guardrail più elegante. Quando l'AI modifica un file del tema (functions.php, header.php, style.css), la modifica va in un file sandbox separato, non sovrascrive il file originale. L'utente vede un diff e deve approvare esplicitamente prima che la modifica venga applicata. In caso di errore, basta scartare il diff.

// Struttura del sandbox (pseudocodice del sistema)
$active_theme = wp_get_theme();
$sandbox_dir  = WP_CONTENT_DIR . '/uploads/wpvibe-sandbox/' . $active_theme->get_stylesheet();
$original     = get_template_directory() . '/functions.php';
$sandbox_file = $sandbox_dir . '/functions.php.sandbox';

if ( ! file_exists( $sandbox_dir ) ) {
    wp_mkdir_p( $sandbox_dir );
}

// L'AI scrive solo nel sandbox, mai nell'originale
file_put_contents( $sandbox_file, $modified_content );

// Review umana
register_shutdown_function( function() use ( $sandbox_file, $original ) {
    if ( current_user_can( 'edit_themes' ) && get_transient( 'wpvibe_apply_sandbox' ) ) {
        copy( $sandbox_file, $original );
        delete_transient( 'wpvibe_apply_sandbox' );
    }
} );

Guardrail 4: WP-CLI in whitelist

L'AI può eseguire solo comandi WP-CLI in una whitelist predefinita. I comandi pericolosi (rm, drop, truncate, exec) sono bloccati a livello di capability. La whitelist è consultabile e personalizzabile dagli admin del sito.

// Whitelist WP-CLI di default
add_filter( 'wpvibe_wpcli_whitelist', function( $commands ) {
    $commands = [
        'wp post list',
        'wp post get',
        'wp option get',
        'wp user list',
        'wp plugin list',
        'wp theme list',
        'wp db query',  // attenzione: solo SELECT, monitorato
        'wp cache flush',
        'wp transient delete --all',
    ];
    return $commands;
} );

Guardrail 5: autenticazione via application password

Il plugin usa il sistema nativo WordPress di application password (RFC 2FA-style, supportato dal core dalla 5.6). Le credenziali sono cifrate a riposo, sono revocabili in un click dall'admin, e possono essere limitate a un sottoinsieme di capability.

Caso d'uso reale: agenzia con 15 siti clienti

Marco gestisce un'agenzia di sviluppo web con 15 siti clienti su managed hosting. Ha implementato WPVibe su tutti e 15 i siti e usa Claude (con il piano Pro) come client MCP centrale. Ecco come ha strutturato il workflow.

Workflow mattutino (15 min)

1. Chiede a Claude: "Mostrami tutti i post pubblicati ieri sera su tutti i miei siti, con il numero di commenti per ciascuno"
2. Claude interroga i 15 server MCP in parallelo (la chiamata MCP supporta richieste multiple), aggrega i risultati, produce un report
3. Marco legge il report in chat e decide se intervenire

Workflow editoriale (1 ora → 15 min)

1. Marco riceve una brief da un cliente: "5 articoli sul tema X, stile Y, con immagini"
2. Chiede a Claude: "Per il sito example.com, genera 5 bozze di articoli sul tema X, stile Y, con immagini da Unsplash, tutti in draft"
3. Claude crea 5 draft, ciascuno con featured image, tag, e categoria corretta
4. Marco legge le bozze in Bacheca (draft visibili), modifica dove serve, pubblica

Manutenzione tecnica

1. Marco: "Verifica salute di tutti i miei siti: versione PHP, plugin outdated, spazio disco"
2. Claude esegue wpvibe_health_check su tutti i server, aggrega, segnala i problemi
3. Marco interviene manualmente sui siti con problemi

Risultato: tempo risparmiato ~6 ore/settimana, ROI del setup in meno di un mese.

Limiti e problemi reali di WPVibe

Non è tutto rose e fiori. Ecco i limiti che ho incontrato nei test.

Limite 1: il client AI deve supportare MCP nativamente

Al momento, i client che supportano MCP out-of-the-box sono: Claude (desktop, web, Code), Cursor (editor AI), Cline (estensione VS Code), e pochi altri. ChatGPT supporta MCP in beta ristretta per utenti Pro. Gemini no. Per chi usa prevalentemente ChatGPT, il vantaggio è ancora parziale.

Limite 2: l'AI può solo eseguire i tool esposti

Se vuoi che l'AI possa, per esempio, modificare le impostazioni di un plugin SEO, quel plugin deve avere un tool MCP registrato. WPVibe espone i tool nativi WordPress, ma per integrazioni con plugin terzi serve lavoro custom. Stanno arrivando estensioni community per Yoast, Rank Math, WooCommerce, ma è work in progress.

Limite 3: la latenza delle operazioni multiple

Se chiedi a Claude "Crea 10 articoli", ogni articolo richiede una chiamata MCP separata. Su un sito con hosting lento, 10 articoli = 30-60 secondi. Per task di massa meglio fare batch via WP-CLI tradizionale.

Limite 4: nessuna memoria persistente cross-sessione

L'AI non ricorda le tue preferenze tra una sessione e l'altra. Se gli dici "usa sempre lo stile formale", devi ridirlo ogni volta. Soluzione: usare il file CLAUDE.md (per Claude) o AGENTS.md (per Cursor) per memorizzare le convenzioni del sito.

Costruire il proprio MCP server WordPress custom

Se WPVibe non fa al caso tuo (ad esempio, vuoi esporre strumenti custom del tuo tema o plugin), puoi costruire un server MCP custom. Ecco un esempio minimale.

<?php
/**
 * Plugin Name: My Custom MCP Server
 * Description: Esempio di server MCP custom per WordPress
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// 1. Registra l'endpoint REST
add_action( 'rest_api_init', function() {
    register_rest_route( 'my-mcp/v1', '/tools', [
        'methods'             => 'GET',
        'callback'            => 'mymcp_list_tools',
        'permission_callback' => function() {
            return current_user_can( 'edit_posts' );
        },
    ] );

    register_rest_route( 'my-mcp/v1', '/invoke', [
        'methods'             => 'POST',
        'callback'            => 'mymcp_invoke_tool',
        'permission_callback' => function() {
            return current_user_can( 'edit_posts' );
        },
    ] );
} );

// 2. Lista dei tool esposti
function mymcp_list_tools() {
    return [
        'tools' => [
            [
                'name'        => 'get_recent_comments',
                'description' => 'Restituisce gli ultimi commenti del blog',
                'inputSchema' => [
                    'type'       => 'object',
                    'properties' => [
                        'limit' => [
                            'type'        => 'integer',
                            'description' => 'Numero massimo di commenti',
                            'default'     => 10,
                        ],
                    ],
                ],
            ],
            [
                'name'        => 'get_site_stats',
                'description' => 'Restituisce statistiche aggregate del sito',
                'inputSchema' => [
                    'type'       => 'object',
                    'properties' => (object) [],
                ],
            ],
        ],
    ];
}

// 3. Invocazione del tool
function mymcp_invoke_tool( WP_REST_Request $request ) {
    $body = $request->get_json_params();
    $tool = sanitize_text_field( $body['name'] ?? '' );
    $args = $body['arguments'] ?? [];

    switch ( $tool ) {
        case 'get_recent_comments':
            $limit  = absint( $args['limit'] ?? 10 );
            $comments = get_comments( [ 'number' => $limit, 'status' => 'approve' ] );
            return rest_ensure_response( [
                'comments' => array_map( function( $c ) {
                    return [
                        'id'       => $c->comment_ID,
                        'author'   => $c->comment_author,
                        'content'  => $c->comment_content,
                        'post_id'  => $c->comment_post_ID,
                        'date'     => $c->comment_date,
                    ];
                }, $comments ),
            ] );

        case 'get_site_stats':
            return rest_ensure_response( [
                'posts'        => wp_count_posts()->publish,
                'pages'        => wp_count_posts( 'page' )->publish,
                'comments'     => wp_count_comments()->approved,
                'users'        => count_users()['total_users'],
                'php_version'  => phpversion(),
                'wp_version'   => get_bloginfo( 'version' ),
            ] );

        default:
            return new WP_Error( 'unknown_tool', 'Tool non riconosciuto', [ 'status' => 400 ] );
    }
}

Questo è uno scheletro funzionante. Per un server MCP completo servono altri endpoint (risorse, prompt templates, gestione errori strutturata secondo lo standard MCP), ma il pattern è questo.

Domande frequenti

WPVibe è davvero gratuito?

Sì, il plugin Vibe AI è gratuito e open source su WordPress.org. Il team SeedProd lo monetizza indirettamente (è una leva per il loro page builder a pagamento), ma il plugin in sé non ha limitazioni, watermark, o costi nascosti.

Posso usarlo con ChatGPT?

Dipende. ChatGPT ha aggiunto il supporto MCP in beta ristretta per utenti Pro a fine 2025. Se sei nel rollout, sì. Altrimenti Claude Desktop e Cursor sono le opzioni più affidabili. Gemini non supporta MCP al momento.

L'AI può cancellare definitivamente un post?

No. Il guardrail del cestino è hardcoded: qualsiasi cancellazione passa per wp_trash_post(), mai wp_delete_post() con force_delete = true. I post nel cestino sono recuperabili per 30 giorni dall'admin WordPress.

È sicuro esporre l'endpoint MCP su internet?

Sì, a patto di: (1) usare HTTPS, (2) autenticare ogni richiesta con application password, (3) mantenere il plugin aggiornato, (4) monitorare i log per attività sospette. L'endpoint è protetto almeno quanto wp-admin.

Cosa succede se l'AI propone modifiche sbagliate al tema?

Vanno tutte nel sandbox. L'utente vede un diff e deve approvare. Se approva per sbaglio, il file originale viene sovrascritto: per questo è essenziale avere un backup (UpdraftPlus, BlogVault, o snapshot del hosting).

Vale la pena rispetto a Jetpack AI o Divi AI?

Sono prodotti diversi. Jetpack AI e Divi AI lavorano dentro l'editor di un singolo post, con focus su generazione di testo. WPVibe lavora a livello di sito, con focus su automazione e orchestrazione via linguaggio naturale. Per un blogger singolo, Jetpack AI è più immediato. Per un'agenzia, WPVibe è enormemente più potente.

WPVibe funziona con WooCommerce?

Al lancio no, ma il team ha annunciato integrazione WooCommerce in roadmap Q3 2026 (gestione ordini, prodotti, inventario via MCP). Per ora, plugin terzi stanno già sperimentando bridge custom.

Riferimenti utili per approfondire

• WPVibe sito ufficiale - documentazione completa e setup guidato.
• Vibe AI su WordPress.org - download e recensioni.
• Model Context Protocol spec Anthropic - documentazione tecnica del protocollo.
• SeedProd page builder - chi sviluppa WPVibe.
• MCP servers directory ufficiale - catalogo di server MCP community.
• WordPress Application Passwords - come funziona il sistema di autenticazione usato da WPVibe.
• Claude Desktop MCP setup - come collegare Claude come client MCP.
• WordPress 7.0 AI Connectors mrtux.it - confronto con l'approccio alternativo dei Connectors core.
• Creare plugin WordPress con AI mrtux.it - per chi vuole costruire il proprio MCP server.
• Sicurezza WordPress plugin piratati mrtux.it - rischi da considerare quando si espongono endpoint.

Questa guida verrà aggiornata quando arriveranno le integrazioni WooCommerce e i tool community. Per casi d'uso specifici o problemi di setup, l'area commenti è aperta.

Questo tutorial spiega come usare il plugin WP Novamira in modo pratico, partendo dalla documentazione ufficiale e mantenendo un principio fondamentale: Novamira è uno strumento potente, pensato per sviluppo e staging, non per fare esperimenti direttamente su un sito in produzione.

Se lavori già con WordPress, AI e progettazione di temi, puoi collegare questo workflow anche ad altri approfondimenti pubblicati su MrTux, come la guida su AI per migliorare SEO, UX e design su WordPress, il metodo per creare articoli WordPress ottimizzati SEO con AI e l'analisi sugli strumenti per il web design di temi WordPress.

Cos'è Novamira.ai e perché interessa ai designer WordPress

Novamira è un plugin WordPress che consente a client AI compatibili con MCP, come Claude, Cursor, VS Code Copilot o altri strumenti che supportano il protocollo, di interagire con WordPress in modo programmatico. Secondo la documentazione ufficiale Getting started, il plugin permette all'AI assistant di eseguire codice PHP, leggere e scrivere file, gestire database, installare plugin e costruire funzionalità personalizzate.

Per il web design WordPress, questo significa poter lavorare con un agente AI che non si limita a suggerire codice in astratto, ma può leggere la struttura reale del sito, controllare il tema, verificare plugin attivi, creare file nella sandbox e iterare sulle modifiche con maggiore contesto.

Novamira non va interpretato come un page builder automatico, ma come un ponte operativo tra WordPress e un assistente AI tecnico.

Prima di iniziare: requisiti tecnici

Prima di installare Novamira, conviene verificare che l'ambiente sia adeguato. La pagina ufficiale sui requisiti Novamira indica alcune condizioni minime da rispettare.

Per installazioni locali senza HTTPS, la documentazione spiega che è possibile impostare WP_ENVIRONMENT_TYPE su local nel file wp-config.php. Questa eccezione va usata solo in locale, non su server remoti.

Installare Novamira su WordPress

La procedura di installazione è simile a quella di molti plugin premium o distribuiti via ZIP. La guida ufficiale Installation indica un flusso diretto: scaricare il file ZIP, caricarlo da WordPress e attivarlo.

1. Scarica l'ultima versione ZIP di Novamira dalla pagina di download ufficiale.
2. Entra nel pannello WordPress del sito di sviluppo o staging.
3. Vai in Plugin > Aggiungi nuovo plugin > Carica plugin.
4. Seleziona il file ZIP di Novamira e clicca su Installa ora.
5. Attiva il plugin.

All'attivazione, Novamira registra il MCP Adapter incluso, espone un menu dedicato nella sidebar admin e prepara le otto abilità principali. Le abilità AI, però, restano disattivate di default: nessun tool MCP viene esposto finché non viene abilitato esplicitamente.

Configurare le AI Abilities

Dopo l'installazione, il passaggio più importante è la configurazione. La pagina ufficiale Configuration spiega che bisogna abilitare manualmente le AI Abilities da Novamira > Settings.

1. Apri il pannello WordPress.
2. Vai in Novamira > Settings.
3. Attiva la checkbox Enable AI Abilities.
4. Leggi con attenzione il messaggio di conferma.
5. Conferma e salva le impostazioni.

Quando le abilità sono attive, compare un indicatore rosso Novamira ON nella barra di amministrazione. È un promemoria utile: in quel momento l'AI agent può accedere agli strumenti MCP collegati al sito.

Le otto abilità disponibili

Novamira registra otto abilità principali. Per un web designer o sviluppatore WordPress, è importante capire cosa fanno prima di usarle in un flusso reale.

Collegare il client AI tramite MCP

Una volta abilitate le AI Abilities, bisogna collegare il client AI. La guida Connecting Your AI Client descrive il processo basato su Application Password e configurazione MCP.

1. Crea una Application Password

Da Novamira > Connect, crea una nuova Application Password. WordPress mostrerà la password una sola volta: copiala subito e conservala in modo sicuro. È consigliabile usare un nome descrittivo, ad esempio il nome del client o della workstation.

2. Configura il client MCP

Novamira fornisce snippet per client come Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Zed e OpenCode. Il modello generale usa npx per avviare il proxy remoto @automattic/mcp-wordpress-remote.

{
  "mcpServers": {
    "novamira": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://your-site.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "your-wordpress-username",
        "WP_API_PASSWORD": "your-application-password"
      }
    }
  }
}

Nel tuo caso reale dovrai sostituire URL, username e Application Password con quelli del sito di staging. Dopo aver salvato la configurazione, riavvia il client AI: molti strumenti caricano i server MCP solo all'avvio.

3. Verifica la connessione

Per verificare che tutto funzioni, chiedi all'agente AI un'operazione semplice e non distruttiva, ad esempio elencare i plugin installati. Se la connessione è corretta, il client dovrebbe mostrare gli strumenti Novamira e usare Execute PHP o le altre abilità disponibili.

Tutorial pratico: usare Novamira per migliorare un layout WordPress

Un caso d'uso realistico per il web design è l'ottimizzazione di una pagina WordPress esistente. L'obiettivo non è chiedere all'AI di "rifare tutto", ma guidarla con richieste progressive e verificabili.

1. Mappa il sito: chiedi all'agente di identificare tema attivo, plugin principali e struttura dei template.
2. Analizza la pagina: fai leggere template, CSS e blocchi coinvolti nella pagina da migliorare.
3. Definisci il problema: per esempio hero troppo pesante, CTA poco visibile, spaziature incoerenti o layout mobile debole.
4. Chiedi una proposta: prima solo piano di intervento, poi modifica mirata.
5. Applica in staging: usa Edit File o file sandbox, mai direttamente su produzione.
6. Verifica risultato: controlla frontend, editor WordPress, mobile e performance.
7. Disabilita o raffina: se una modifica non convince, disabilita il file sandbox o chiedi una correzione puntuale.

Un prompt pratico potrebbe essere: "Analizza il tema attivo e proponi un miglioramento del layout della pagina servizi. Non modificare file finché non approvo il piano. Concentrati su leggibilità, CTA, mobile e compatibilità con Gutenberg".

Sicurezza: cosa fare e cosa evitare

La parte più importante della documentazione Novamira è quella sulla sicurezza. La pagina Security & Best Practices chiarisce che Novamira offre accesso programmatico reale al sito WordPress. Questo è il suo valore, ma anche il motivo per cui va usato con disciplina.

La documentazione su uso live/production è molto esplicita: le AI abilities dovrebbero essere attivate solo su ambienti di sviluppo e staging, mai direttamente in produzione. Il plugin può rimanere installato sul sito live, ma le abilità AI devono restare disattivate.

• Usa sempre backup prima di lavorare con AI agents.
• Configura Novamira su staging o sviluppo, non sul sito live.
• Approva ogni tool call prima dell'esecuzione.
• Crea Application Password separate per client o workstation.
• Revoca le password non più usate.
• Evita richieste vaghe come "sistema il sito".
• Preferisci interventi piccoli, verificabili e reversibili.

Capire la sandbox

La sandbox Novamira si trova in wp-content/novamira-sandbox/. Secondo la pagina ufficiale The Sandbox, i file PHP scritti dagli AI agent vengono confinati in questa directory e caricati automaticamente a ogni richiesta WordPress tramite un loader must-use.

Questo rende la sandbox utile per organizzare codice generato dall'AI: shortcode, endpoint REST, custom post type, funzioni di supporto o piccoli esperimenti. Ma la documentazione precisa anche un punto essenziale: la sandbox non è una vera barriera di sicurezza. Il codice che gira lì ha comunque privilegi simili a quelli di un plugin WordPress.

Quando Novamira è utile nel web design WordPress

Novamira diventa interessante quando il progetto richiede lavoro tecnico su un sito reale: analisi del tema, creazione di funzionalità, debug, verifica plugin, generazione di CSS mirato, integrazioni PHP o miglioramenti di workflow. Non sostituisce Figma, Gutenberg o un buon processo di design; li affianca nella fase di implementazione e revisione tecnica.

• Utile: staging, prototipi, debug, sviluppo custom, analisi plugin, refactoring controllato.
• Da evitare: test diretti su produzione, modifiche non approvate, prompt troppo generici, assenza di backup.
• Da valutare: team con più sviluppatori, processi di deploy, policy interne e gestione credenziali.

FAQ su Novamira e WordPress

Novamira è un page builder AI?

No. Novamira non è un page builder visuale. È un plugin che collega AI agents a WordPress tramite MCP, dando accesso a strumenti tecnici per leggere, modificare e testare il sito.

Posso usarlo su un sito in produzione?

La documentazione consiglia di usare le AI abilities solo su sviluppo o staging. Su produzione il plugin può restare installato, ma le abilità AI dovrebbero rimanere disattivate.

Serve Node.js?

Per connessioni remote tramite MCP proxy serve Node.js 18 o superiore lato client. Per installazioni locali con WP-CLI è possibile usare il trasporto STDIO, che non richiede Node.js.

La sandbox rende sicuro il codice generato dall'AI?

No. La sandbox aiuta a organizzare e gestire i file PHP generati, ma non va considerata una barriera di sicurezza. Il codice va sempre revisionato prima di portarlo in produzione.

Conclusione

Novamira.ai è uno strumento potente per chi lavora con WordPress in modo tecnico. Permette a un AI agent di operare con molto più contesto rispetto al classico copia e incolla di codice, aprendo scenari interessanti per sviluppo, debug, prototipazione e miglioramento del web design.

Il modo migliore per iniziare è prudente: installa Novamira su staging, abilita le AI Abilities solo quando servono, collega un client MCP, prova operazioni non distruttive e lavora sempre per passaggi piccoli. Se il risultato è valido, potrai poi portarlo nel normale flusso di deploy. L'AI diventa davvero utile quando accelera il lavoro senza togliere controllo al professionista.