Come far leggere i dati di Drupal a un agente AI senza che li interpreti male?

Native Observability è nato per guardare dentro Drupal con una dashboard tutta sua: tempi delle rotte, cache e query lente, misurati dal sito stesso e letti da una persona in una pagina di amministrazione. Ora quegli stessi dati li legge anche un agente AI. A Claude Desktop basta chiedere «perché questa pagina è lenta?» e va a prenderli attraverso il Model Context Protocol, in sola lettura.

Dare i numeri a un modello però non basta. Li legge con il buon senso, e sulle metriche di Drupal il buon senso sbaglia in punti precisi. Nel primo confronto alla cieca, 4 risposte su 5 leggevano come traffico perso un calo causato dalla page cache, anche con le istruzioni giuste davanti.

Istruzioni migliori da sole non sono bastate. Il sito ora calcola da solo i segnali che il modello sbaglierebbe a dedurre, e gli spiega il resto con un vocabolario controllato frase per frase sul codice. Nell'ultimo giro di misura Claude è arrivato alla conclusione giusta in 30 risposte su 30.

Anche su ciò che lascia il sito la regola è diventata più semplice di una lista di parole vietate: verso l'esterno escono nomi di rotta, mai un URL o il valore di un parametro. Qui racconto le misure, gli errori che ho trovato per strada, le domande che si possono fare e che cosa serve per collegare un agente al proprio sito.

Che cos'è Native Observability via MCP?

native_observability_mcp è un sottomodulo di Native Observability che dà a un agente AI, come Claude Desktop o Claude Code, accesso in sola lettura ai dati di prestazione di un sito Drupal 11. È incluso nella release stabile del modulo, oggi la 2.2.0. Il Model Context Protocol è lo standard con cui un agente chiede a un server esterno quali strumenti offre e li usa. Il sottomodulo si appoggia a MCP Server (si apre in una nuova scheda), installato su 3198 siti, e a Simple OAuth (si apre in una nuova scheda) per l'accesso.

I dati restano nel database del sito. L'agente li chiede uno strumento alla volta, e al grado 1 gli strumenti rispondono con dati aggregati per nome di rotta: tempi, richieste, motivi per cui una pagina non va in cache, query lente con la rotta che le ha lanciate.

Perché i numeri da soli non bastano a un agente AI?

Un modello che riceve solo i numeri li legge con il buon senso, e il buon senso sulle metriche di prestazione di Drupal sbaglia in punti precisi. Ne ho misurati tre:

• Il p95 su più finestre. Il modulo calcola il p95 di una rotta per finestre di 5 minuti. Su un periodo più lungo restituisce il valore più alto fra quelle finestre, che è un tetto e non il p95 esatto del periodo. Senza spiegazioni il modello a volte lo prende per esatto: 2 risposte su 5 nel primo giro.
• La page cache. Una pagina servita dalla page cache riceve risposta prima che Drupal arrivi al routing, quindi non conta fra le richieste della rotta. Se la cache serve più pagine, le richieste della rotta scendono anche quando i visitatori aumentano.
• Le pagine escluse. Il titolare può escludere degli URL dalla registrazione. Per quegli URL non c'è nessun dato, e «nessun dato» non vuol dire «nessuna visita».

Nella mia prova, con il vocabolario spento, Claude ha indicato per una pagina esclusa un tetto di 10 richieste preso dal conteggio della sua rotta, che le richieste escluse non le contiene, in 2 risposte su 5: le richieste ricevute erano 15. Confrontando due settimane, non ha mai detto che i dati per rotta restano solo 7 giorni.

Come fa il sito a far leggere i dati nel modo giusto?

Il sito fa due cose: calcola da solo i segnali che il modello sbaglierebbe a dedurre, e gli manda un vocabolario che spiega come leggere il resto, verificato frase per frase sul codice. Ci sono arrivato in tre giri di misura.

