I 10 migliori gateway e proxy MCP per l’IA locale nel 2026

Un server MCP è facile da gestire. Dieci server possono trasformare ogni client IA in un caos di endpoint, token, schemi degli strumenti, peculiarità dei trasporti e autorizzazioni duplicate.

Un gateway MCP inserisce un unico punto di controllo al centro. I tuoi agenti si connettono una sola volta; il gateway gestisce a quali server possono accedere, quali strumenti possono vedere, come vengono inserite le credenziali e come ogni chiamata agli strumenti viene instradata o sottoposta ad audit.

Che cos'è un gateway MCP e perché l'IA locale ne ha bisogno?

Il Model Context Protocol offre ai client IA un modo standard per scoprire e chiamare strumenti, risorse e prompt. Il protocollo non richiede che ogni implementazione disponga di un gateway.

Se utilizzi un client IA e uno o due server MCP, le connessioni dirette sono generalmente più semplici:

Client IA
   |
   +---- MCP filesystem
   |
   +---- MCP GitHub

Il problema emerge quando entrambi i lati aumentano.

Claude Code ----\
Codex -----------\
OpenClaw ---------> Gateway MCP
Cline ------------/      |
                     +----+-------+-------+
                     |            |       |
                  GitHub       File    Database
                    MCP         MCP       MCP

Invece di configurare separatamente GitHub, filesystem, database, browser, automazione e server MCP interni in ogni client, il gateway diventa il livello di controllo condiviso.

Questo è particolarmente utile per gli agenti IA locali. Il modello può essere eseguito sul tuo hardware, ma una volta che può chiamare strumenti con privilegi, la località da sola non risolve i problemi di autenticazione, autorizzazione, isolamento o audit.

La domanda architetturale più importante diventa:

Intento del modello
     |
     v
Gateway MCP
     |
Autenticazione / Policy / Filtro degli strumenti
Credenziali / Log / Routing
     |
     v
Strumenti con privilegi

Questo livello gateway è strettamente correlato al confine di fiducia dell'esecuzione degli strumenti: un modello può richiedere un'azione, ma un livello di esecuzione separato dovrebbe decidere se tale azione è effettivamente consentita.

Come abbiamo classificato i migliori gateway e proxy MCP

Questa non è una classifica basata sulle stelle di GitHub e i dieci progetti non risolvono tutti esattamente lo stesso problema.

Alcune sono piattaforme MCP complete. Altre sono gateway di sicurezza, aggregatori, gateway per agenti o proxy di trasporto leggeri. Le abbiamo classificate in base agli aspetti più importanti per l'IA locale e il self-hosting:

• Possibilità di self-hosting: Puoi eseguire il gateway su un'infrastruttura che controlli?
• Aggregazione MCP: Più server MCP possono essere esposti tramite un unico endpoint?
• Filtraggio degli strumenti: Puoi limitare gli strumenti effettivamente visibili a un agente?
• Autenticazione e autorizzazione: Supporta l'identità del client, OAuth, token, RBAC, ACL o motori di policy?
• Gestione delle credenziali: i segreti possono essere centralizzati invece di essere copiati in ogni client AI?
• Supporto dei trasporti: può funzionare tramite stdio, SSE, HTTP trasmissibile o altri modelli di distribuzione?
• Isolamento: i server MCP o l'esecuzione degli strumenti possono essere separati dall'host?
• Osservabilità: sono disponibili log, tracce, metriche o registri di audit?
• Flessibilità di distribuzione: è adatto a un laptop, a un server domestico, a un host Docker, a una macchina virtuale o a un cluster Kubernetes?
• Direzione attuale: il progetto è ancora rilevante per lo stack MCP del 2026, in rapida evoluzione?

L'ordine numerico è editoriale e non corrisponde a un punteggio ottenuto tramite benchmark sintetico.

I 10 migliori gateway e proxy MCP per l'AI locale a colpo d'occhio

1. Docker MCP Gateway — La scelta migliore in assoluto per l'AI locale basata su Docker

Docker MCP Gateway è uno dei punti di partenza più naturali per un ambiente AI locale, perché i server MCP sono in definitiva programmi che hanno bisogno di un luogo sicuro e prevedibile in cui essere eseguiti.

Il gateway di Docker si colloca tra i client AI e i server MCP, centralizzando configurazione, credenziali, instradamento, autenticazione e gestione del ciclo di vita dei server.

La caratteristica più importante per chi gestisce server autonomamente è l'isolamento. Invece di installare direttamente sull'host ogni server MCP e le relative dipendenze, Docker può eseguire i server all'interno di container con restrizioni e controlli su privilegi, accesso alla rete, risorse della CPU e segreti.

