MCP nella digital analytics: dalla domanda in chat al tag sul container

Questo editoriale segue il filo analytics del cluster MCP: quello che serve sapere del protocollo per usarlo nel lavoro quotidiano di misurazione, da una domanda su GA4 posta in chat fino al caso in cui il modello mette mano a un container di Google Tag Manager. Le voci del cluster restano gli approfondimenti di riferimento: qui ogni concetto è introdotto quanto basta a seguire il filo, e il link alla voce, alla prima occorrenza, porta al dettaglio completo e alle fonti. Il materiale deriva dalla documentazione ufficiale del protocollo e dei server Google, dagli articoli di Stape sui suoi server hosted e sui controlli per l’uso dell’AI su GTM, dall’analisi dei rischi di Red Hat e dal modello di minaccia di Simon Willison. La bibliografia aggregata sta in fondo.

Una presa standard per i dati di misurazione

Chi lavora nella digital analytics passa le giornate tra sistemi che non si parlano: Google Analytics 4 per il comportamento, Google Ads per la spesa, Google Tag Manager per la raccolta. Collegare un assistente AI a ciascuno di questi sistemi richiederebbe, senza uno standard, un’integrazione su misura per ogni coppia applicazione-servizio: con N applicazioni e M servizi, fino a N×M integrazioni. Il Model Context Protocol (MCP), annunciato da Anthropic il 25 novembre 2024 e dal dicembre 2025 governato dalla Agentic AI Foundation della Linux Foundation, riduce il problema a N+M: ogni applicazione implementa il protocollo una volta, ogni servizio espone un server compatibile. La metafora di Anthropic è USB-C, il collegamento unico al posto di un cavo per ogni coppia.

L’architettura distingue tre ruoli. L’host è l’applicazione usata dalla persona, per esempio Claude Desktop o Gemini CLI. Il client è il componente dell’host che comunica con un singolo server. Il server espone dati o azioni di un sistema esterno. Se l’host usa un server per GA4 e uno per GTM, crea due client separati e coordina i risultati. Ciò che i server espongono sono le primitive: tool che eseguono azioni, resource in sola lettura, prompt riutilizzabili. Nei server per l’analytics contano soprattutto i tool: il modello sceglie quale invocare e ne compila i parametri, il server traduce la chiamata nell’API del sistema. I messaggi viaggiano in JSON-RPC su un transport che è stdio per i server locali e Streamable HTTP per quelli remoti, una distinzione che tornerà più avanti, perché i server Google sono locali e quelli di Stape remoti.

Un’ultima coordinata prima di entrare nei server: la spec 2026-07-28, informalmente “MCP 2.0”, ha reso il protocollo stateless. Ogni richiesta viaggia da sola, senza sessione da mantenere lato server. Per chi usa i server dell’analytics da un client desktop il cambiamento è quasi invisibile, ma è la ragione per cui i server remoti del 2026 sono più semplici da distribuire e scalare di quelli dell’anno precedente.

Leggere GA4 dalla chat

Il primo caso d’uso concreto è il GA4 MCP Server, il server ufficiale di Google Analytics pubblicato nel repository googleanalytics/google-analytics-mcp. Gira sul computer dell’utente, opera in sola lettura ed è ancora indicato come sperimentale. I suoi tool coprono le operazioni che un analista compie ogni giorno: elencare account e proprietà, eseguire report standard con run_report, analizzare funnel con run_funnel_report, leggere dimensioni e metriche personalizzate, ottenere dati in tempo reale. La domanda in linguaggio naturale (“quante sessioni ieri?”) diventa una tool call dell’host verso il server, che interroga l’API di Google Analytics e riporta il risultato nella conversazione.

Il setup, però, non è un percorso senza configurazione: l’installazione ufficiale usa pipx, richiede un progetto Google Cloud con le API Analytics Admin e Analytics Data abilitate, e credenziali applicative con il solo permesso analytics.readonly. È il primo esempio di un pattern che attraversa tutti i server Google del dominio: ufficiali, gratuiti e in sola lettura, ma gestiti in proprio, con il costo di configurazione a carico dell’utente.

Google Ads e il linguaggio delle query

