Le parole locale e cloud vengono usate per i server MCP come se risolvessero la questione della privacy. Non è così. Rispondono con precisione a una sola domanda — dove gira il processo del server — e lasciano intatta quella che alla maggior parte delle persone interessa davvero: chi finisce per poter leggere i propri dati.
In breve: un server MCP locale tiene i dati fuori dall'infrastruttura del fornitore, non fuori dalla conversazione. Tutto ciò che l'assistente legge attraverso un server MCP, locale o cloud che sia, viene inviato al modello con cui si sta parlando. Il locale cambia chi conserva i dati e chi può raggiungerli. Non cambia che cosa vede il modello.
Questo articolo separa le due cose. Se il protocollo in sé è una novità, che cos'è un server MCP copre prima le basi.
La specifica MCP, revisione 2026-07-28, definisce esattamente due trasporti standard, e questi corrispondono con precisione alle due parole.
stdio — quello locale. Il client avvia il server MCP come sottoprocesso e i due dialogano attraverso l'ingresso e l'uscita standard di quel processo, un messaggio JSON-RPC per riga. Non c'è alcuna connessione di rete né alcuna porta. Quando il client termina, chiude il flusso di ingresso del server e il processo si spegne. È questo che significa in concreto «gira sulla propria macchina».
Streamable HTTP — quello nel cloud. Il server è un processo indipendente che
espone un unico endpoint HTTP, e ogni messaggio è un POST HTTP verso di esso. Il
client lo raggiunge in rete a un URL come https://mcp.example.com/mcp. È il
trasporto dietro ogni pulsante «collega l'account».
La distinzione è una scelta di distribuzione, non una differenza di capacità. La specifica è esplicita nel dire che la semantica del protocollo è identica su ogni trasporto: un trasporto definisce come i messaggi vengono impacchettati e consegnati, non che cosa significano. Uno strumento che legge le trascrizioni delle riunioni fa lo stesso lavoro in entrambi i casi.
È la domanda per cui le due parole di solito fanno da sostituto, e ha più di due risposte. Quattro soggetti possono potenzialmente leggere ciò che passa da una connessione MCP.
| Chi | Server locale (stdio) | Server cloud (HTTPS) |
|---|---|---|
| Il fornitore MCP | Non riceve i dati | Li conserva e serve ogni richiesta |
| Il fornitore del modello | Vede tutto ciò che l'assistente legge | Vede tutto ciò che l'assistente legge |
| L'app client IA | Li legge in locale per costruire il prompt | Lo stesso |
| Chi possiede il token | Non esiste alcun token da rubare | Raggiunge gli stessi dati finché non viene revocato |
La riga centrale è quella che sorprende, ed è identica nelle due colonne. Un server MCP non offre al modello un canale privato. Recupera del testo e lo passa al client, che lo inserisce nel prompt. Da quel momento i dati hanno lasciato la macchina, indipendentemente da dove girasse il server.
La prima e l'ultima riga sono il punto in cui il locale vince davvero. Con stdio non c'è alcun account, nessuna copia conservata sul disco di qualcun altro e nessuna credenziale che possa essere rubata o esposta in una violazione, perché non c'è nulla da autorizzare.
Le forme qui sono tre, non due, e i fornitori raramente isolano quella di mezzo.
Server cloud, dati nel cloud. Il fornitore ospita il server, lo si autorizza con OAuth nel browser e il client effettua una chiamata HTTPS ogni volta che gli serve qualcosa. È la forma naturale quando i dati risiedono già nel cloud di quel fornitore.
Processo locale, dati nel cloud. Il fornitore distribuisce un server da
eseguire per conto proprio — un comando npx, uvx o docker avviato dal
client IA, che custodisce una chiave API. Nulla di tutto ciò rende locali i
dati. Il processo gira sul portatile e poi chiama l'API del fornitore attraverso
la rete a ogni richiesta. È il caso da escludere quando qualcuno dice che il suo
server MCP è locale.
Processo locale, dati locali. I dati si trovano già sulla macchina, così il server li legge senza alcuna chiamata di rete. È l'unica forma in cui «locale» descrive i dati e non soltanto il processo.
L'indizio sono le credenziali, non il comando. Un accesso dal browser significa che i dati sono del fornitore ed è lui ad autorizzarne l'uso. Una chiave API incollata in un file di configurazione significa che un processo locale chiama la sua API per conto dell'utente. Né l'uno né l'altro sono dati locali.
Quando si passa per una schermata OAuth di un server MCP nel cloud, si sta emettendo una credenziale sul proprio account, e vale la pena sapere che cosa può fare.
La specifica MCP costruisce tutto questo su OAuth 2.1. I client devono inviare
il parametro resource di
RFC 8707 affinché il token sia
legato a un server specifico, e i server devono verificare che un token sia
stato emesso per loro e non devono accettare né inoltrare nient'altro. Quel
meccanismo esiste per impedire che un token emesso per un servizio venga
riutilizzato contro un altro.
Tre conseguenze pratiche:
Nulla di tutto ciò vale per stdio. La specifica di autorizzazione dice esplicitamente di coprire i trasporti basati su HTTP e che le implementazioni che usano stdio non dovrebbero seguirla, prendendo invece le credenziali dall'ambiente.
Locale non è sinonimo di sicuro, e la versione onesta di questo ragionamento deve dire che cosa si perde.
Di solito non c'è alcun livello di permessi. Poiché la specifica di autorizzazione non si applica, un server stdio in genere non ha alcuna nozione di utenti o scope. Qualsiasi cosa giri con la propria utenza può di norma avviarlo e richiamarne gli strumenti. Su una macchina condivisa o gestita da altri, questo conta.
Un server locale in ascolto su una porta è un altro animale. Alcuni server
descritti come locali in realtà restano in ascolto su HTTP. La specifica
affronta il punto direttamente: i server devono verificare l'intestazione
Origin per prevenire attacchi di DNS rebinding e, quando girano in locale,
dovrebbero associarsi solo a 127.0.0.1 e non a 0.0.0.0. Senza queste
protezioni, avverte la specifica, un attaccante potrebbe usare il DNS rebinding
per interagire con server MCP locali da siti web remoti.
Si eredita la catena di fornitura. Un server avviato con npx scarica ed
esegue codice sulla macchina con i permessi dell'utente. La
OWASP MCP Top 10, in beta nel 2026,
elenca fra le sue dieci categorie gli attacchi alla catena di fornitura e la
manomissione delle dipendenze (MCP04:2025) e il tool poisoning (MCP03:2025):
rischi che un'installazione locale porta con sé e un endpoint ospitato no. Sul
caso generale la specifica è netta: gli strumenti rappresentano esecuzione di
codice arbitrario, e le descrizioni del comportamento di uno strumento vanno
considerate inaffidabili a meno che non provengano da un server fidato.
MCP non aggiunge un modello di permessi ai dati. Standardizza il modo in cui gli strumenti vengono descritti e richiamati; che cosa un dato strumento possa toccare è una decisione presa da chi ha scritto il server. Ne discendono due cose, qualunque sia il trasporto:
Quattro domande, con risposta ricavabile in un minuto dalla pagina di configurazione di qualsiasi fornitore.
https:// è un server nel cloud.
Un comando npx, uvx o docker è un processo sulla propria macchina.Detto chiaramente, perché la scelta non è a senso unico:
Il cloud perde su un solo asse, ma è l'asse di cui parla questo articolo: una copia dei dati risiede sull'infrastruttura di qualcun altro, raggiungibile con una credenziale.
Conviene porre due domande invece di una. Dove gira il server dice chi conserva i dati e chi può raggiungerli con un token. Che cosa legge l'assistente dice che cosa arriva al fornitore del modello, e quella risposta è la stessa in entrambi i casi.
Se la forma desiderata è processo locale su dati locali, è ciò che fa il
server MCP di Speak-Y: fa parte dell'app desktop, si installa in un clic
da Impostazioni → Integrazioni e legge le registrazioni già presenti sulla
macchina, senza account, senza chiave API e senza copia ospitata. La lettura
funziona anche ad app chiusa; gli strumenti che modificano qualcosa passano
dall'app e chiedono conferma, e l'opzione --read-only limita un client alla
sola lettura. Il server è incluso in ogni piano. La documentazione
MCP descrive la configurazione manuale, l'informativa sulla
privacy dichiara che cosa viene conservato e dove, e per vedere come
altri strumenti di note rispondono alla stessa domanda abbiamo confrontato i
loro server MCP.
Un server locale è un programma che il client IA avvia sul computer dell'utente e con cui dialoga tramite l'ingresso e l'uscita standard del processo, senza alcuna rete di mezzo. Un server cloud è un servizio web che il client raggiunge via HTTPS, autorizzato con OAuth. La specifica MCP li chiama trasporti stdio e Streamable HTTP.
No. Un server locale tiene i dati fuori dai server del fornitore, ma tutto ciò che l'assistente legge attraverso di esso viene inviato al fornitore del modello come parte della conversazione, esattamente come se lo si fosse incollato a mano. Il locale governa archiviazione e accesso, non che cosa vede il modello.
È più riservato, ma non automaticamente più sicuro. La specifica di autorizzazione MCP vale solo per i trasporti HTTP; ai server stdio si raccomanda invece di prendere le credenziali dall'ambiente, quindi un server locale di solito non ha un proprio livello di permessi. Di norma può raggiungerlo qualsiasi cosa giri con la propria utenza.
Dalle istruzioni di configurazione. Un URL https:// e un accesso dal browser indicano il cloud del fornitore. Un comando come npx, uvx o docker indica un processo sulla propria macchina. Un processo locale che custodisce una chiave API chiama comunque l'API del fornitore, quindi il comando da solo non dice dove risiedono i dati.
Claude Desktop avvia i server locali direttamente, installati come estensioni desktop. ChatGPT si collega a endpoint HTTPS remoti in modalità sviluppatore, quindi un server stdio locale va prima esposto attraverso un tunnel. Lo stesso server può dunque essere locale su un client e remoto su un altro.