Il gateway può anche esporre solo gli strumenti selezionati, invece di riversare nel client ogni strumento di ogni server. Gli strumenti MCP di Docker includono controlli sui profili e sugli strumenti progettati per ridurre il rumore e l'uso superfluo di token.

Un client può connettersi a un unico gateway:

{
  "mcpServers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"]
    }
  }
}

mentre Docker gestisce i processi dei server MCP sottostanti.

Questo si adatta particolarmente bene a un server domestico:

Claude Code / Codex / Cline
            |
     Docker MCP Gateway
            |
    +-------+-------+
    |       |       |
 Filesystem GitHub  n8n
 Container  Server  Server

Ideale per: utenti di IA locali che eseguono già Docker e vogliono un unico gateway, oltre all'esecuzione isolata dei server MCP, alla gestione dei segreti, al filtraggio degli strumenti e ai log centralizzati.

Compromesso: Docker offre ora diverse esperienze MCP correlate, tra cui MCP Toolkit, Gateway, Sandboxes e funzionalità di governance più recenti. Alcune funzionalità di governance dell'IA di Docker sono soggette a restrizioni separate, quindi verifica quale set di funzionalità includa effettivamente la tua distribuzione, invece di presumere che ogni funzionalità MCP di Docker sia disponibile in tutte le edizioni.

2. ToolHive — La migliore piattaforma MCP completa e self-hosted per la gestione

ToolHive va ben oltre un proxy leggero.

La sua architettura è suddivisa in diversi livelli:

• Gateway: espone endpoint MCP controllati ai client;
• Registro: mantiene un catalogo di server e competenze MCP approvati;
• Runtime: distribuisce e gestisce i server MCP;
• Portale: fornisce un'interfaccia di gestione e rilevazione.

Il gateway può aggregare più strumenti, integrarsi con provider di identità OAuth/OIDC, applicare policy di accesso, filtrare strumenti e descrizioni e centralizzare gli audit.

Il runtime può avviare localmente i server MCP tramite Docker o Podman, mentre l'Operatore Kubernetes estende lo stesso approccio a cluster più grandi. Il supporto per OpenTelemetry e Prometheus offre una gestione operativa molto più solida rispetto a un semplice proxy inverso.

Questo rende ToolHive particolarmente interessante per i team. Uno sviluppatore non deve più cercare un repository MCP arbitrario, installarlo manualmente, incollare le credenziali nella configurazione di un client e sperare che tutti gli altri ripetano correttamente la stessa configurazione.

In alternativa:

Registro attendibile
      |
    Runtime
      |
 Server MCP
      |
   Gateway
      |
+-----+------+------+
Claude     Codex   VS Code

Ideale per: team che vogliono riunire in un'unica piattaforma self-hosted la rilevazione, la distribuzione, la sicurezza, le policy, l'osservabilità e l'accesso tramite gateway a MCP.

Compromesso: ToolHive è una piattaforma molto più completa di quanto serva a una configurazione per singolo utente. Se vuoi solo cinque server dietro un unico endpoint, MCPJungle è più semplice.

3. agentgateway — Ideale per il traffico MCP, LLM e agente-agente in un unico livello

agentgateway è uno dei progetti più importanti da tenere d’occhio perché pone una domanda più ampia:

Perché creare un gateway per MCP, un altro per le API LLM e un altro ancora per il traffico da agente ad agente?

La sua architettura combina tre classi di traffico sempre più importanti:

Agente
  |
  +--> Gateway LLM
  |
  +--> Gateway MCP
  |
  +--> Gateway A2A

Per MCP, supporta la federazione degli strumenti insieme ai trasporti stdio, HTTP, SSE e HTTP con streaming. Le opzioni di autenticazione includono OAuth, JWT e chiavi API, mentre RBAC granulare, limitazione della frequenza, TLS e OpenTelemetry forniscono il livello di governance.

Ha anche un orientamento diretto verso l’IA locale: agentgateway può instradare l’inferenza verso modelli self-hosted e infrastrutture di inferenza Kubernetes invece di presumere che ogni chiamata al modello venga inviata a un provider cloud.

Il progetto si sta inoltre adattando attivamente alle nuove generazioni del protocollo MCP, incluse le modifiche molto più ampie del protocollo del 2026 e il problema di compatibilità creato quando client e server si aggiornano in momenti diversi.

Ideale per: infrastrutture IA self-hosted avanzate in cui gli agenti necessitano di un unico livello di connettività per modelli, strumenti e altri agenti.

Compromesso: se il tuo unico problema è consolidare alcuni server MCP locali, agentgateway potrebbe offrire un’architettura più complessa del necessario.

4. MCPJungle — Il miglior gateway self-hosted semplice per più server MCP

MCPJungle è probabilmente il progetto più facile da spiegare di questo elenco:

registra una volta i tuoi server MCP, quindi lascia che i tuoi client IA si connettano a un unico endpoint.

