Server MCP di terze parti: 7 controlli prima di adottarli

Un server MCP di terze parti è un fornitore di tool di cui l'agente AI si fida per impostazione: descrive da sé i propri tool, il modello legge quelle descrizioni come istruzioni e, se il server gira in locale, ha gli stessi accessi del tuo account. Alla fine di questa guida avrai sette controlli da fare su qualsiasi server MCP che non hai scritto tu, una configurazione con le versioni fissate, un'impronta della lista dei tool di ogni server che ti avvisa quando cambia e un'allowlist che decide quali server possono raggiungere gli agenti.

L'offerta è enorme e nessuno la controlla. Il 2 novembre 2026 abbiamo contato il registro ufficiale MCP tramite la sua API pubblica: 54.599 server nella versione più recente, 53.756 attivi e 843 deprecati. 36.418 indicano un endpoint remoto, 21.864 un pacchetto da installare. Il registro verifica una cosa sola: chi può pubblicare sotto un certo nome. La sua documentazione lo dice chiaramente: si occupa dell'autenticazione dei namespace e dei metadati, e lascia l'analisi del codice a npm, PyPI, Docker Hub e ai marketplace costruiti sopra. Essere in elenco dimostra che chi pubblica controlla un account GitHub o un dominio. Su cosa faccia il codice, non dice niente.

Quel vuoto qualcuno l'ha già sfruttato. A settembre 2025 Koi Security ha scoperto postmark-mcp, un pacchetto npm che copiava il server MCP di Postmark: quindici versioni pulite, poi una riga sola nella 1.0.16 che mandava in copia nascosta ogni email a un indirizzo esterno. Secondo The Register, nell'ultima settimana online era stato scaricato circa 1.500 volte.

Cosa ti serve prima di cominciare

• L'elenco dei server MCP configurati oggi in ogni client che usa il team: Claude Code, Claude Desktop, Cursor, VS Code, gli agenti interni. I server che nessuno ha approvato sono un rischio a sé; l'OWASP MCP Top 10 li chiama MCP09, Shadow MCP Servers.
• Per ogni agente, i dati che può raggiungere e le credenziali che ha.
• Un posto dove annotare le decisioni: un file in un repository o una pagina per server in un registro interno.
• L'MCP Inspector, o qualsiasi client che chiami tools/list e mostri la risposta così com'è.

Passo 1: verifica chi ha pubblicato il server

Ogni server del registro ufficiale ha un nome in formato DNS inverso. Un nome sotto io.github.username l'ha pubblicato chi controlla quell'account GitHub. Un nome come com.example/server è passato da una verifica DNS o HTTP su quel dominio. Nel nostro conteggio, 31.758 voci stanno sotto namespace GitHub e 22.841 sotto altri domini.

Controlla che tre cose coincidano: il nome nel registro, il repository del codice e l'identificativo del pacchetto che installerai davvero. postmark-mcp questo controllo non lo passa. Postmark pubblicava il suo server dal proprio repository GitHub; il pacchetto npm con lo stesso nome era di un altro. Scegli, quando c'è, il server pubblicato da chi fornisce il servizio. Se resta solo un server della community, leggi la cronologia dei commit e chi lo mantiene, e un cambio di proprietario recente trattalo come un server nuovo.

Passo 2: leggi ogni descrizione che leggerà il modello

Le descrizioni dei tool sono testo di prompt. L'utente vede il nome del tool; il modello legge la descrizione intera. Il 1° aprile 2025 Invariant Labs ha dimostrato che istruzioni nascoste in una descrizione possono spingere un agente a far uscire dati attraverso un altro server, di cui ci si fidava. OWASP lo chiama MCP03, Tool Poisoning.

Collega il server in un ambiente usa e getta, chiama tools/list e leggi il JSON grezzo: ogni descrizione, ogni descrizione dei parametri, ogni valore predefinito. Segna tutto quello che si rivolge al modello ("prima di usare questo tool", "non dirlo all'utente"), che nomina altri tool o altri server, o che chiede file e segreti di cui il tool non ha bisogno. Poi confronta i tool con quello che il server dice di fare. Un server meteo con un tool che legge i file locali ti ha già detto cos'è.

Passo 3: decidi dove gira e isola i server locali

Un server remoto gira sulle macchine di chi lo gestisce e arriva solo a quello che gli mandi e a quello che gli concedono gli scope OAuth. Un server locale è un altro rischio. La guida del progetto MCP sulla sicurezza dei server locali lo descrive come un normale processo figlio: eredita le variabili d'ambiente e legge tutto quello che il tuo account può leggere, dalle chiavi SSH alle credenziali cloud. La guida è esplicita: il trasporto stdio non è una sandbox, client e server stanno nello stesso dominio di fiducia.

Quindi, se il fornitore offre un endpoint remoto e i dati lo permettono, scegli quello. Quando un server deve girare in locale, mettilo in un container o in una VM, senza la home montata, con le sole variabili d'ambiente che gli servono e il traffico in uscita limitato agli host che deve chiamare. Per i server remoti, concedi gli scope OAuth più stretti e confrontali con MCP02 della lista OWASP, l'escalation dei privilegi per accumulo di scope.

Passo 4: fissa la versione esatta, mai latest

