Client MCP e conferme prima di modificare i dati: confronto 2026

2026-09-29

Ogni client MCP che conta nel 2026 chiede conferma prima che un assistente esegua uno strumento che modifica qualcosa. Questa parte della risposta è noiosa e rassicurante. La parte utile è ciò che succede dopo la prima richiesta, perché nessuno clicca «Allow» quaranta volte al giorno a lungo: ogni client offre un modo per smettere di chiedere, e i client differiscono nettamente in quanto quel modo sia preciso.

In breve: Claude Code, Zed, Cursor e Devin Desktop permettono di pre-approvare i singoli strumenti MCP per nome. Codex, il motore dietro l'app desktop di ChatGPT, può invece decidere in base alle etichette del server stesso — chiedere per tutto ciò che non è marcato come di sola lettura. VS Code fa entrambe le cose a livello di finestra di dialogo e aggiunge interruttori validi per l'intero workspace. Nessuna di queste impostazioni è sbagliata, ma falliscono in modi diversi, e il fallimento che dovrebbe preoccupare dipende da chi ha scritto il server.

Questo confronto affianca la nostra ricognizione su quali client MCP possono avviare un server locale. Quella risponde a «si avvia?»; questa risponde a «che cosa farà quando l'assistente decide di cambiare qualcosa?». Tutto ciò che segue è stato verificato sulla documentazione di ciascun fornitore il 29 settembre 2026.

La risposta breve

Due colonne portano la maggior parte del significato. «Permesso permanente più fine» dice se ci si può fidare di search senza fidarsi di share. «Decide in base alle annotazioni» dice se il client fa quella distinzione al posto dell'utente — usando etichette che il server ha scritto su sé stesso.

Codex e l'app desktop di ChatGPT: quattro modalità e un'etichetta

Codex ha l'impostazione più esplicita, e poiché l'app desktop di ChatGPT, Codex CLI e l'estensione IDE condividono un unico file di configurazione, vale per tutti e tre. Ogni server MCP riceve un default_tools_approval_mode, e ogni strumento può sovrascriverlo con tools.<tool>.approval_mode. I valori documentati sono auto, prompt, writes e approve.

Quello interessante è writes. Nelle parole di OpenAI, «chiede conferma per gli strumenti che non sono marcati come di sola lettura». La ricerca procede in silenzio, tutto il resto si ferma e chiede, e uno strumento senza alcuna annotazione conta come scrittura — l'impostazione sicura quando un server non dice nulla. Oltre alle modalità, la documentazione sulle approvazioni di Codex afferma che le chiamate a strumenti MCP distruttivi richiedono sempre un'approvazione quando lo strumento dichiara un'annotazione distruttiva, a meno che non dichiari anche un'annotazione di lettura.

Un cambiamento da conoscere per chi ha una configurazione più vecchia: Codex non supporta più approval_policy = "untrusted", e l'impostazione ritirata può impedire l'avvio del client. La fiducia in un progetto ora si imposta invece con il trust_level del progetto.

ChatGPT sul web funziona secondo lo stesso principio. In modalità sviluppatore, disponibile sugli account Pro, Plus, Business, Enterprise ed Education, «le azioni di scrittura richiedono una conferma per impostazione predefinita»; ChatGPT rispetta readOnlyHint e tratta ogni strumento che non lo dichiara come una scrittura. Una scelta può essere ricordata per singolo strumento per il resto di una conversazione, e non oltre.

Claude Code e Claude Desktop: regole scritte per nome

Claude Code non legge le annotazioni per decidere. Usa regole di permesso in tre liste — allow, ask e deny — valutate in quest'ordine fisso: prima deny, poi ask, poi allow. Gli strumenti MCP si chiamano mcp__<server>__<tool>, quindi mcp__notes__search consente un solo strumento, mcp__notes__get_* una famiglia, e mcp__notes o mcp__notes__* copre l'intero server. La modalità predefinita ora si chiama Manual; tra quelle più permissive ci sono acceptEdits, auto, in cui un classificatore esamina le azioni al posto dell'utente, e bypassPermissions.

Due dettagli pendono verso la sicurezza. I server provenienti dal file .mcp.json versionato in un progetto hanno bisogno di un'approvazione prima ancora di connettersi. E l'autore di un server può marcare uno strumento con _meta["anthropic/requiresUserInteraction"], dopodiché Claude Code mostra la sua richiesta di conferma a ogni chiamata — anche in acceptEdits, auto e bypassPermissions.

Le impostazioni dei connettori di Claude Desktop, in Customize → Connectors, raggruppano gli strumenti di un server in categorie come sola lettura e scrittura/eliminazione, e ogni categoria o singolo strumento può essere impostato su Always allow, Needs approval o Blocked.