MCP GitHub ------\
MCP Postgres -----\
MCP filesystem ----> MCPJungle ----> /mcp
MCP browser -------/                    |
n8n MCP ----------/          +----------+---------+
                              Claude   Cursor   Codex

Il progetto supporta server MCP remoti e stdio, offrendo al contempo un rilevamento unificato di strumenti, prompt e risorse.

I gruppi di strumenti consentono a una distribuzione di esporre solo un sottoinsieme curato degli strumenti disponibili per un determinato caso d’uso, invece di fornire a ogni client l’intero catalogo degli strumenti.

MCPJungle offre anche un utile percorso dall’infrastruttura personale a quella condivisa. Puoi iniziare con Docker Compose e un endpoint locale, quindi passare a identità client, token di accesso, elenchi espliciti di server consentiti, PostgreSQL e OpenTelemetry man mano che la distribuzione diventa più importante.

Ciò lo rende particolarmente adatto a un home lab. Non è necessario iniziare installando Kubernetes o creando un'architettura di identità aziendale.

Ideale per: sviluppatori e piccoli team che desiderano un unico endpoint MCP ordinato senza adottare una piattaforma di infrastruttura AI molto più ampia.

Compromesso: le funzionalità di governance più avanzate sono legate alle modalità orientate alla produzione o alle aziende, e il suo modello di sicurezza non è ampio quanto quello di ToolHive, agentgateway o di un gateway API maturo.

5. IBM ContextForge — Ideale per federare MCP con API e agenti esistenti

IBM ContextForge diventa particolarmente utile quando la tua infrastruttura non è composta ordinatamente da server MCP.

Gli ambienti reali contengono solitamente un insieme eterogeneo:

Server MCP
API REST
Servizio gRPC
Agente A2A
API interna legacy
       |
       v
  ContextForge
       |
       v
   Client IA

ContextForge funge da registro, proxy e livello di federazione tra servizi MCP, A2A, REST e gRPC.

L'architettura attuale include funzioni di gateway per gli strumenti, traduzione delle API, routing degli agenti, estensibilità tramite plugin, limitazione della velocità, autenticazione, ritentativi e osservabilità basata su OpenTelemetry.

Il progetto ha raggiunto la disponibilità generale 1.0 nel 2026, con ulteriori miglioramenti alla sicurezza, al protocollo, al catalogo e alle modifiche di distribuzione orientate alla produzione.

Può essere eseguito tramite pacchetti Python o Docker e scalare fino a distribuzioni Kubernetes e multi-cluster.

Ideale per: organizzazioni o home lab avanzati che devono esporre sistemi REST/gRPC esistenti agli agenti senza riscrivere ogni servizio come server MCP dedicato.

Compromesso: ContextForge è più ampio di un gateway dedicato esclusivamente a MCP. Questa flessibilità comporta una maggiore complessità operativa rispetto a MCPJungle o Supergateway.

6. Microsoft MCP Gateway — Ideale per server MCP con stato su Kubernetes

Microsoft MCP Gateway è particolarmente adatto quando i server MCP stessi devono diventare infrastrutture gestite.

Il progetto combina un gateway di dati con un piano di controllo.

Il livello dati instrada il traffico MCP, mentre il livello di gestione può rappresentare i server come risorse gestite e gestire le operazioni di distribuzione, aggiornamento ed eliminazione.

La sua caratteristica distintiva è il routing stateful sensibile alla sessione.

Alcuni server MCP non sono endpoint HTTP stateless intercambiabili. Una sessione client potrebbe dover continuare a raggiungere la stessa istanza backend. Microsoft MCP Gateway può instradare le richieste che condividono un ID di sessione verso la stessa istanza server, consentendo comunque l’esecuzione di più istanze dietro il gateway.

Sessione client A ----> Gateway ----> Pod MCP 1
Sessione client A ----> Gateway ----> Pod MCP 1

Sessione client B ----> Gateway ----> Pod MCP 2

Il progetto include inoltre autorizzazione, telemetria, integrazione con il controllo degli accessi e gestione del ciclo di vita, progettate per gli ambienti Kubernetes.

Ideale per: team che utilizzano già Kubernetes e gestiscono flotte di server MCP con stato o gestite dinamicamente.

Compromesso: non è la scelta più ovvia per un singolo server domestico. Docker MCP Gateway o MCPJungle saranno normalmente molto più semplici da gestire.

7. OpenZiti MCP Gateway — Ideale per l’accesso remoto zero-trust agli strumenti MCP privati

OpenZiti MCP Gateway risolve uno dei problemi più pratici dell’IA locale:

Cosa succede quando l’agente e il server MCP non si trovano sulla stessa LAN?

Una configurazione privata comune è questa:

