L'app desktop di ChatGPT può dialogare con un server MCP in esecuzione sulla propria macchina; ChatGPT nel browser no. Questa sola distinzione decide tutto il resto della pagina, ed è la parte che la maggioranza delle guide sbaglia, perché è cambiata dopo la prima ondata di connettori di ChatGPT.
Secondo la documentazione MCP di OpenAI (verificata il 12 agosto 2026), l'app desktop, Codex CLI e l'estensione per IDE supportano due tipi di server: i server STDIO, processi locali avviati da un comando, e i server streamable HTTP, che vivono a un indirizzo. I tre client condividono un unico file di configurazione, quindi un server aggiunto una volta è disponibile in tutti. ChatGPT sul web è un'altra storia: può usare strumenti remoti basati su MCP forniti dai plugin, e una normale conversazione web non ha alcuna via verso qualcosa in esecuzione sul portatile.
Questa guida copre il percorso desktop dall'inizio alla fine — dove si trova la configurazione, come aggiungere un server locale, che cosa controllano davvero le modalità di approvazione e i limiti da conoscere prima di puntare un assistente sui propri file.
Conviene tenere a mente due modelli distinti.
L'app desktop è il client locale. La sua configurazione MCP sta nel file di
Codex, ~/.codex/config.toml, e accetta comandi locali. È la via per tutto ciò
che legge file, database o librerie di applicazioni sulla propria macchina.
L'app web è il client remoto. La sua storia MCP passa dai plugin e, per lavorare in prima persona con i propri server, dalla modalità sviluppatore — una beta che OpenAI descrive come supporto MCP completo per tutti gli strumenti, in lettura e in scrittura. È disponibile sul web per gli account Pro, Plus, Business, Enterprise ed Education, e si attiva in Settings → Security and login di ChatGPT. La modalità sviluppatore parla SSE e streaming HTTP. Non ha alcuna nozione di processo locale, quindi un server sul proprio portatile ha bisogno di un endpoint HTTPS pubblico prima che l'app web possa vederlo — per un archivio personale, di solito un cattivo compromesso.
Se i dati sono locali, si usa l'app desktop. È quello che fa il resto di questa guida.
Tre percorsi equivalenti; si scelga quello che risulta meno macchinoso.
Dall'interfaccia. Si apre Settings → MCP servers, si sceglie Add server, si assegna un nome, si seleziona STDIO e si inserisce il comando che avvia il server. Si salva, poi si seleziona Restart.
Dal terminale. Codex aggiunge la stessa voce:
codex mcp add <server-name> -- <command>
Modificando il file. ~/.codex/config.toml accetta una tabella per server:
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
Qualunque percorso si scelga, la voce finisce nello stesso posto, e la
raccolgono anche Codex CLI e l'estensione per IDE. Per confermare che il server
sia davvero partito, si digita /mcp nel campo di composizione: i server
collegati sono elencati lì. Come per
Claude Desktop e Claude Code,
il riavvio non è facoltativo: il client legge la propria configurazione MCP
all'avvio.
Speak-Y include un server MCP dentro l'app macOS, ed è gratuito in ogni piano,
incluso il piano Free. Dal lato Speak-Y si apre Impostazioni → Integrazioni.
Claude Desktop, Claude Code e Cursor hanno lì un Install in un clic, perché
la loro configurazione è JSON e l'app può fondersi con essa in sicurezza.
Quella di OpenAI non è JSON, quindi la voce OpenAI Codex CLI offre invece
una Setup guide e un pulsante Copy values — due righe da incollare
sotto [mcp_servers.speaky] in ~/.codex/config.toml:
[mcp_servers.speaky]
command = "/Applications/Speak-Y.app/Contents/MacOS/Speak-Y"
args = ["--mcp"]
La scheda dice Codex CLI e non ChatGPT per un motivo che vale la pena interiorizzare: il file è uno solo, e l'app desktop lo legge. Si incollano i valori una volta e le trascrizioni sono disponibili allo stesso modo nell'app desktop di ChatGPT, in Codex CLI e nell'estensione per IDE.
Poi si riavvia ChatGPT e gli si chiede qualcosa a cui solo le proprie registrazioni possono rispondere — «cerca nelle mie registrazioni Speak-Y la riunione di pianificazione della settimana scorsa ed elenca che cosa abbiamo deciso» è un primo test onesto. Altri schemi si trovano in 20 prompt per le note delle riunioni.
Qui la precisione conta più della rassicurazione, quindi: tredici strumenti, divisi in due.
Cinque leggono la libreria direttamente. Elencare le registrazioni, cercarle, recuperare una trascrizione, prendere la registrazione più recente, elencare i tag. Lavorano sui file della propria macchina e non richiedono che l'app Speak-Y sia in esecuzione.
Otto passano dall'app in esecuzione — assegnare tag, rinominare chi parla, modificare il titolo di una registrazione, ritrascrivere una dettatura, sincronizzare, ed elencare, creare o pubblicare in un canale del team. L'app custodisce il database e le chiavi di cifratura, quindi ad app chiusa non cambia nulla.
Nulla cancella. Non esiste uno strumento che rimuova una registrazione, un canale o uno spazio di lavoro. La pubblicazione in un canale è l'unica azione che non si può annullare dalla finestra di chat: si fa nell'app.
MCP permette a un server di annotare ogni strumento con un readOnlyHint, e il
client di OpenAI usa esattamente quello. I valori documentati per
default_tools_approval_mode sono auto, prompt, writes e approve, e
writes chiede conferma per ogni strumento non marcato come di sola lettura. I
singoli strumenti si possono sovrascrivere.
Tutto questo funziona solo se il server è onesto sui propri strumenti. Speak-Y
marca i suoi cinque strumenti di lettura come di sola lettura e le sue azioni
come modificanti i dati, quindi writes produce il comportamento desiderato:
ricerche e trascrizioni scorrono senza interruzioni, mentre l'assegnazione di
tag o la condivisione si fermano e chiedono. Ogni azione è registrata nel log
in Impostazioni → Integrazioni, dove un solo interruttore disattiva le azioni e
lascia funzionante la lettura.
Se si preferisce eliminare del tutto la possibilità, si avvia il server
vincolato alla lettura: si aggiunge --read-only ad args, e gli strumenti
che modificano non vengono mai pubblicati a quel client.
args = ["--mcp", "--read-only"]
Un server che etichetta una scrittura come lettura vanifica tutto questo — ed è la ragione pratica per cui conta chi ha scritto i server MCP che si installano. La documentazione della modalità sviluppatore di OpenAI segnala la stessa classe di rischi: prompt injection, errori del modello sulle azioni di scrittura e server apertamente malevoli.
Una libreria personale interrogabile in ChatGPT risolve metà del problema: il proprio ricordo. L'altra metà è quello di tutti gli altri — decisioni prese in riunioni a cui non si era presenti. Le registrazioni pubblicate in uno spazio di lavoro del team sono cifrate end-to-end e ricercabili dallo stesso assistente, il che trasforma il «perché abbiamo deciso così?» da interruzione a domanda che si può semplicemente porre.
L'app desktop sì. La documentazione MCP di OpenAI elenca i server STDIO — quelli avviati da un comando sulla propria macchina — accanto ai server remoti streamable HTTP per l'app desktop, Codex CLI e l'estensione per IDE. ChatGPT sul web no: raggiunge soltanto gli strumenti remoti basati su MCP forniti dai plugin.
Nel file di configurazione di Codex, ~/.codex/config.toml, sotto una tabella [mcp_servers.<name>]. L'app desktop, Codex CLI e l'estensione per IDE condividono quell'unico file, quindi un server aggiunto in uno qualsiasi di essi compare anche negli altri.
Dipende dalla modalità di approvazione. I valori documentati per default_tools_approval_mode sono auto, prompt, writes e approve; writes chiede conferma per ogni strumento non marcato come di sola lettura, e i singoli strumenti si possono sovrascrivere. Sono i server che annotano i propri strumenti in modo onesto, come fa Speak-Y, a rendere significativa quell'impostazione.
Per la connessione in sé non viene caricato nulla: il server MCP di Speak-Y gira sul Mac dell'utente e legge la libreria locale. Ma tutto ciò che ChatGPT legge davvero entra a far parte della conversazione e viaggia verso il modello con il resto della chat, quindi le trascrizioni su cui si fanno domande lasciano comunque la macchina come contesto.
Perché è la stessa configurazione. Il file di Codex è in TOML anziché JSON, quindi Speak-Y fornisce i due valori da incollare invece di scrivere il file al posto dell'utente — e l'app desktop di ChatGPT legge quello stesso file.