Quasi tutte le istruzioni d'installazione dicono npx -y pacchetto o uvx pacchetto, senza versione. Così a ogni avvio il client scarica l'ultima uscita: una 1.0.15 pulita diventa una 1.0.16 con la backdoor senza che nessuno l'abbia deciso. Scrivi la versione esatta nella configurazione del client (pacchetto@1.4.2, o l'immagine del container per digest), fai il commit del lockfile e, quando chi pubblica la fornisce, controlla la provenienza: le provenance statement di npm collegano un pacchetto pubblicato al commit e alla build da cui è nato.

Il registro fa la sua parte. Le sue regole di versioning chiedono una stringa di versione unica per ogni pubblicazione, bloccano i metadati una volta pubblicati e rifiutano gli intervalli come ^1.2.3. Fissare le versioni ha un costo: gli aggiornamenti diventano compito tuo. Dai a ogni server un responsabile e una data di revisione. Un server remoto, invece, non si può fissare: chi lo gestisce rilascia quando vuole. Il passo successivo serve a questo.

Passo 5: registra l'impronta dei tool e riapprova a ogni cambio

Un pacchetto con la versione fissata blocca il codice che esegui. Non blocca quello che un server remoto dice di sé, e il protocollo gli lascia annunciare nuove definizioni dei tool in qualsiasi momento con notifications/tools/list_changed. Invariant Labs chiama rug pull l'abuso di questo meccanismo: un tool approvato pulito cambia dopo l'approvazione.

Difendersi costa poco. Al momento dell'approvazione salva la risposta di tools/list, normalizzala (chiavi ordinate, niente spazi) e conserva l'hash SHA-256 accanto alla decisione. A ogni avvio di sessione, e a ogni notifica list_changed, ricalcolalo e confrontalo. Se l'hash è diverso, il server resta bloccato finché una persona non legge le differenze. Quasi sempre saranno tool nuovi e innocui. I pochi casi che non lo sono giustificano il controllo.

Passo 6: controlla anche i connettori lato client

Il server non è l'unica dipendenza. Anche i bridge e i proxy che collegano un client ai server remoti girano sulla tua macchina. Il 9 luglio 2025 JFrog ha reso nota la CVE-2025-6514 in mcp-remote, un bridge molto diffuso: un server malevolo poteva rispondere alla fase di autorizzazione con un URL costruito ad arte che eseguiva comandi sulla macchina collegata. Punteggio CVSS 9,6, versioni colpite dalla 0.0.5 alla 0.1.15, corretta nella 0.1.16.

Metti questi pacchetti nello stesso inventario dei server, fissane la versione e iscriviti ai loro avvisi di sicurezza. Un server affidabile, raggiunto da un bridge mai aggiornato, resta una porta aperta.

Passo 7: fallo passare da un'allowlist, con log e una via d'uscita

L'ultimo controllo trasforma i sei precedenti in una regola.

• Un'allowlist dei server e delle versioni approvate, l'unica fonte che i client leggono. Il registro pubblica una specifica OpenAPI che anche i registri privati possono implementare, così l'elenco interno risponde nella stessa forma di quello pubblico.
• Un gateway che registra ogni chiamata ai tool, con i suoi argomenti. Un'azione dell'agente che non puoi ricostruire è un'azione su cui non puoi indagare; OWASP chiama questa lacuna MCP08, Lack of Audit and Telemetry.
• Credenziali separate per ogni server, mai un token da amministratore condiviso, così se ne revochi una le altre continuano a funzionare.
• Una via d'uscita scritta: quali righe di configurazione togliere, quali chiavi ruotare, chi avvisare.

Gateway e audit li trattiamo nel dettaglio in come blindare un server MCP per l'enterprise.

Come verificare che funziona

1. Ogni server configurato in ogni client compare nell'allowlist con un responsabile, una versione fissata e una data di revisione.
2. Una configurazione con latest, un npx -y senza versione o un tag d'immagine senza digest fa fallire il controllo in CI.
3. Se cambi un solo carattere nella descrizione di un tool di un server di prova, al prossimo avvio di sessione il server viene bloccato.
4. Una chiamata ai tool da qualsiasi agente compare nel log del gateway, con gli argomenti, entro un minuto.
5. Revocando le credenziali di un server, tutti gli altri continuano a funzionare.

Errori frequenti e come risolverli

• L'hash cambia a ogni avvio. Alcuni server generano le descrizioni con timestamp o in ordine casuale. Normalizza prima di calcolare l'hash; se il server continua a cambiare, segnalalo a chi lo mantiene o sostituiscilo.
• Gli sviluppatori aggiungono server in locale e saltano la revisione. Sulle macchine gestite fai dell'allowlist l'unica configurazione che i client caricano, e cerca i file di configurazione MCP che l'elenco non conosce.
• Il fornitore non ha un endpoint remoto e il server locale vuole accesso ampio ai file. Monta solo la cartella su cui lavora, in sola lettura dove puoi, e rivedi quel server più spesso degli altri.
• Gli aggiornamenti si accumulano perché, con le versioni fissate, sono manuali. Raggruppali una volta al mese: leggi insieme il changelog e le differenze nella lista dei tool, poi aggiorna.

Per andare oltre

La verifica è una parte del lavoro di chi usa MCP in produzione. Per capire cos'è il protocollo e quando un SaaS ha bisogno di un server suo, leggi cos'è MCP e perché il tuo SaaS ha bisogno di un server MCP. Se lo stesso server di terze parti non passa mai la revisione, scriverne uno può costare meno: ne parliamo in build vs buy per i server MCP. Su chi decide come cambia il protocollo, vedi la governance di MCP nel 2026.