Laptop / client IA
        |
      Internet
        |
 Server domestico / NAS
        |
 Strumenti MCP privati

La soluzione convenzionale consiste spesso nell’esporre un endpoint HTTPS, configurare le regole del firewall, impostare una VPN o mettere un altro reverse proxy davanti al servizio.

OpenZiti adotta invece un approccio overlay zero-trust. Il suo MCP Gateway può esporre gli strumenti interni come servizi invisibili che non ascoltano su indirizzi IP pubblici e non richiedono il tradizionale port forwarding.

Le identità crittografiche, mTLS, l’isolamento per client e i controlli a livello di strumento costituiscono il livello di accesso. Il progetto può inoltre aggregare più backend e collegare server stdio locali a servizi MCP accessibili da remoto.

Questo lo rende particolarmente rilevante per un spazio di lavoro privato per agenti IA, in cui il runtime dell’agente, i file e i servizi risiedono su un server domestico sempre attivo, ma devono essere raggiunti in sicurezza da un altro dispositivo.

Ideale per: utenti che desiderano accedere da remoto a strumenti MCP privati senza esporli direttamente a Internet pubblico.

Compromesso: stai adottando il modello di rete OpenZiti/zrok come parte della soluzione. Se una LAN privata convenzionale o una VPN esistente risolve già il problema della connettività, questa soluzione potrebbe essere superflua.

8. MetaMCP — Ideale per ridurre il sovraccarico di contesto degli schemi degli strumenti

MetaMCP affronta un problema diverso di scalabilità di MCP.

Supponiamo che un agente si connetta direttamente a:

MCP di Playwright      52 strumenti
MCP del database        20 strumenti
MCP di GitHub          30 strumenti
MCP del filesystem      15 strumenti
MCP di monitoraggio      18 strumenti

Il modello potrebbe dover ricevere un’ampia raccolta di schemi JSON degli strumenti prima ancora di iniziare a svolgere attività utili.

Questo consuma contesto e può rendere più rumorosa la selezione degli strumenti.

MetaMCP colloca questi server secondari dietro un’interfaccia piccola e stabile. Il design attuale espone quattro meta-strumenti principali per il rilevamento, il provisioning, le chiamate e l’esecuzione in più passaggi, invece di esporre direttamente lo schema di ogni strumento downstream.

L’architettura diventa:

               +-- Playwright
               +-- GitHub
LLM locale --> MetaMCP -- Database
               +-- File
               +-- Più server

Il modello vede: 4 meta-strumenti

Questo è particolarmente interessante per i modelli locali. I modelli cloud di frontiera dispongono sempre più spesso di contesti ampi e di solide capacità di selezione degli strumenti, ma i modelli self-hosted più piccoli possono essere più sensibili alle dimensioni del prompt e a cataloghi di strumenti estesi.

La documentazione di MetaMCP mostra come il sovraccarico degli schemi possa rimanere pressoché costante quando si aggiungono altri server MCP secondari, invece di crescere linearmente con ogni strumento downstream.

Ideale per: implementazioni locali di IA con molti server MCP, in cui gli schemi degli strumenti consumano troppo contesto o confondono la selezione degli strumenti da parte del modello.

Compromesso: l’astrazione cambia il modo in cui il modello interagisce con gli strumenti. Guadagni efficienza del contesto, ma aggiungi un ulteriore livello di rilevamento e routing tra il modello e gli strumenti MCP reali.

9. Kong AI Gateway — Ideale se utilizzi già un gateway API

Kong AI Gateway è una proposta diversa dai progetti sopra citati, pensati prima di tutto per l’home lab.

Se la tua organizzazione utilizza già Kong per API, autenticazione, routing o governance dei servizi, aggiungere MCP allo stesso piano di controllo può essere più interessante che distribuire una piattaforma MCP completamente separata.

L’architettura attuale di Kong AI Gateway riconosce MCP e A2A oltre al traffico convenzionale dei modelli. La configurazione del server MCP supporta l’aggregazione e il controllo degli accessi a livello di strumento, mentre le funzionalità esistenti del gateway possono fornire autenticazione, routing, metriche e una governance più ampia.

Un schéma utile ressemble à ceci :

Client IA
     |
Kong AI Gateway
     |
+----+-------+--------+
|            |        |
MCP A    MCP B    API REST
|            |
Outils       Outils

Cela devient particulièrement utile lorsque la même plateforme gouverne déjà les API applicatives classiques et le trafic des modèles d’IA.

Idéal pour : les équipes qui utilisent déjà Kong et souhaitent intégrer la gouvernance MCP à une stratégie existante de passerelle API et IA.

Compromis : la disponibilité des fonctionnalités MCP de Kong varie selon le déploiement et la configuration du produit, et certaines recettes plus récentes pour sécuriser MCP sont actuellement soumises à des contraintes propres à Konnect. Ce n’est pas le choix le plus simple pour un petit serveur Docker local.

