Scegli il trasporto con consapevolezza
Un server stdio locale e un servizio remoto HTTP hanno esigenze di distribuzione diverse. Usa un trasporto remoto supportato, TLS e una rotta autenticata. Controlla le versioni del client e del server invece di presumere che ogni implementazione supporti le stesse capacità.
Tratta ogni strumento come un API
Valida gli argomenti, applica autorizzazioni specifiche per utente e limita le risorse. Non esporre l'esecuzione arbitraria di shell come strumento di comodità. Limita le destinazioni in uscita quando uno strumento recupera URL e tieni i segreti fuori da descrizioni e risposte.
Mantieni proporzionata la raccolta dell'identità
Un host no-KYC può ridurre al minimo i dati di registrazione del provider, ma il servizio MCP può comunque necessitare dei propri utenti, della sicurezza delle sessioni e dei controlli anti-abuso. Spiega cosa registra nei log ed evita di conservare gli input degli strumenti senza uno scopo definito.
Esegui il deployment per chiarezza operativa
Esegui con un utente dedicato, usa controlli di integrità, limita i tempi delle richieste e mantieni il buffering e i timeout del reverse proxy compatibili con il protocollo. Testa autenticazione, revoca, disconnessioni e tentativi ripetuti prima di concedere privilegi di scrittura.
Allinea l'autenticazione al protocollo supportato
Per un deployment MCP basato su HTTP, esamina i requisiti di autorizzazione attuali del protocollo e la versione supportata dal client. L'accesso alle risorse basato su OAuth implica audience del token, discovery e scope, non semplicemente una password sulla homepage. Usa HTTPS, convalida i token per la risorsa prevista e tieni le credenziali bearer fuori dalle query string. Un server stdio usa un confine di credenziali locale diverso.
- Testa una richiesta non autenticata
- Verifica una richiesta autenticata al di fuori del suo ambito
- Revoca una credenziale e verifica che smetta di funzionare
Documentazione ufficiale: Specifica di autorizzazione MCP
Pubblica un primo set di strumenti limitato
Inizia con strumenti di sola lettura che restituiscono una quantità limitata di dati. Aggiungi scritture di file, operazioni sul ciclo di vita del server o messaggi esterni solo dopo aver compreso le relative autorizzazioni e il comportamento in caso di duplicati. Tratta le pagine web e i documenti restituiti come input non attendibili; non devono ampliare silenziosamente l'autorità del server degli strumenti.
Fissa il comportamento del protocollo prima di scrivere le regole del proxy
Registra sia la release del server SDK sia la revisione MCP che il client utilizzerà. Nella revisione 2026-07-28 Streamable HTTP, le richieste usano un endpoint POST; gli esempi più vecchi basati su sessioni di protocollo o su uno stream GET autonomo appartengono a una revisione diversa. Non rimuovere un apparente requisito di compatibilità finché non sai quale client supporti. Un reverse proxy deve preservare le intestazioni richieste, lo stato HTTP e il comportamento di streaming delle risposte per quella versione.
- Inizia con uno strumento in sola lettura su un listener di loopback, poi anteponi ad esso il confine HTTPS/autenticazione previsto.
- Verifica un risultato normale, un risultato in streaming, un timeout e un client disconnesso attraverso il proxy pubblico.
- Convalida i valori Origin consentiti come richiesto dal trasporto; un controllo Origin non sostituisce l'autenticazione del chiamante.
- Se gli eventi arrivano solo alla fine, ispeziona il buffering del proxy e il comportamento dei timeout prima di modificare il codice degli strumenti.
Documentazione ufficiale: MCP 2026-07-28: Streamable HTTP
Testa i fallimenti di autorizzazione con la stessa cura dei successi
Per l'accesso a HTTP protetto da OAuth, il server MCP è una risorsa protetta. Testa la scoperta dei metadati, l'issuer previsto e l'audience del token, e gli scope necessari per una particolare operazione. Mantieni il token di autorizzazione fuori dalle query string di URL e non inoltrarlo mai invariato a un servizio downstream non correlato. Un errore di autenticazione lato client deve preservare la sfida HTTP appropriata affinché il client possa recuperare tramite il flusso supportato.
- Nessun token o token scaduto: l'endpoint protetto rifiuta l'accesso invece di restituire dati privati degli strumenti.
- Token valido con permessi insufficienti: la risorsa richiesta rimane inaccessibile.
- Token per un altro pubblico: rifiutalo anche se la firma è altrimenti valida.
- URL esterno o percorso di file inatteso: convalida rispetto all'autorità dello strumento prima di recuperare o scrivere.
- Log e tracce di errore: conserva un identificatore dell'operazione e l'esito rimuovendo token e input privati degli strumenti.
Documentazione ufficiale: MCP 2026-07-28: autorizzazione HTTP · MCP: best practice di sicurezza