Cursor, VS Code, Zed e Devin Desktop: gli editor

Cursor lo dice chiaramente: «Per impostazione predefinita, Cursor chiede l'approvazione prima di usare gli strumenti MCP.» MCP segue le stesse Run Modes dei comandi del terminale. In Auto-review le chiamate nella lista di permessi vengono eseguite subito e tutto il resto passa per un modello classificatore; Run Everything esegue ogni chiamata senza chiedere. La lista di permessi accetta voci server:tool con caratteri jolly. Una trappola: lasciare vuota la lista degli strumenti consentiti di un server consente tutti gli strumenti di quel server.

VS Code chiama il proprio livello predefinito Manual permissions: tutto ciò che non è approvato automaticamente richiede una conferma. La finestra di dialogo permette di approvare un singolo utilizzo o di concedere l'approvazione per la sessione, il workspace o tutte le chiamate future, e le approvazioni per singolo strumento si possono impostare per ogni server MCP. Allow all elimina del tutto le richieste, e Assisted permissions, in cui un modello giudica ogni chiamata, è indicato come sperimentale. Un'eccezione merita attenzione: i server MCP inclusi in un plugin per agenti «sono considerati implicitamente attendibili quando si installa il plugin» e saltano la richiesta di fiducia separata all'avvio. Installare il plugin è la decisione di fiducia.

Zed ha il sistema di regole più leggibile. agent.tool_permissions.default vale confirm se non lo si cambia, con allow e deny come alternative. Le regole indicano gli strumenti MCP come mcp:<server>:<tool_name> e possono essere impostate su consenti sempre, conferma sempre o nega sempre, con il diniego che ha la precedenza. La richiesta stessa offre «Allow once», «Deny once» e «Always for» lo strumento; per gli strumenti MCP esiste solo l'opzione a livello di strumento.

Devin Desktop, l'ex Windsurf, ha cambiato modello insieme al nome. Il suo agente, Devin Local, «sostituisce i livelli di esecuzione automatica con un sistema di permessi più granulare», e per impostazione predefinita chiede prima di chiamare qualsiasi strumento MCP. Dalla richiesta si può consentire un solo strumento o tutti gli strumenti di quel server, per la sessione o in modo permanente, e le regole Deny prevalgono su tutto. Gli amministratori Enterprise possono pre-approvare server o strumenti specifici per l'intera organizzazione.

Cosa possono fare le annotazioni e cosa no

La specifica MCP dà ai server un vocabolario per descrivere i propri strumenti: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Dice anche ai client quanto crederci: i client «DEVONO considerare le annotazioni degli strumenti non attendibili, a meno che non provengano da server attendibili». E chiede un essere umano nel ciclo, con la possibilità di negare qualsiasi chiamata a uno strumento.

Questo mette in prospettiva le due impostazioni descritte sopra. Un client che decide in base alle annotazioni, come la modalità writes di Codex, è comodo con un server di cui ci si fida: si configura una riga, e ogni nuovo strumento di scrittura aggiunto dal server fa scattare automaticamente la richiesta. Con un server di cui non ci si fida, è sicuro esattamente quanto l'onestà del server. Uno strumento che modifica i dati e si dichiara di sola lettura viene eseguito senza richiesta.

Un client che obbliga a nominare gli strumenti, come Claude Code o Zed, fallisce nel modo opposto. Non gli importa che cosa dichiari il server, ma un nuovo strumento di scrittura aggiunto in un aggiornamento è coperto solo se la regola era abbastanza ampia da includerlo — oppure abbastanza stretta da mancarlo e ricadere sulla richiesta di conferma. Le regole basate sui nomi sono più sicure se scritte come «consenti queste letture», non come «consenti questo server».

Una configurazione sensata per un server che legge e scrive

Qualunque sia il client, le stesse quattro abitudini coprono la maggior parte del rischio:

1. Consentire le letture per nome, non l'intero server. Cercare e leggere trascrizioni è ciò che un assistente fa tutto il giorno; è lì che una richiesta costa di più e protegge di meno.
2. Mantenere una richiesta su tutto ciò che condivide o sostituisce. Pubblicare per altre persone e sovrascrivere un testo sono i due tipi di modifica che non si annullano rimettendo un valore com'era.
3. Affidarsi alle annotazioni solo per i server attendibili. Per un server preso da un registro mai usato prima, meglio nominarne gli strumenti nelle regole.
4. Dare a un client meno affidabile un'istanza di sola lettura. Se il server supporta una modalità di sola lettura, un client può essere limitato alla lettura mentre un altro mantiene l'accesso completo.