10. Supergateway — Meilleur pont de transport MCP léger

Supergateway figure sur cette liste pour une raison beaucoup plus ciblée : la compatibilité des transports.

Une grande partie des premiers logiciels MCP reposait sur stdio. Cela est pratique lorsque le serveur MCP s’exécute comme processus enfant sur la même machine que le client IA.

Cela devient peu pratique lorsque le serveur doit fonctionner sur un NAS, une machine virtuelle, un hôte de conteneurs ou une autre machine du réseau.

Supergateway peut faire le lien entre des transports MCP tels que :

stdio
  |
  +--> SSE
  |
  +--> WebSocket
  |
  +--> HTTP Streamable

et il peut convertir l’HTTP Streamable distant en stdio pour les clients qui attendent encore un processus local.

Par exemple, un serveur de fichiers local en stdio peut être exposé en HTTP Streamable :

npx -y supergateway \
  --stdio "npx -y @modelcontextprotocol/server-filesystem ./data" \
  --outputTransport streamableHttp \
  --port 8000

Il prend également en charge les en-têtes, l’authentification par bearer token, les points de terminaison de contrôle d’état, les sessions HTTP Streamable avec état et plusieurs options de déploiement.

Idéal pour : les développeurs qui disposent déjà de serveurs MCP fonctionnels, mais qui doivent faire le lien entre les différences de transport des clients locaux et distants.

Compromis : Supergateway est un proxy de transport, pas une plateforme complète de gouvernance. Il ne remplace pas ToolHive, Docker MCP Gateway ou agentgateway lorsque vous avez besoin de politiques centralisées, de gestion des identités et du cycle de vie, ainsi que d’audit.

Quelle passerelle MCP devriez-vous choisir ?

Docker MCP Gateway vs ToolHive vs MCPJungle

Queste sono tre delle opzioni più rilevanti per un ambiente self-hosted, ma si rivolgono a livelli diversi di complessità.

Scegli Docker MCP Gateway quando Docker è già la base del tuo stack IA self-hosted e l'isolamento dei container è importante.

Scegli ToolHive quando diversi sviluppatori hanno bisogno di un catalogo MCP affidabile, distribuzione centralizzata, integrazione con l'identità, criteri e monitoraggio.

Scegli MCPJungle quando il problema principale è semplicemente che Claude, Codex, Cursor e altri client non debbano più gestire configurazioni MCP duplicate.

Gateway MCP vs proxy vs aggregatore vs ponte di trasporto

La terminologia relativa all'infrastruttura MCP è ancora incoerente, quindi i soli nomi dei prodotti possono trarre in inganno.

Un progetto può svolgere contemporaneamente diverse di queste funzioni. La domanda utile non è come si definisce il repository, ma quale problema di controllo risolve effettivamente.

Come creare un'architettura gateway MCP locale

Una configurazione locale pratica non deve partire da una piattaforma gigantesca.

Inizia con quattro livelli:

Client IA
Claude Code / Codex / OpenClaw
             |
             v
        Gateway MCP
             |
    +--------+--------+
    |        |        |
 File     GitHub   Automazione
 MCP       MCP       MCP
    |
Archiviazione locale / NAS

Tieni il gateway vicino agli strumenti

Se la maggior parte dei server MCP accede a file locali, Docker, Home Assistant, database, repository Git o API private, in genere il gateway dovrebbe trovarsi sulla stessa rete di server attendibili, anziché su ogni laptop degli sviluppatori.

Questa architettura rispecchia quella di un spazio di lavoro privato per agenti IA: il client può spostarsi, ma lo storage privato, il runtime, i log e i servizi di automazione rimangono su un host sempre attivo.

Separa l'hosting del modello dall'hosting MCP

Il gateway MCP non deve necessariamente essere eseguito sulla stessa macchina dell'LLM.

Host dell'agente             Server GPU
    |                       |
Gateway MCP              Ollama
    |                     vLLM
Strumenti locali
    |
File / DB / API

Questo è importante perché il traffico MCP è solitamente leggero rispetto all'inferenza. Un server sempre attivo di fascia media può ospitare il gateway e i servizi degli strumenti, mentre una workstation o un nodo GPU gestisce il modello.

Usa set di strumenti curati invece di esporre tutto

Probabilmente un agente di programmazione non ha bisogno dei controlli della casa intelligente. Un agente di ricerca probabilmente non ha bisogno dell'amministrazione di Docker. Un assistente per la conoscenza personale non dovrebbe ereditare automaticamente l'accesso ai database di produzione.

Crea profili o gruppi di strumenti separati:

programmazione
  - github
  - filesystem-dev
  - documenti