Il Google Ads MCP Server, pubblicato come progetto open source nel 2025 e annunciato formalmente nell’aprile 2026, applica lo stesso modello alla spesa pubblicitaria. Anche qui sola lettura: il modello può esaminare campagne e proporre modifiche, ma non mettere in pausa, cambiare offerte o creare annunci. La configurazione aggiunge un requisito in più, il developer token della Google Ads API, con livelli di approvazione e quote differenti.

Il design dei tool merita attenzione, perché è una scelta che si ritrova in molti server ben fatti. Invece di esporre decine di tool fissi, il server ne espone tre: list_accessible_customers elenca gli account leggibili, get_resource_metadata descrive i campi disponibili, e search esegue query in GAQL, il linguaggio di interrogazione della Google Ads API simile a SQL. Un solo tool copre quasi ogni domanda di reporting, perché GAQL è il linguaggio completo dell’API. Il rovescio è che l’accuratezza della risposta dipende dalla capacità del modello di scrivere GAQL corretto: un campo sbagliato o un segmento data mancante può produrre un errore oppure, peggio, numeri plausibili esposti con sicurezza. Chi valuta le risposte deve conoscere almeno le convenzioni del linguaggio, a partire dai costi espressi in micros, dove un milione di micros vale un’unità della valuta dell’account.

Il passo oltre la lettura: scrivere su GTM

Fin qui i server leggono. Il GTM MCP Server di Stape, disponibile all’indirizzo gtm-mcp.stape.ai/mcp, rompe lo schema: può creare e modificare tag, trigger, variabili e versioni di un container GTM. Per il lavoro di misurazione è il caso più interessante e insieme il più delicato, perché un errore può produrre un tag apparentemente corretto ma privo di un’impostazione di consenso o di deduplicazione.

La distinzione che rende il rischio gestibile è quella tra modifica e pubblicazione. Stape raccomanda di assegnare all’account usato dall’AI soltanto il permesso Edit: il modello può lavorare in un workspace, ma la versione arriva sul sito solo dopo che una persona l’ha controllata e pubblicata. Attorno a questa distinzione Stape costruisce sei controlli: integrazione proporzionata al rischio, account dedicato con solo Edit, un workspace separato per sessione (eliminabile in blocco per annullare tutto), verifica diretta delle modifiche in GTM invece del riepilogo del modello, verifica indipendente con la Preview o con i dati letti dal server GA4, e regole operative salvate in un file di istruzioni. Il principio che li tiene insieme vale oltre GTM: i permessi tecnici sono più affidabili di un divieto scritto nel prompt, perché il modello può interpretare male un’istruzione, mentre l’API applica il limite dell’account.

Hosted o self-hosted

I server incontrati finora tracciano una divisione che orienta la scelta pratica. I server ufficiali di Google sono self-hosted: gratuiti, con il codice nel repository pubblico, ma con progetto cloud, credenziali OAuth e processo locale a carico dell’utente. Stape, il principale fornitore di server MCP per il tracking, offre l’alternativa hosted: quattro server gratuiti raggiungibili via URL, con autenticazione OAuth Google gestita da mcp-remote, senza progetto GCP né pacchetto Python da mantenere. La comodità si paga con una dipendenza dal fornitore, che sta nel mezzo tra il client e i dati.

Della posizione di Stape vale la pena riportare anche la tesi sull’ambito d’uso, perché viene dal fornitore stesso dei server: i server MCP vanno bene per l’esplorazione e le modifiche una tantum, mentre per le azioni ripetute conviene una connessione API diretta con script, che produce lo stesso risultato a ogni esecuzione ed è revisionabile come codice. Una domanda estemporanea su un calo di conversioni è un buon caso per MCP; il report che parte ogni lunedì mattina probabilmente no.

Il modello di rischio

Collegare un modello linguistico ai dati di misurazione apre il capitolo della sicurezza. Red Hat raggruppa i rischi in sei categorie, dalla catena di fornitura (un server installato da terzi è codice eseguibile) alla prompt injection, il caso in cui un contenuto letto dal modello, una pagina, un’email, contiene istruzioni nascoste che il modello scambia per comandi. Simon Willison condensa il pericolo nella “trifecta letale”: dati non attendibili, capacità di azione e attaccabilità via prompt injection, pericolose quando coesistono nella stessa sessione.

