Configurare MCP tra VS Code e Copilot: formati e limiti

Per condividere server MCP tra Visual Studio Code e GitHub Copilot, mantieni una definizione comune dei server e genera o gestisci file distinti per ciascun formato. Visual Studio Code usa servers; la configurazione portatile letta direttamente dall’harness di Copilot usa mcpServers e non conserva alcune funzioni di VS Code.

MCP, il Model Context Protocol, permette ai client di IA di accedere a strumenti e altre capacità offerte dai server. La scelta del file dipende quindi da dove avvierai l’agente, non solo da quali server vuoi usare.

Scegli il formato in base al client

Microsoft documenta due formati con percorsi, chiavi principali e riferimenti alle variabili diversi. La configurazione di VS Code può stare nel workspace o nel profilo utente; quella portatile di Copilot può stare nel workspace o nella configurazione utente di Copilot.

La documentazione Microsoft sui formati MCP spiega anche come vengono usati: le sessioni dell’harness di Copilot leggono direttamente il formato portatile. VS Code può inoltrare a Copilot i server compatibili dalla propria configurazione, ma non quelli che richiedono valori interattivi ${input:...}.

Perciò, se vuoi mantenere una sola definizione di server per più ambienti, trattala come sorgente da cui ricavare configurazioni adatte ai rispettivi client. Non basta copiare lo stesso JSON cambiando il nome del file: schema e funzionalità disponibili non coincidono.

Cosa non passa al formato portatile

I file portatili non supportano i prompt di input di VS Code, envFile, la modalità di sviluppo né le impostazioni sandbox per singolo server. Se la configurazione di VS Code dipende da una di queste funzioni, il file portatile non ne riproduce il comportamento.

Prima di adottare il formato portatile come configurazione condivisa, controlla quindi se i server usati dal team dipendono da una di queste opzioni. Quando una funzione serve solo nell’editor, conserva una configurazione specifica per VS Code invece di considerare il file portatile una copia completa.

Separa il controllo dei file dal test del server

Un audit strutturale può individuare JSON non valido, chiavi principali errate, sintassi delle variabili incoerente o valori simili a segreti inseriti direttamente nei file. Può anche confrontare l’elenco dei server tra i file generati. Non dimostra però che un server si avvii, si autentichi o risponda alle richieste.

Tech Insider ha descritto un flusso che parte da un file sorgente e genera file distinti per Cursor, VS Code e Copilot, con controlli di configurazione e una verifica delle differenze in CI. L’autrice ha riferito di aver eseguito gli script su Linux. Per controllare il funzionamento, la stessa guida suggerisce invece di usare MCP Inspector e di provare una chiamata rappresentativa nel client previsto: sono verifiche diverse dall’audit del JSON.

In pratica, procedi così:

1. Decidi quali client useranno i server. Questo determina i formati di destinazione, perché VS Code e Copilot non leggono lo stesso schema.
2. Confronta le funzioni usate dalla configurazione VS Code con quelle supportate dal formato portatile. Prompt, envFile, modalità di sviluppo e sandbox per server non vengono trasferiti ai file portatili.
3. Controlla ogni file generato. Verifica struttura JSON, chiave principale e riferimenti alle variabili per il formato a cui è destinato.
4. Prova i server nel client in cui verranno usati. Un file valido non certifica connessione, autenticazione o disponibilità degli strumenti.

Configurazione gestita di Cursor

Per i workspace gestiti, Coder descrive un’alternativa alla generazione di file nel repository: il suo modulo accetta dati MCP in formato JSON e li scrive in ~/.cursor/mcp.json all’avvio del workspace. In un post pubblicato il 20 agosto 2025, l’azienda presenta i template Terraform versionati come parte di questo approccio. È una modalità di provisioning per Cursor descritta da Coder, distinta da un generatore condiviso per VS Code e Copilot.