ricerca
  - browser
  - articoli
  - conoscenza-locale

home-ops
  - monitoraggio
  - home-assistant
  - docker-readonly

Questo si integra naturalmente con i flussi di lavoro di IA locale: il livello MCP determina quali funzionalità esistono, mentre le competenze e le istruzioni dell'agente determinano come e quando tali funzionalità devono essere utilizzate.

Perché il filtraggio degli strumenti è importante per i modelli locali

La sicurezza è solo uno dei motivi per limitare gli strumenti.

Anche il contesto è un fattore.

Ogni strumento può contribuire con un nome, una descrizione, argomenti, uno schema JSON e altri metadati alla superficie degli strumenti disponibili per il modello.

Con una manciata di strumenti, è banale.

Con centinaia di strumenti, può diventare parte del budget del prompt:

5 server MCP
x 20 strumenti
= 100 schemi di strumenti

20 server MCP
x 20 strumenti
= 400 schemi di strumenti

Ciò può ridurre il contesto disponibile per la conversazione, il codice del repository, i documenti recuperati, il ragionamento e l'output.

Può anche rendere più difficile la selezione degli strumenti. Se un agente vede diversi strumenti di ricerca, interrogazione, recupero, lettura o esecuzione con nomi simili, scegliere quello giusto diventa un ulteriore compito di ragionamento.

Esistono tre soluzioni principali:

• Filtraggio degli strumenti: esporre solo gli strumenti pertinenti a un agente specifico.
• Gruppi o profili di strumenti: fornire cataloghi diversi a client diversi.
• Meta-routing: esporre una piccola interfaccia di individuazione e chiamata, quindi risolvere gli strumenti downstream su richiesta.

Docker MCP Gateway e ToolHive enfatizzano il filtraggio e l'esposizione curata. MCPJungle offre gruppi di strumenti. MetaMCP si spinge oltre, trasformando molti strumenti secondari in una piccola superficie stabile di meta-strumenti.

Questo è ancora più importante quando MCP si connette a una base di conoscenza locale, perché gli schemi degli strumenti ora competono con i documenti e il contesto recuperato per la stessa finestra del modello.

Checklist di sicurezza del gateway MCP per l'IA locale

Un gateway non è utile semplicemente perché tutto il traffico lo attraversa. Il valore deriva da ciò che il gateway applica effettivamente.

Autentica il client

Il gateway dovrebbe sapere se il chiamante è Codex su una macchina per sviluppatori, un agente sempre attivo, un processo CI o un altro servizio.

Non considerare “all'interno della mia LAN” come un'identità.

Autorizza separatamente server e strumenti

L'accesso al server MCP di GitHub non implica necessariamente l'accesso a ogni strumento di GitHub.

Una policy utile può consentire:

read_issue
list_pull_requests
search_code

negando al contempo:

merge_pull_request
delete_repository
change_branch_protection

Mantieni le credenziali fuori dai file di configurazione degli agenti

Uno dei principali vantaggi di un gateway è spostare le chiavi API e le credenziali dei servizi fuori da ogni singolo client AI.

Il flusso ideale è:

Agente
  |
Richiesta dello strumento
  |
Gateway
  |
Inserisci una credenziale con ambito limitato
  |
Server MCP

Il modello non deve visualizzare il token sottostante.

Isola i server MCP non attendibili

Un server MCP è un software eseguibile.

Se un server è installato da un repository di terze parti, trattalo come qualsiasi altra dipendenza software. Esamina il pacchetto, blocca le versioni quando è pratico farlo, limita l'accesso alla rete e al file system e usa container o altri sistemi di isolamento quando appropriato.

Registra le chiamate agli strumenti, non solo gli errori HTTP

Quando un agente modifica un file o aggiorna un sistema esterno, hai bisogno di informazioni sufficienti per ricostruire:

• quale client ha effettuato la richiesta;
• quale strumento è stato selezionato;
• quali argomenti sono stati approvati;
• quale risultato è stato restituito;
• se l'effetto collaterale è stato effettivamente completato.

Ecco perché l'osservabilità è un fattore di valutazione fondamentale, non un extra riservato alle aziende.

Rimuovi i percorsi di bypass

Un gateway MCP configurato con cura non definisce il vero confine di sicurezza se lo stesso agente dispone anche di:

• una shell dell'host senza restrizioni;
• un socket Docker scrivibile;
• credenziali amministrative;
• accesso root diretto al database;
• un'altra connessione MCP senza restrizioni.

Il confine di fiducia dell'esecuzione degli strumenti è significativo solo quando le azioni privilegiate lo attraversano effettivamente.

Hai davvero bisogno di un gateway MCP?

Probabilmente no, se la tua configurazione è simile a questa:

Un client AI
   |
Due server MCP

