Una guida per sviluppatori illustra i compromessi tra l'esecuzione di un server Model Context Protocol (MCP) su una workstation e l'hosting dello stesso come servizio HTTP condiviso. L'autore sostiene che la scelta determini la latenza, l'esposizione delle credenziali e la facilità con cui un team può scalare lo strato di accesso ai dati guidato dall'IA.

Perché la decisione è importante

L'MCP è il ponte che consente agli assistenti basati su modelli linguistici di grandi dimensioni (LLM), come Claude o Cursor, di eseguire query SQL su un database senza mai visualizzare la password. L'assistente chiama uno strumento, lo strumento inoltra la richiesta a un server MCP e il server esegue la query. Se il server si trova sul laptop di uno sviluppatore, l'andata e ritorno è essenzialmente una chiamata a una funzione locale. Se risiede su un host centrale, ogni richiesta attraversa la rete ed è soggetta ai meccanismi di autenticazione e logging dell'host. I team che passano da un prototipo sviluppato da un singolo utente a un ambiente di produzione devono decidere quale modello si adatti alla propria postura di sicurezza, alle aspettative di prestazioni e al carico operativo.

I due modelli di deployment

Locale (stdio)

Il client avvia il server MCP come processo figlio e comunica con esso tramite lo standard input / output. Non viene coinvolto alcuno stack di rete.

  • Ideale per: sviluppatori singoli, esperimenti rapidi e database di test esclusivamente locali.
  • Vantaggi: la latenza è virtualmente nulla; il processo eredita l'ambiente dell'utente, quindi le password non lasciano mai la macchina.
  • Svantaggi: ogni utente deve mantenere il proprio file di configurazione o le proprie variabili d'ambiente; non esiste una traccia di audit centrale; scalare verso più utenti richiede la replica della configurazione su ogni workstation.

Remoto (HTTP)

Il server viene eseguito continuamente su un host raggiungibile tramite HTTP. I client si autenticano, solitamente con un flusso di tipo OAuth, e inviano richieste a un endpoint noto.

  • Ideale per: team, pipeline CI e dati di produzione che devono essere accessibili da diverse persone o servizi.
  • Vantaggi: un unico punto per i log di audit, il controllo degli accessi basato sui ruoli e il pooling delle connessioni; le credenziali sono memorizzate una sola volta in un vault controllato.
  • Svantaggi: infrastruttura aggiuntiva da predisporre e mantenere; la latenza di rete aggiunge alcuni millisecondi per ogni andata e ritorno.

Confronto diretto

Aspetto Locale Remoto
Utilizzo previsto Un utente Molti utenti
Autenticazione Variabili d'ambiente o configurazione locale Flusso di token compatibile con OAuth
Audit Nessuno integrato Un log centrale registra ogni richiesta
Complessità di configurazione Minima Richiede provisioning del server, TLS, gestione dei token
Latenza Quasi nulla Maggiore a causa del salto di rete
Esposizione delle credenziali Limitata alla macchina dello sviluppatore Centralizzata, ma deve essere protetta da violazioni

Un approccio ibrido pragmatico

La maggior parte delle organizzazioni non sceglie un singolo modello per sempre. La guida raccomanda un rilascio graduale:

  1. Sviluppare localmente – avviare un server MCP locale su un database sandbox. La velocità favorisce un'iterazione rapida e mantiene i segreti fuori dal controllo di versione.
  2. Passare al remoto – una volta condiviso il codebase, spostare il server su un host centrale. Modificare la configurazione del client per puntare all'endpoint HTTP e abilitare OAuth.
  3. Proteggere la produzione – mantenere i database di produzione dietro un gateway remoto e verificabile. Imporre ruoli di sola lettura per l'assistente IA e memorizzare le password di produzione solo in un secrets manager a cui il server remoto può accedere.

Errori comuni da evitare

  • Memorizzare le password di produzione nel file .env di uno sviluppatore o in altre configurazioni locali. Se la macchina viene compromessa, il database viene esposto.
  • Distribuire un server MCP remoto senza un sistema OAuth o un sistema di token comparabile. L'autenticazione basic in chiaro o le chiavi API statiche sono facili da far trapelare.
  • Concedere all'assistente IA permessi di scrittura sulle tabelle di produzione. Anche istruzioni DELETE accidentali possono causare la perdita di dati; un ruolo di sola lettura elimina questo rischio.

Quando il modello locale ha ancora senso

Se il flusso di lavoro di un team non lascia mai una singola macchina — si pensi a un data scientist che lavora da solo su un prototipo con un laptop personale — il deployment locale rimane l'opzione più semplice e veloce. L'onere di configurare certificati TLS, l'emissione di token e una pipeline di logging potrebbe non essere giustificato per un esperimento di breve durata.

In sintesi

Se hai bisogno della massima velocità e sei l'unico utente, un server MCP locale è la scelta più immediata. Se necessiti di auditabilità, accesso condiviso o sicurezza di livello produzione, un server HTTP remoto è l'unica strada percorribile. La maggior parte dei team inizia con una soluzione locale per comodità, per poi passare a un gateway remoto protetto da token prima di interagire con i dati di produzione. Adatta il modello di deployment alla fase del progetto e al profilo di rischio dei dati che intendi esporre.