1.787 Server MCP Analizzati: Il 40% Può Distruggere Dati o Eseguire Comandi

PolicyLayer ha fatto quello che nessuno aveva ancora fatto: catalogare e classificare ogni singolo tool di ogni server Model Context Protocol pubblicamente raggiungibile. 25.329 tool. 1.787 server funzionanti. I numeri che ne escono non sono rassicuranti.

Quaranta percento di superficie distruttiva

Il 40% dei server MCP espone almeno un tool capace di cancellare dati o lanciare comandi arbitrari. Se il vostro stack usa cinque server MCP, la probabilità che almeno uno possa fare danni irreversibili è del 92%. A dieci server siete al 99%.

E qui viene il bello: il 96,8% di questi tool non avvisa l’agente di quello che sta per fare. Nessun “sei sicuro?”. Nessun “questa operazione è irreversibile”. Il modello vede una lista piatta di funzioni, sceglie quella che semanticamente sembra giusta per il task, e la chiama. Se il task era “pulisci le righe duplicate” e il tool si chiama delete_rows, boom.

Un server MCP medio? 14,4 tool

La mediana è 7 tool per server. La media sale a 14,4. Il 99° percentile? 122 tool. Il campione assoluto è io-fusionauth-mcp-api con 310 tool esposti contemporaneamente.

Fate i conti: 310 schemi di tool che competono per spazio nel context window prima ancora che l’utente abbia digitato una parola del task vero. Nessun essere umano legge 310 descrizioni prima di installare. Il modello le vede tutte, sempre, per default.

Quando MCP tocca i soldi

Solo 60 server nel dataset gestiscono operazioni finanziarie — pagamenti, trasferimenti, wallet. Rari, sì. Ma combinati male: il 46,7% di questi server espone anche tool distruttivi. Il 71,7% espone tool distruttivi o di esecuzione arbitraria.

Il peggiore della lista? 12 tool distruttivi più 15 tool finanziari. 27 modi diversi di rompere qualcosa irreversibilmente o spostare denaro, in un singolo install MCP. E il modello deve scegliere quello giusto ogni volta, basandosi su descrizioni che nel 96,8% dei casi non contengono warning.

I registry ufficiali non sono più sicuri

Aspettativa comune: i listing “ufficiali” sono curati, quindi più sicuri. Realtà: il peso di rischio medio per tool varia pochissimo tra fonti. Anzi, i server aggiunti manualmente a mano per fare bootstrap dell’ecosistema (seed-listed) sono il gruppo a rischio più alto.

Nessun registry filtra per categoria di tool, parametri pericolosi, o presenza di path di scrittura non confermati. Il listing è curazione solo per nome. La valutazione del rischio è lasciata al developer che installa.

CRUD ovunque, delete in pole position

I sei verbi più comuni nell’ecosistema MCP dopo get e list sono create, search, update, delete. Due dei top sei sono mutazioni che il modello non può annullare. Il protocollo non fornisce alcuna separazione tra loro.

delete_* appare 321 volte. Praticamente un tool dal nome distruttivo ogni cinque server, prima ancora di contare quelli distruttivi senza usare la parola (“drop”, “remove”, “wipe”, “purge”). La forma del verbo è il segnale più economico su cui un client potrebbe agire. Niente in MCP obbliga i client a usarlo. Quindi non lo fanno.

Il trust boundary è la buona volontà dello sviluppatore

MCP spec non include autorizzazione built-in, rate limit, spend cap, audit trail. I server espongono quello che i loro autori hanno deciso di esporre, nella forma che hanno scelto, con la descrizione che hanno scritto. I client passano liste di tool ai modelli senza filtri forzati. I modelli chiamano tool con gli argomenti che ritengono appropriati.

Il confine di fiducia è la moderazione dello sviluppatore quando scrive il server. Punto.

La maggior parte dei team non shipperebbe mai un’API interna dove ogni endpoint è non autenticato e non categorizzato, dove 1 su 4 endpoint può cancellare dati in produzione, e dove il 96,8% degli endpoint non ha documentazione sugli effetti collaterali. Questo è il server MCP mediano oggi.

La fix non è bannare i tool distruttivi

La soluzione vera è enforcement al livello di trasporto: ogni chiamata a tool valutata contro una policy deterministica prima che raggiunga il server. PolicyLayer fa esattamente questo — un gateway davanti a ogni server MCP della vostra fleet, con OAuth gestito, policy editor che scopre i tool di ogni server e permette di filtrare per categoria (destructive, financial, execute), grant per-agent sganciati dall’identità utente, audit log per-chiamata con argomenti completi e outcome.

Il dataset completo è pubblicato come open dataset su Hugging Face sotto CC-BY-4.0: huggingface.co/datasets/PolicyLayer/mcp-server-catalogue. Caricabile via load_dataset("PolicyLayer/mcp-server-catalogue"). Edizioni mensili taggate (corrente: 2026-05).