Aggiungere un gateway significherebbe creare un altro servizio da installare, aggiornare, proteggere, monitorare e sottoporre a debug.

Un gateway inizia ad avere senso quando si verificano diverse di queste condizioni:

• utilizzi più client IA;
• hai diversi server MCP;
• gli stessi server MCP vengono configurati ripetutamente;
• le credenziali sono duplicate sui computer client;
• agenti diversi devono poter vedere strumenti diversi;
• i dispositivi remoti devono accedere ai servizi MCP privati;
• ti servono i log di audit;
• alcuni server MCP dovrebbero essere eseguiti in isolamento;
• gli schemi degli strumenti stanno consumando troppo contesto del modello;
• devi collegare i trasporti stdio e di rete;
• la distribuzione sta diventando un’infrastruttura condivisa.

Una regola utile è:

1 client + 2 server
        ↓
MCP diretto va bene

Più client + più server
        ↓
Il gateway inizia a essere utile

Team + credenziali + policy + audit
        ↓
Il gateway diventa infrastruttura

Dove si colloca Soth MCP Proxy

Vale la pena tenere d’occhio anche Soth MCP Proxy, soprattutto se la tua priorità è collocare un livello di policy di sicurezza davanti a una distribuzione MCP esistente.

Il design attuale include l’applicazione delle policy OPA/Rego, la registrazione persistente degli audit, i controlli delle sessioni, le metriche Prometheus, gli endpoint di integrità e TLS.

Questa è un’architettura utile:

Agente
  |
Soth Policy Proxy
  |
Server MCP esistente

Non lo abbiamo inserito nella Top 10 principale perché è ancora un progetto molto più giovane rispetto alla maggior parte dei gateway elencati sopra e diverse funzionalità di trasporto e amministrazione fanno ancora parte della sua roadmap.

Per ora, consideralo un promettente proxy di sicurezza leggero, piuttosto che una piattaforma matura per la gestione di MCP.

La svolta del 2026: il gateway MCP sta diventando infrastruttura per gli agenti

La prima domanda su MCP era:

Come collego il mio assistente IA a questo strumento?

La domanda più recente è:

Come posso gestire ogni strumento utilizzato da ogni agente?

Questo cambia l’architettura.

2025

Agente
  |
Server MCP
  |
Strumento


2026

Agenti
  |
Gateway per agenti / MCP
  |
Identità
Policy
Routing
Credenziali
Individuazione degli strumenti
Osservabilità
Traduzione del protocollo
  |
Molti server MCP
  |
API / File / Database / Servizi

Per questo progetti come agentgateway e ContextForge non si fermano più a MCP. Si stanno espandendo anche verso il routing dei modelli e i protocolli da agente ad agente.

Il gateway sta diventando il livello di connettività e governance tra il ragionamento probabilistico dell’IA e i sistemi in grado di svolgere concretamente il lavoro.

Per gli utenti che stanno già sperimentando strumenti IA CLI e agenti di programmazione, questo aspetto diventerà probabilmente sempre più importante. Un agente di programmazione con cinque strumenti è un’applicazione. Dieci agenti che condividono cinquanta strumenti sono infrastruttura.

Verdetto finale

Scegli Docker MCP Gateway se il tuo stack IA locale funziona già su Docker e vuoi una combinazione pratica di gestione del ciclo di vita dei server MCP, isolamento dei container, credenziali, filtraggio e accesso centralizzato.

Scegli ToolHive se MCP sta diventando un’infrastruttura condivisa dal team e ti servono un registro, un runtime, un gateway, criteri e un livello di osservabilità, anziché un singolo proxy.

Scegli agentgateway se prevedi che il traffico MCP, il traffico dei modelli e la comunicazione tra agenti convergano dietro un unico gateway nativo per l’IA.

Scegli MCPJungle se vuoi il percorso più semplice dalle configurazioni sparse dei client MCP a un unico endpoint self-hosted.

Scegli IBM ContextForge se il tuo ambiente include API REST o gRPC esistenti che dovrebbero diventare utilizzabili insieme a MCP e ai servizi per agenti.

Scegli Microsoft MCP Gateway se la tua flotta di server MCP appartiene già a Kubernetes e necessita di instradamento consapevole della sessione e controllo del ciclo di vita.

Scegli OpenZiti MCP Gateway se gli agenti devono accedere da remoto a strumenti MCP privati senza esporre tali servizi su porte pubbliche.

Scegli MetaMCP se il problema principale non è la connettività, ma il numero di schemi degli strumenti che consumano contesto e confondono i modelli locali.

Scegli Kong AI Gateway quando MCP deve diventare un’altra classe di traffico governata all’interno di una piattaforma API e IA esistente basata su Kong.

Scegli Supergateway quando ti serve semplicemente un bridge ordinato tra i trasporti MCP stdio e di rete.