Nel primo giro c'era solo il vocabolario. Su una domanda, un calo di richieste causato dalla page cache, Claude ha sbagliato più spesso con il vocabolario che senza: 4 risposte su 5 lo leggevano come traffico perso. La regola c'era, ma il modello non la collegava al calo che aveva davanti.

Nel secondo giro ho spostato il collegamento nei dati. Quando confronta due periodi, lo strumento riporta le risposte della page cache in ciascuno e, se il calo di una rotta coincide con un loro aumento, lo segnala con possible_cause: page_cache. Sono valori calcolati dal sito, uguali per ogni modello. Il calo letto come traffico perso è sceso a 0 su 5.

Nel terzo giro ho confrontato ogni frase del vocabolario con il codice. Su 133 punti controllati, 15 frasi erano false e 28 ambigue, e sono emersi tre difetti che falsavano i conteggi senza segnalarlo. Dopo la correzione, con il vocabolario, Claude è arrivato alla conclusione giusta in tutte le risposte.

Il segnale calcolato corregge il calo anche con il vocabolario spento: 0 risposte sbagliate su 5. Il vocabolario fa la differenza sulle altre domande. Senza, sulla pagina esclusa Claude arriva alla conclusione giusta 3 volte su 5 e sulla settimana mai. Con il vocabolario, 5 volte su 5 in entrambe.

Ogni risposta è stata valutata da un secondo modello, Claude Opus 5.5, che non sapeva in quale condizione era stata scritta e doveva citare la frase esatta di ogni errore. Le risposte erano di Claude Sonnet 5.5, collegato solo al server MCP del sito di prova.

Quali domande si possono fare all'agente?

Con Native Observability collegato, a Claude si fanno domande in linguaggio naturale e lui sceglie gli strumenti da chiamare. Queste domande ricalcano quelle che ho fatto sul sito di prova, con quello che restituiscono.

Ho fatto la domanda della dashboard a Claude Desktop. Il registro delle chiamate del sito mostra che Claude ha letto il vocabolario, ha usato da solo quattro strumenti di dati e poi ha chiesto le rotte giorno per giorno. Sul sito di prova la rotta più lenta per p95 era eval.search, con 900 ms di p95 e 260 ms di media su 960 richieste. Sono righe del sito di prova, in parte scritte a mano: mostrano il percorso dalla domanda al dato, non le prestazioni di un sito vero.

Chi decide quali dati escono dal sito?

L'amministratore del sito sceglie quali dati escono, con il grado di esposizione che si imposta nelle impostazioni di Native Observability, scheda «External exposure» (/admin/config/development/native-observability/exposure). Il grado vale per tutti i client collegati:

• Grado 0, il valore di partenza: nessuno strumento di dati risponde.
• Grado 1: rispondono solo gli strumenti aggregati per nome di rotta, senza percorsi, visitatori o indirizzi IP.
• Grado 2: anche le singole richieste, con rotta, stato, tempi, nomi dei parametri senza i valori e classe dell'eccezione. Per attivarlo l'amministratore conferma una dichiarazione, che resta registrata. Il client deve poi rifare il login chiedendo lo scope delle singole richieste, con un utente che abbia il permesso di vederle.

Perché dal sito non esce nessun URL?

Nessun URL esce dal sito, a nessun grado: MCP, OpenTelemetry e Prometheus portano solo il nome macchina della rotta. All'inizio mi affidavo a una lista di nomi sensibili, come token e password, ma una lista non riconosce un segreto sotto una chiave qualsiasi come xw=. La security review ha mostrato che le fughe passavano da dove non guardavo: l'hash di un link di reset con lo slash finale o il prefisso di lingua, il Referer nel messaggio di un 404.

Così ho tolto il problema alla radice. Il percorso non esce più, dei parametri restano solo i nomi e dell'eccezione solo la classe. Ho rifatto la prova con valori sentinella in tutti quei punti: nessuno è uscito dagli strumenti MCP. Il dettaglio completo resta nel database del sito, dove lo vede l'amministratore.

