AIREITERUn server MCP per ChatGPT non è davvero pronto quando /mcp risponde. ChatGPT deve riuscire a raggiungerlo, individuare gli strumenti corretti, autenticare gli utenti e scegliere i tool più adatti. Per la maggior parte dei team, l'hosting gestito è la scelta più sensata; l'infrastruttura privata va invece collegata tramite Secure MCP Tunnel.
Stabilisci il perimetro di deployment prima di scrivere codice
Il perimetro di deployment determina il trasporto, il lavoro necessario per l'autenticazione, il carico operativo e la possibilità di pubblicare il server. ChatGPT è un client MCP remoto: non avvia direttamente un processo locale in stdio come fanno alcuni client desktop (OpenAI Help Center).
| Modalità di deployment | Connessione a ChatGPT | Ideale per | Principale compromesso |
|---|---|---|---|
| Hosting pubblico gestito | Endpoint HTTPS stabile con Streamable HTTP | La maggior parte delle app per team e clienti | Limiti della piattaforma e dipendenza dal provider |
| Endpoint pubblico autogestito | Endpoint HTTPS stabile su container, VM o cluster | Team platform già strutturati, con requisiti di compliance o di rete | Il team gestisce TLS, scalabilità, patch, rollback e monitoraggio |
| Secure MCP Tunnel | Endpoint ospitato da OpenAI che inoltra le richieste a un server privato in stdio o HTTP | Sistemi on-premise, reti private e sviluppo | La disponibilità dipende anche dall'affidabilità di tunnel-client |
Scegli l'hosting gestito come opzione predefinita quando il server MCP è stateless, il traffico è intermittente e il team non gestisce già una piattaforma applicativa pubblica affidabile. Il pattern con route handler di Vercel e quello con Worker stateless di Cloudflare producono entrambi l'endpoint HTTPS stabile richiesto da ChatGPT; prima di decidere, verifica i limiti di durata delle richieste, streaming e gestione dello stato di ciascuna piattaforma (Vercel, Cloudflare).
Gestisci in autonomia l'endpoint pubblico quando il server deve stare accanto a database esistenti, usare l'infrastruttura di identità già adottata, rispettare vincoli di residenza dei dati o eseguire workload incompatibili con il modello serverless. Questa scelta ha senso solo se il team dispone già di gestione dei secret, rollback delle release, alerting e un responsabile reperibile.
Usa Secure MCP Tunnel quando l'ingresso pubblico non è il confine di sicurezza corretto. Il client del tunnel di OpenAI apre connessioni HTTPS in uscita verso api.openai.com:443 e inoltra le richieste a un server HTTP o stdio privato: non serve alcun listener Internet in ingresso. La documentazione di deployment di OpenAI specifica inoltre che Secure MCP Tunnel non soddisfa il requisito di pubblicazione, che richiede un endpoint HTTPS stabile e raggiungibile pubblicamente (documentazione OpenAI sul tunnel, guida OpenAI alla realizzazione).
Dal tool locale al server MCP per ChatGPT pronto per la produzione
Un deployment affidabile per ChatGPT separa i controlli sul comportamento dei tool, sul protocollo, sulla raggiungibilità in produzione e sull'instradamento del modello. Superare un controllo non significa automaticamente superare quello successivo.
1. Definisci tool mirati e contratti stabili
Parti da un tool per ogni azione riconoscibile dell'utente. Nella guida di OpenAI, per esempio, list_projects, get_project e update_project sono strumenti separati, invece di confluire in un unico tool con modalità non correlate (documentazione per sviluppatori OpenAI). Ogni tool deve avere un nome orientato all'azione, una descrizione precisa, uno schema di input esplicito, un output utile e annotazioni di sicurezza corrette.
Imposta readOnlyHint: true solo quando il tool non può modificare lo stato. Usa destructiveHint: true per gli effetti irreversibili o difficili da annullare e openWorldHint: true quando il tool accede a entità esterne non predefinite. OpenAI descrive queste annotazioni come metadati rivolti al modello, utilizzati per il comportamento dei tool e la gestione della sicurezza; l'autorizzazione deve comunque essere applicata dal server a ogni richiesta protetta (documentazione per sviluppatori OpenAI).
Restituisci identificativi stabili dei record in structuredContent quando una chiamata successiva potrebbe dover aggiornare lo stesso record. Tieni token, secret e dati personali non necessari fuori da content, structuredContent e _meta: OpenAI specifica chiaramente che _meta è nascosto al modello, ma non è un archivio sicuro.
2. Esponi localmente Streamable HTTP
La connessione remota standard di ChatGPT usa Streamable HTTP, di norma su /mcp. Il percorso è convenzionale, non obbligatorio, ma l'URL completo del deployment deve essere inserito in ChatGPT (guida OpenAI alla connessione).
Avvia il server in locale e apri MCP Inspector:
npx @modelcontextprotocol/inspector@latestCollega Inspector a un URL come http://localhost:3000/mcp. Verifica l'inizializzazione e l'elenco dei tool, quindi chiama ogni strumento con una richiesta valida, uno schema non valido, un identificativo mancante e un caso senza risultati. Per i tool protetti, assicurati che credenziali assenti o insufficienti producano un rifiuto sicuro.
3. Aggiungi il controllo degli accessi prima di esporre il server
Un health check pubblico non giustifica una superficie di tool pubblica. Se gli strumenti espongono solo dati intenzionalmente pubblici e in sola lettura, un endpoint senza autenticazione può essere accettabile. Dati privati, dati specifici dell'utente e operazioni di modifica richiedono autenticazione e autorizzazione a ogni richiesta (guida OpenAI alla realizzazione).
Con MCP protetto da OAuth, il server svolge il ruolo di resource server. Una richiesta non autenticata restituisce 401 e indica al client i metadata della risorsa protetta, normalmente disponibili su /.well-known/oauth-protected-resource. Il flusso di autorizzazione dovrebbe usare PKCE, token con scope stretti, una validazione rigorosa di issuer e audience e il supporto ai refresh token quando le connessioni persistenti lo richiedono (OpenAI Help Center).
Non inoltrare il token di accesso MCP a un servizio upstream solo perché entrambi riconoscono i bearer token. Il token deve essere destinato alla risorsa che lo riceve; per le chiamate downstream usa credenziali di servizio o un'architettura appropriata di token exchange (guida alla sicurezza nel deployment MCP).
4. Distribuisci un candidato immutabile
Distribuisci su un endpoint di preview o staging la stessa build che ha superato i test in Inspector, quindi promuovi quell'artefatto in produzione. L'endpoint di produzione deve usare HTTPS, mantenere il percorso MCP completo, raggiungere tutte le dipendenze e conservare i secret nel secret store della piattaforma di hosting.
Per un percorso di riferimento compatto su Vercel, installa mcp-handler, @modelcontextprotocol/server e zod; monta il Web handler restituito in app/api/mcp/route.ts; esportalo per GET e POST; quindi esegui il deployment con:
npx vercel deploy --prodL'URL di connessione a ChatGPT avrà quindi la forma https://your-project.vercel.app/api/mcp. Vercel documenta una durata predefinita delle funzioni di 300 secondi con Fluid compute e limiti superiori nelle configurazioni a pagamento idonee; sposta quindi in un job resumable il lavoro che supera la durata di una richiesta, invece di mantenere aperto uno stream inattivo (guida al deployment Vercel). Mantieni la route stateless, a meno che il runtime scelto non offra un'architettura deliberata per lo stato condiviso.
Prima di collegare ChatGPT, aggiungi questi quattro controlli operativi:
- Imposta timeout e rate limit per i tool più costosi.
- Registra gli errori di inizializzazione e quelli dei tool senza scrivere nei log token o risultati sensibili.
- Associa a ogni invocazione un identificativo della release, così da collegare gli incidenti al codice distribuito.
- Mantieni una procedura di rollback testata per le regressioni negli schemi dei tool o nell'autorizzazione.
Esegui MCP Inspector sull'URL di produzione, non solo su localhost. Ricontrolla discovery, schemi, annotazioni, autenticazione, chiamate valide ed errori. Un load balancer, un proxy, una regola CORS o un redirect del provider di identità possono fallire anche quando l'applicazione funziona in locale.
Progetta il controllo degli accessi su tre livelli
L'accesso MCP da ChatGPT ha tre livelli indipendenti di enforcement; attivare OAuth copre solo il livello dell'identità.
| Livello | Punto di enforcement | Decisione necessaria |
|---|---|---|
| Accesso al workspace | Controlli amministrativi di ChatGPT | Chi può creare, pubblicare, abilitare o usare l'app? |
| Identità dell'utente | Authorization server OAuth e resource server MCP | Quale account sta effettuando la chiamata e il token è valido per questo server? |
| Autorizzazione su risorsa o azione | Handler del tool MCP e backend | Questo utente può eseguire questa azione su questo tenant, record o ambiente? |
Su ChatGPT Business, amministratori o proprietari controllano la developer mode e la pubblicazione. I workspace Enterprise ed Edu aggiungono RBAC per l'accesso degli sviluppatori, l'accesso alle app e le azioni (OpenAI Help Center). Questi controlli regolano l'uso dell'app da parte di ChatGPT; non dimostrano che una chiamata possa modificare il record del cliente A nel backend.
L'handler MCP deve ricavare l'identità da credenziali validate e applicare a ogni chiamata i controlli su tenant e oggetto. Non accettare mai un ID utente, un ID organizzazione o un ruolo fornito negli argomenti generati dal modello come prova dell'identità. Considera tutti gli argomenti dei tool come input non affidabile.
Separa gli scope di lettura da quelli di scrittura. Una policy pratica potrebbe consentire projects:read in modo ampio, riservare projects:write agli editor e richiedere un nuovo controllo lato server prima delle operazioni distruttive. ChatGPT può chiedere conferma per le azioni con conseguenze rilevanti, ma la conferma è una protezione dell'esperienza utente, non un controllo di autorizzazione.
Anche la prompt injection è un problema di controllo degli accessi. Output dei tool e documenti recuperati possono contenere istruzioni ostili: per questo i tool di scrittura dovrebbero esporre l'azione più circoscritta possibile e validare lato server i campi consentiti. Un tool generico come execute_action aumenta sia l'ambiguità nell'instradamento sia il raggio d'azione di un eventuale errore.
Collega, testa e pubblica l'app in ChatGPT
Il collegamento dell'endpoint crea una bozza dell'app e uno snapshot dei suoi metadata. La pubblicazione rende disponibile al workspace una configurazione verificata; non coincide con il deployment del codice del server.
- Abilita la developer mode secondo la policy applicabile al workspace ChatGPT.
- Apri il flusso di creazione dell'app e inserisci l'URL MCP HTTPS completo, compreso
/mcpquando quella è la route montata. - Seleziona il meccanismo di autenticazione e completa OAuth, se richiesto.
- Esegui Scan Tools, controlla ogni nome, schema, annotazione e azione rilevata, quindi crea la bozza.
- Testa la bozza in una nuova chat prima di pubblicarla nel workspace.
Per un server privato, scegli Tunnel come connessione e seleziona un tunnel associato oppure inserisci il relativo tunnel_id. L'operatore deve disporre del permesso OpenAI Platform Tunnels Read + Use, mentre la developer mode di ChatGPT resta un'autorizzazione separata del workspace (documentazione OpenAI sul tunnel).
Le modifiche ai metadata richiedono un ciclo di vita esplicito. Per una connessione in developer mode, distribuisci o riavvia il server, apri la connessione, seleziona Refresh, verifica i metadata modificati e avvia una nuova conversazione. Le indicazioni attuali di OpenAI per Business specificano che le app pubblicate devono essere ricreate e ripubblicate per modificare tool o metadata; gli amministratori Enterprise/Edu possono aggiornare le azioni, esaminare le differenze e abilitare nuove azioni, che per impostazione predefinita sono disabilitate (OpenAI Help Center).
L'evoluzione retrocompatibile resta comunque la policy server più sicura. Aggiungi campi opzionali e nuovi tool, evitando di cambiare silenziosamente il significato di uno strumento esistente. Mantieni disponibili gli schemi precedenti finché tutti gli snapshot approvati e i client non sono stati aggiornati.
Testa il comportamento che gli utenti di ChatGPT vedranno davvero
I test di protocollo dimostrano che il server sa rispondere. I test in ChatGPT verificano invece che il modello selezioni il tool previsto, fornisca argomenti adatti, rispetti i confini e non usi lo strumento quando non è pertinente.
L'utente Reddit u/EmailNo8428 ha descritto così il problema a due livelli:
“In pratica stai testando due cose contemporaneamente: la logica dei tuoi tool e il modo in cui un determinato client li chiama.” (r/mcp)
Costruisci un piccolo set di valutazione versionato che includa questi casi:
| Caso | Risultato atteso |
|---|---|
| Richiesta diretta | Selezionare la capacità nominata con argomenti validi |
| Richiesta indiretta | Inferire il tool corretto dall'obiettivo dell'utente |
| Richiesta successiva | Riutilizzare l'identificativo stabile restituito in precedenza |
| Richiesta negativa | Non chiamare alcun tool MCP |
| Permesso mancante | Restituire un errore di autorizzazione utile senza divulgare dati |
| Richiesta di scrittura | Selezionare il tool di scrittura più circoscritto e attivare la conferma prevista |
| Richiesta ambigua | Chiedere le informazioni necessarie invece di inventare argomenti |
| Risultato vuoto | Restituire uno stato vuoto valido, non un errore di trasporto o di schema |
Registra il tool selezionato, gli argomenti, il risultato restituito, l'errore e il comportamento relativo alla conferma. Ripeti i casi interessati ogni volta che cambiano nome, descrizione, schema, annotazione, regola di autenticazione o forma del risultato di un tool; OpenAI prescrive lo stesso ciclo di aggiornamento e nuovo test nella guida alla connessione.
Un server che supera Inspector ma instrada male le richieste in ChatGPT di solito ha bisogno di confini, descrizioni o schemi dei tool più chiari. Un server che instrada correttamente ma restituisce 401, va in timeout o perde lo stato presenta invece un problema di infrastruttura o autorizzazione. Separare queste diagnosi accorcia il ciclo di correzione.
Domande frequenti
ChatGPT può collegarsi direttamente a un server MCP su localhost o in stdio?
No. ChatGPT si collega normalmente a un endpoint MCP remoto. OpenAI Secure MCP Tunnel può inoltrare le richieste a un server privato in stdio o HTTP senza esporre ingressi pubblici, mentre un tunnel HTTPS temporaneo può essere utile durante lo sviluppo, ma non per la pubblicazione di un plugin.
Un server MCP per ChatGPT deve avere un endpoint HTTPS pubblico?
Una connessione remota normale e la pubblicazione di un plugin richiedono HTTPS stabile. Un server privato usato in developer mode può invece utilizzare Secure MCP Tunnel, mantenendo il server nell'ambiente controllato dal cliente.
search e fetch sono obbligatori?
No. OpenAI afferma che i server collegati non devono più includerli. Implementa i contratti standard search e fetch quando l'app deve partecipare alle superfici di recupero per la knowledge aziendale o la ricerca approfondita (OpenAI Help Center).
Perché ChatGPT mostra ancora i vecchi tool dopo il deployment?
ChatGPT conserva i metadata rilevati e non considera ogni deployment del codice come una modifica approvata ai tool. Aggiorna una connessione in developer mode e avvia una nuova conversazione; le app pubblicate nei workspace seguono invece il processo di revisione e ripubblicazione previsto dal piano.