Pertanto, il miglior gateway MCP non è necessariamente quello con l’elenco di funzionalità più lungo. È il più piccolo livello di controllo in grado di risolvere il problema effettivamente raggiunto dal tuo stack di agenti.

Domande frequenti

Che cos’è un gateway MCP?

Un gateway MCP si interpone tra i client IA e i server MCP. Può aggregare più server dietro un unico endpoint e aggiungere funzionalità come instradamento, autenticazione, controllo degli accessi, gestione delle credenziali, filtraggio degli strumenti, registrazione, osservabilità, isolamento o conversione del trasporto.

Ho bisogno di un gateway MCP per l’IA locale?

Non sempre. Un singolo client IA connesso a uno o due server MCP funziona solitamente bene senza un gateway. I gateway diventano più utili quando più client condividono più server MCP, credenziali, criteri, accesso remoto o requisiti di audit.

Qual è il miglior gateway MCP per un server domestico?

Docker MCP Gateway e MCPJungle sono due ottimi punti di partenza. Docker MCP Gateway è adatto agli utenti che usano già Docker e offre isolamento dei container e gestione del ciclo di vita. MCPJungle è interessante quando l’obiettivo principale è mettere più server MCP dietro un unico endpoint ordinato.

Qual è la differenza tra un gateway MCP e un proxy MCP?

Un proxy inoltra principalmente il traffico e può aggiungere alcuni controlli selezionati. Un gateway di solito funge da piano di controllo più ampio, con routing, gestione delle identità, policy, aggregazione, gestione delle credenziali, discovery, osservabilità o gestione del ciclo di vita. Nella pratica, i progetti spesso usano i termini in modo intercambiabile.

Un singolo gateway MCP può connettere più client IA?

Sì. Uno dei principali vantaggi di un gateway è consentire a Claude, Codex, Cursor, Cline, OpenClaw o agli agenti personalizzati di riutilizzare un’infrastruttura MCP condivisa invece di configurare ogni server MCP separatamente in ogni client.

Un gateway MCP può ridurre l’uso dei token?

Sì, se filtra o astrae gli schemi degli strumenti prima che arrivino al modello. Docker MCP Gateway e ToolHive possono esporre set di strumenti selezionati, MCPJungle supporta i gruppi di strumenti e MetaMCP riduce un ampio catalogo di strumenti downstream a un piccolo insieme di meta-strumenti.

Qual è il miglior gateway MCP per i modelli locali?

Per l’IA locale in generale, Docker MCP Gateway e MCPJungle sono opzioni pratiche. MetaMCP è particolarmente interessante quando i modelli locali più piccoli hanno difficoltà con cataloghi di strumenti estesi, mentre agentgateway è pertinente quando il routing dell’inferenza self-hosted e la governance di MCP devono risiedere nello stesso livello dell’infrastruttura.

Posso esporre un server MCP stdio tramite HTTP?

Sì. Supergateway può convertire i server MCP stdio nei trasporti Streamable HTTP, SSE o WebSocket. Anche altri gateway possono collegare o fare da proxy per i server stdio locali, trasformandoli in endpoint MCP accessibili dalla rete.

Come posso accedere in sicurezza a un server MCP al di fuori della mia rete domestica?

Usa una rete privata autenticata o un gateway progettato per l’accesso remoto invece di limitarti a inoltrare una porta pubblica. OpenZiti MCP Gateway è progettato specificamente per rendere accessibili da remoto i servizi MCP privati tramite un overlay zero-trust, senza esporre direttamente il server su un IP pubblico.

Un gateway MCP è un confine di sicurezza?

Può farne parte, ma solo se l’accesso agli strumenti privilegiati passa effettivamente da lì. Se lo stesso agente IA dispone anche di accesso illimitato alla shell, credenziali di amministratore, un socket Docker scrivibile o connessioni dirette che bypassano il gateway, quest’ultimo non definisce il vero confine di esecuzione.

I server MCP dovrebbero essere eseguiti in Docker?

I container sono utili per isolare le dipendenze dei server MCP, l’accesso al file system, l’accesso alla rete e l’utilizzo delle risorse. Docker MCP Gateway e ToolHive pongono entrambi l’esecuzione containerizzata di MCP al centro del loro approccio, ma i container non sostituiscono l’autenticazione, l’autorizzazione, il filtraggio degli strumenti o l’audit.

Qual è la differenza tra MetaMCP e un normale gateway MCP?

Un gateway convenzionale in genere aggrega e gestisce i server MCP, rendendone disponibili gli strumenti. MetaMCP fa un passo ulteriore nascondendo ampi cataloghi di strumenti downstream dietro un insieme molto ridotto di meta-strumenti, riducendo il sovraccarico dello schema nel contesto del modello.