Il dominio analytics offre un esempio concreto della trifecta: una sessione in cui il modello legge dati che possono contenere testo di terzi (per esempio referrer o termini di ricerca in un report GA4) e allo stesso tempo dispone del tool di scrittura su GTM combina due delle tre condizioni. La sola lettura dei server Google non è quindi un dettaglio ma una scelta di design che tiene l’analisi separata dall’esecuzione. Willison stesso, critico verso MCP nel 2025, ha parzialmente rivisto la posizione nel 2026: un insieme limitato di tool, registrabili e controllabili singolarmente, è più facile da governare di una shell con accesso libero a internet. Il protocollo restringe il confine d’azione; il problema della prompt injection resta aperto.

Cosa MCP non fa

L’ultimo pezzo del quadro sono i limiti, riassunti dalla metafora “una porta, non un lavoratore”. MCP standardizza il collegamento con il tool, non l’orchestrazione del lavoro: il server GA4 risponde quando l’host lo interroga, ma non contiene il trigger che controlla le conversioni ogni mattina né la memoria che conserva lo storico delle analisi. Chi vuole report schedulati o reazioni a eventi deve inserire i server MCP in un workflow che fornisca calendario, trigger e memoria, il ciclo che la voce sull’agent loop descrive nella sua forma fondamentale. Anche il coordinamento tra sistemi spetta all’host: una vista che incrocia GA4, Google Ads e GTM è possibile, ma sono tre server e tre client da orchestrare.

Le implementazioni Google aggiungono confini propri, che non sono limiti del protocollo ma scelte di design: le risposte dipendono dalle query generate dal modello, e una query valida ma concettualmente sbagliata produce numeri credibili e inutili; i server leggono campi strutturati e non valutano la qualità di immagini, video o landing page; non espongono il funzionamento interno di Smart Bidding o Performance Max. Per chi misura, la conseguenza pratica è che MCP automatizza l’accesso ai dati, non il giudizio su cosa i dati significano.

Come proseguire

Il portale del cluster dichiara il percorso di studio completo, sedici tappe con avanzamento salvato nel browser: è lo strumento per riprendere gli stessi argomenti voce per voce, con le fonti annotate affermazione per affermazione. Il cluster copre anche il filo che questo editoriale ha solo sfiorato, quello del protocollo in sé: la versione stateless nel dettaglio, le estensioni come i Task per i lavori a lunga esecuzione, l’ecosistema di registro e SDK, il protocollo complementare A2A per la delega tra agenti. Nel cluster privato restano approfondimenti non ancora pubblicati, tra cui l’autorizzazione in dettaglio (OAuth, DCR e CIMD): quando le voci corrispondenti matureranno, questo editoriale verrà esteso nei punti corrispondenti.

Bibliografia e sitografia

Le fonti primarie da cui derivano le voci attraversate dall’editoriale; il dettaglio degli ancoraggi sta nelle singole voci.

• Anthropic, Introducing the Model Context Protocol, 25 novembre 2024. anthropic.com
• Model Context Protocol docs, Architecture overview, spec 2026-07-28. modelcontextprotocol.io
• MCP Blog, The 2026-07-28 Specification, 28 luglio 2026. blog.modelcontextprotocol.io
• Google Developers, Try the Google Analytics MCP server, 16 settembre 2025. developers.google.com
• Carly, Google Analytics MCP: Official, Local, and Read-Only, 16 luglio 2026. usecarly.com
• Google Developers, Google Ads MCP server: Developer integration guide, 3 agosto 2026. developers.google.com
• Soku, Google Ads MCP: The Complete Guide (2026), 8 giugno 2026. soku.ai
• The Ad Spend, Google Ads MCP Limitations: Read-Only and Self-Hosted, 27 giugno 2026. theadspend.com
• Stape, How to configure the MCP Server for Google Tag Manager, 20 luglio 2026. stape.io
• Stape, How to configure the MCP Server for Google Analytics 4, 7 agosto 2026. stape.io
• Stape, AI in Google Tag Manager: give it access, not control, 11 agosto 2026. stape.io
• Red Hat, Model Context Protocol (MCP): Understanding security risks and controls, 1 luglio 2025. redhat.com
• Simon Willison, Stateless MCP has recaptured my interest, 31 luglio 2026. simonwillison.net