Un server MCP locale e uno remoto, una volta in funzione, sembrano identici: stesso elenco di strumenti nel client, stessa conversazione, stesso risultato. La differenza sta in ciò che si è consegnato per arrivarci. Un server locale è un programma sulla propria macchina che il client avvia e con cui parla tramite standard input e output, e ciò che si consegna è una riga di comando. Un server remoto è l'endpoint HTTPS di qualcun altro, e ciò che si consegna è una credenziale — insieme a tutto quello che apre, per tutto il tempo in cui la si lascia in vita.
La domanda utile prima di incollare un URL nella finestra di un connettore non è quindi «questo server è affidabile», a cui nessuno può rispondere leggendo una scheda. Sono tre domande più strette, che una risposta consultabile ce l'hanno: a che cosa è limitato il token, dove si va a riprenderselo e che cosa ha davvero verificato il catalogo in cui si è trovato il server. Le risposte qui sotto si basano sulla specifica MCP e sulla documentazione dei fornitori nello stato in cui si trovavano il 16 agosto 2026.
La revisione corrente della specifica, 2026-07-28, tratta i due trasporti come contesti di sicurezza diversi. L'autorizzazione in MCP è facoltativa, e dove si applica è detto esplicitamente: le implementazioni che usano un trasporto HTTP dovrebbero conformarsi alla specifica OAuth, mentre le implementazioni stdio non dovrebbero seguirla affatto e recuperare invece le credenziali dall'ambiente. HTTP+SSE, il vecchio trasporto remoto, è deprecato; quello da attendersi è Streamable HTTP.
| Locale (stdio) | Remoto (Streamable HTTP) | |
|---|---|---|
| Che cosa si consegna | Un comando che il client eseguirà | Un URL e di solito una concessione OAuth |
| Dove gira il codice | La propria macchina, il proprio account utente | Infrastruttura gestita da qualcun altro |
| Credenziali | Prese dall'ambiente | Token di accesso legato a quel solo server |
| Che cosa fa «disconnect» | Smette di avviare un processo | Cancella la copia del token nel client; la concessione può sopravvivere |
| Caso peggiore se l'autore è ostile | Codice arbitrario con i propri privilegi | Tutto ciò che gli scope approvati raggiungono |
Nessuna delle due colonne è quella sicura. Un server locale è codice arbitrario che gira con la propria identità — ed è esattamente per questo che la specifica richiede che un client il quale offra la configurazione locale con un clic mostri il comando esatto che eseguirà, senza troncarlo, e ottenga prima un'approvazione esplicita. Un server remoto non mette codice sulla macchina, ma sposta i dati verso un operatore e lascia un percorso di accesso che sopravvive all'attenzione di chi l'ha aperto. I due falliscono in direzioni diverse; il nostro confronto su che cosa vede ciascun tipo lo esamina più da vicino.
Il modello di autorizzazione è OAuth 2.1, e la parte che conviene capire da
utenti è il vincolo di destinatario. I client devono implementare Resource
Indicators for OAuth 2.0 (RFC 8707): il parametro resource va inviato sia
nella richiesta di autorizzazione sia in quella del token, e nomina il server
specifico a cui il token è destinato. I server devono verificare che i token
siano stati emessi per loro, accettare solo token validi per le proprie risorse
e non devono accettare né far transitare gli altri. Passare il token di un
client a un'API a valle — il «token passthrough» — è vietato senza eccezioni.
Un token implementato correttamente, quindi, è inutile presso un altro server. Questo chiude il replay, il riuso delle credenziali tra servizi e una classe di attacchi confused deputy — e non dice nulla sull'operatore. Il vincolo di destinatario dice dove funziona il token, non che cosa faccia l'azienda all'altro capo con ciò che i suoi strumenti recuperano per conto di chi li usa. A quello risponde la sua informativa sulla privacy, non il protocollo.
Sono gli scope a decidere davvero l'esposizione. La specifica spinge i server
verso il privilegio minimo: scopes_supported dovrebbe essere l'insieme minimo
necessario alle funzioni di base, e tutto il resto va richiesto in modo
incrementale quando si tenta per la prima volta un'operazione privilegiata. I
server che lo rispettano chiedono poco in partenza; quelli che non lo fanno
mostrano una sola schermata di consenso che elenca tutto. Quella schermata è
l'ultimo punto in cui la decisione resta nelle proprie mani.
Le superfici di revoca sono due, e di solito si usa solo la prima.
Nell'assistente. In Claude i connettori personalizzati stanno sotto Customize > Connectors, dove se ne aggiunge uno incollando l'URL del server; sul piano Free se ne può avere uno solo. È la stessa pagina da cui si disconnette e da cui si abilitano o disabilitano i singoli strumenti del server invece di accettarli tutti. Anthropic dichiara la posizione sulla fiducia senza giri di parole nel proprio centro assistenza: i connettori personalizzati collegano Claude a servizi arbitrari che Anthropic non ha verificato. In ChatGPT i server remoti arrivano attraverso la modalità sviluppatore — Settings → Security and login, sul web, con endpoint SSE e streaming HTTP. La documentazione di OpenAI la definisce potente ma pericolosa, indica tra i rischi il prompt injection e le azioni di scrittura distruttive, e per impostazione predefinita richiede conferma per le azioni di scrittura.
Presso il servizio con cui si è autorizzato. È quella che si salta. Cancellare il connettore rimuove la copia del token nel client; la concessione registrata nell'account Google, GitHub, Atlassian o Notion è un oggetto separato con una vita propria, e un refresh token collegato può sopravvivere al connettore di parecchio. Le indicazioni di Anthropic dicono proprio questo — revocare disconnettendo il connettore nelle impostazioni di Claude oppure nelle impostazioni di sicurezza del servizio di terze parti. Conviene fare entrambe le cose, e trovare quella pagina delle app collegate prima di collegarsi.
Il registry ufficiale MCP all'indirizzo registry.modelcontextprotocol.io è il
posto naturale dove cercare i server, ed è facile leggere in una voce più di
quanto ci sia. Lo statuto del suo gruppo di lavoro è preciso. Pubblicazione e
fiducia coprono i flussi di autenticazione — GitHub OAuth, GitHub OIDC, verifica
via DNS e HTTP — più la titolarità dei namespace, gli strumenti di moderazione e
le segnalazioni della comunità. Esplicitamente fuori ambito: classificare o
scegliere tra implementazioni di server MCP per conto dei client o degli utenti
finali, e ospitare, distribuire o eseguire il codice dei server, perché il
registry è un catalogo di metadati e non un registro di pacchetti.
Un namespace verificato dimostra quindi che chi ha pubblicato la voce controlla l'organizzazione GitHub o il dominio che compare nel nome. È un segnale reale: rende più difficile il typosquatting e dà qualcuno a cui chiedere conto. Non è una revisione del codice, non è un audit di sicurezza e non è un'approvazione — identità stabilita, comportamento ancora ignoto.
Un principio della specifica vale la pena portarselo dietro in ogni connessione: le descrizioni del comportamento degli strumenti, annotazioni comprese, vanno considerate non attendibili a meno che non provengano da un server attendibile, e gli host devono ottenere il consenso esplicito dell'utente prima di invocare qualsiasi strumento. La descrizione di uno strumento è testo che scrive una parte remota e che legge il proprio modello — la definizione di input non attendibile, e il motivo per cui «il server ha detto che era di sola lettura» non è un controllo di sicurezza.
Il precedente concreto è CVE-2025-6514, pubblicata il 9 luglio 2025 su
mcp-remote, il proxy che molti client usavano per raggiungere i server remoti.
Valutata 9,6, permetteva a un server malevolo di ottenere l'iniezione di comandi
di sistema sulla macchina che si collegava, attraverso un valore di
authorization_endpoint costruito ad arte nel flusso OAuth — con le versioni
dalla 0.0.5 alla 0.1.16 interessate e la correzione nella 0.1.16. In chat non
c'era nulla da approvare: collegarsi era l'intero attacco. Tutto ciò che un
server remoto invia è dato che il software di chi lo usa interpreta, e la
connessione stessa fa parte della superficie d'attacco.
Tutto quanto sopra è il prezzo per raggiungere qualcosa che vive davvero nel cloud di qualcun altro — il proprio issue tracker, il proprio CRM, il proprio calendario. È un prezzo ragionevole per quelli e strano per file che stanno già sul disco: per questo Speak-Y distribuisce un server locale e non un endpoint ospitato.
Il suo server MCP è un processo che il client avvia sulla macchina di chi lo
usa. Per leggere non serve nient'altro in esecuzione: risultati di ricerca,
trascrizioni, riassunti delle riunioni e action item arrivano direttamente dalla
libreria sullo stesso computer, senza alcun token emesso e senza relay nel
mezzo. I comandi che modificano qualcosa — assegnare tag a una registrazione,
dare un nome ai partecipanti, condividere in un canale di team — passano
dall'app in esecuzione, sono dichiarati al client come modificanti perché chieda
conferma, e vengono registrati dove è anche possibile spegnerli. Aggiungere
--read-only agli argomenti del server significa che i comandi che modificano
non vengono proprio pubblicati verso quel client — una garanzia più forte di una
descrizione che promette buona condotta. L'installazione è un clic da
Impostazioni → Integrazioni, gratuita su ogni piano incluso Free.
Il compromesso vale in entrambe le direzioni: un server locale non può servire ChatGPT in una scheda del browser, e gira solo dove gira l'app. Se quel vincolo pesa, quali client sanno avviare un server locale è il confronto da leggere subito dopo — e se la domanda è che cosa un assistente possa modificare una volta collegato, dove passa la linea sull'accesso in scrittura copre il tema. La panoramica su MCP elenca che cosa espone il server di Speak-Y.
Un server locale è un programma sulla propria macchina che il client avvia e con cui parla tramite standard input e output: ciò che si consegna è una riga di comando, e nessun token viene emesso. Un server remoto è un endpoint HTTPS gestito da qualcun altro: ciò che si consegna è una credenziale, di solito un token di accesso OAuth 2.1, e i dati toccati dagli strumenti viaggiano verso l'infrastruttura di quell'operatore.
Secondo la specifica di autorizzazione di MCP, il token è legato a un solo server e a un solo insieme di scope. I client devono inviare un resource indicator RFC 8707 che nomina il server sia nella richiesta di autorizzazione sia in quella del token, e il server deve verificare che i token siano stati emessi per sé — non deve accettare né inoltrare alcun altro token. Questo impedisce di riutilizzare il token presso un servizio diverso. Non dice nulla su che cosa faccia l'operatore con i dati che i suoi strumenti recuperano per conto di chi li usa.
In due posti, e di solito si fa solo il primo. Rimuovere il connettore nel proprio assistente cancella la copia del token nel client; la concessione OAuth registrata presso il servizio con cui si è autorizzato è un oggetto separato e di norma sopravvive. Le indicazioni di Anthropic dicono di revocare i permessi disconnettendo il connettore nelle impostazioni di Claude oppure nelle impostazioni di sicurezza del servizio di terze parti. Conviene trovare la pagina delle app collegate del fornitore prima di collegarsi, non dopo.
No. Il registry verifica la titolarità del namespace — un nome io.github.* attraverso l'autenticazione GitHub, un nome basato su dominio attraverso verifica DNS o HTTP — il che dimostra che chi pubblica controlla quel nome. Il suo statuto mette esplicitamente fuori ambito il classificare o scegliere tra implementazioni di server, e afferma che il registry è un catalogo di metadati e non un registro di pacchetti: non ospita, non distribuisce e non esegue il codice dei server.
Solo quelli che gli scope approvati raggiungono. Il rischio è che gli scope siano più ampi del compito: un token concesso su un'intera casella di posta o su un intero drive è disponibile a ogni strumento esposto da quel server, per tutta la vita della concessione. Conviene leggere la schermata di consenso invece della pagina di marketing, e usare i controlli per singolo strumento dove il client li offre — le impostazioni dei connettori di Claude permettono di abilitare e disabilitare i singoli strumenti, e la modalità sviluppatore di ChatGPT richiede conferma per le azioni di scrittura per impostazione predefinita.