Nessuno strumento scrive: grado, cattura ed esclusioni si cambiano solo dall'interfaccia di Drupal. Un client che si registra da solo resta in attesa finché un amministratore non lo approva dalla scheda MCP, la pagina di consenso mostra che cosa potrà leggere, e ogni chiamata finisce in un registro. Claude Desktop ha provato anche a leggere le singole richieste: il sito era al grado 1 e lo strumento ha risposto con un rifiuto, registrato nel registro delle chiamate.

Quali moduli servono per collegare un agente?

Per far rispondere l'agente sulle rotte bastano tre sottomoduli: native_observability, native_observability_metrics e native_observability_mcp, insieme ai moduli contrib MCP Server (con MCP Server Tool Bridge e MCP Server OAuth), Tool e Simple OAuth (con Simple OAuth 2.1). La ricetta native_observability_mcp del modulo installa da sola lo stack dell'agente.

La dashboard non serve all'agente: il sottomodulo MCP non dipende da lei, e si porta dietro sottomoduli che registrano dati e costano. L'elenco completo è nella documentazione di installazione (si apre in una nuova scheda).

Quanto rallenta il sito il modulo stesso?

Sul sito di prova, con tutti i sottomoduli accesi, il modulo aggiunge 8,1 ms a richiesta sulla home, da 23 a 31 ms: vale per quel sito, non per il tuo. L'agente legge la misura del proprio sito con lo strumento overhead_report, che restituisce l'ultima fatta dalla scheda «Overhead measurement», con la sua data. Se la misura non c'è, lo strumento lo dice e indica la pagina dove farla, senza stimare niente. Come si fa la misura l'ho raccontato in un articolo a parte.

Come si collega Claude Desktop a un sito Drupal?

Claude Desktop si collega con mcp-remote, un piccolo proxy che gira sul computer e apre il login di Drupal nel browser: approvazione dell'amministratore, consenso, e gli strumenti compaiono in Claude. Il connettore personalizzato di Claude Desktop si collega invece dai server di Anthropic, quindi richiede un sito raggiungibile da Internet con un nome DNS pubblico. La procedura passo per passo è nella guida allo stack minimo (si apre in una nuova scheda). Sui siti nuovi la registrazione dei client è chiusa: va aperta dalla scheda MCP, poi il primo client aspetta l'approvazione.

La prima prova si è fermata due volte: un client in attesa che si registrava di nuovo a ogni tentativo, e un login completato in due schede. Ho corretto entrambi i casi.

Poi ho fatto la prova che mancava: un Drupal vuoto, la guida seguita alla lettera da un agente che non aveva scritto il codice. Il codice ha retto, la guida no. Si è fermata quattro volte, e una era seria: raccomandava una versione di Simple OAuth bloccata da una security advisory. Ho corretto e rifatto la prova tre volte: al terzo giro mancavano ancora un permesso e una password, e sono gli ultimi due passi che ho aggiunto. La stessa prova sull'aggiornamento ha trovato un sito che con Cache Observer senza Spans non ripartiva più, con la pipeline tutta verde: i test automatici non potevano vederlo.

Quali sono i limiti di Native Observability via MCP oggi?

Il sottomodulo native_observability_mcp è sperimentale. Questi sono i limiti che conosco:

Fonti

1. Native Observability (si apre in una nuova scheda), progetto su drupal.org, e la sua documentazione (si apre in una nuova scheda). Fonte primaria.
2. MCP Server (si apre in una nuova scheda), progetto su drupal.org. Fonte primaria.
3. Simple OAuth (si apre in una nuova scheda), progetto su drupal.org. Fonte primaria.
4. Model Context Protocol, Authorization: Client Registration (si apre in una nuova scheda). Fonte primaria.
5. Prove dell'autore sul sito di prova: tre giri di confronto alla cieca con e senza vocabolario, più una misura ripetuta su una domanda, controlli deterministici sul server, collegamento di Claude Desktop, installazioni da zero e aggiornamenti reali. Il repository di valutazione non è pubblico.