Campanelli d'allarme: una voce nella lista di permessi di Cursor per un server con la lista degli strumenti vuota, un plugin di VS Code che nessuno nel team ha esaminato, e «Always allow» cliccato su uno strumento di cui non si è letto il nome.

Come funziona in Speak-Y

Il server MCP di Speak-Y è scritto per entrambi i tipi di client. Gli strumenti di lettura — cercare nelle registrazioni, leggere trascrizioni, riepiloghi e azioni da svolgere, elencare tag e canali — dichiarano readOnlyHint e leggono la libreria direttamente dalla macchina locale. Gli strumenti che modificano qualcosa — tag, titoli, nomi dei parlanti, nuova trascrizione, condivisione in un canale del team — sono dichiarati come modificanti e passano per l'app Speak-Y in esecuzione, dove ogni chiamata viene registrata e dove si possono disattivare.

Due di essi sono marcati destructiveHint di proposito: retranscribe, perché sostituisce il testo attuale di una registrazione, comprese le correzioni fatte a mano, e share_to_channel, perché i colleghi possono leggere una registrazione prima che la si ritiri. Nella modalità writes di Codex queste richieste arrivano senza alcuna configurazione; in Claude Code o Zed si consentono gli strumenti di lettura per nome e si lascia il resto su ask.

Se si preferisce che un client possa solo leggere, basta avviare il server con --read-only nella configurazione di quel client: gli strumenti di modifica non gli vengono proprio pubblicati, quindi non c'è nulla da approvare per errore. La configurazione è a un clic da Impostazioni → Integrazioni, e il server MCP è gratuito su ogni piano, incluso Free.

La richiesta di approvazione è solo uno dei controlli che rendono sicuro un assistente in grado di scrivere. Gli altri — quali modifiche sono reversibili e che cosa conserva il registro — sono trattati in cosa rende sicuro l'accesso in scrittura via MCP, e la documentazione MCP contiene la configurazione per ogni client.

FAQ

I client MCP chiedono conferma prima di eseguire uno strumento che modifica i dati?

Tutti i client principali chiedono conferma per impostazione predefinita. Claude Code, Cursor, VS Code, Zed e Devin Desktop chiedono prima di eseguire uno strumento MCP finché non lo si pre-approva, e la modalità sviluppatore di ChatGPT richiede una conferma per ogni strumento non marcato come di sola lettura. Cambia invece quanto finemente si può pre-approvare dopo: per strumento, per server, per sessione o per sempre. Verificato il 29 settembre 2026.

Quali client MCP usano l'annotazione readOnlyHint per decidere quando chiedere?

Codex e ChatGPT lo fanno in modo esplicito. La modalità di approvazione writes di Codex chiede conferma per gli strumenti non marcati come di sola lettura e chiede sempre prima di uno strumento che si dichiara distruttivo, e la modalità sviluppatore di ChatGPT tratta ogni strumento senza readOnlyHint come un'azione di scrittura. Claude Code, Cursor, VS Code e Zed non documentano le annotazioni come elemento della decisione; le regole si scrivono a mano, per nome dello strumento.

Si possono approvare automaticamente gli strumenti di lettura e ricevere comunque una richiesta prima delle scritture?

Sì, in ogni client di questo confronto, ma il meccanismo cambia. In Claude Code, Zed, Cursor e Devin Desktop si consentono gli strumenti di lettura per nome, come mcp__server__search in Claude Code o mcp:server:search in Zed. In Codex la modalità writes lo fa con una riga, affidandosi al server perché marchi onestamente i propri strumenti di lettura.

Le annotazioni degli strumenti come readOnlyHint sono una garanzia di sicurezza?

No. La specifica MCP dice che i client devono considerare le annotazioni degli strumenti non attendibili, a meno che non provengano da server attendibili. Un server che marca come di sola lettura uno strumento di scrittura vanifica qualsiasi politica del client basata su quel suggerimento. Le annotazioni vanno trattate come una comodità per i server di cui ci si fida già; per gli altri, gli strumenti vanno nominati esplicitamente nelle regole.

Qual è il modo più sicuro di collegare un server di note delle riunioni a un assistente AI?

Pre-approvare solo gli strumenti di lettura, mantenere la richiesta di conferma su tutto ciò che modifica i dati e dare ai client meno affidabili un'istanza di sola lettura. Con Speak-Y, avviare il server con --read-only nella configurazione di un client rimuove del tutto gli strumenti di modifica per quel client, mentre un altro client mantiene l'accesso completo con le proprie richieste di conferma.