Gateway MCP: come gestire più server MCP su larga scala

Per molti di noi, tutto inizia con un unico server MCP. Uno sviluppatore effettua una connessione tra GitHub e Claude o Cursor, e funziona. Poi qualcuno aggiunge Slack, poi Jira, poi un database interno.

Sei mesi dopo, ogni sviluppatore ha il proprio file di configurazione, le proprie chiavi API e il proprio elenco di server.

Ora non sapete quali agenti possano accedere ai dati di produzione. Se un ingegnere lascia l’azienda, dovete effettuare il monitoraggio di ogni singolo token che ha creato. Aggiungere un nuovo server significa aggiornare manualmente 15 configurazioni client.

La parte preoccupante: quando un agente fa qualcosa di inaspettato, non esiste un unico log in grado di spiegare perché ciò sia accaduto.

I token rappresentano il secondo costo. Ogni server connesso carica le definizioni dei propri strumenti nella finestra di contesto. In una configurazione a cinque server, Anthropic ha misurato circa 55.000 token relativi alle definizioni degli strumenti prima che l’agente leggesse una singola richiesta.

Pertanto, la gestione di più server MCP si riduce a due compiti: controllare gli accessi da un unico punto e mantenere ridotto l’elenco degli strumenti di ciascun agente. Un gateway MCP gestisce il primo aspetto per impostazione predefinita. Gestisce il secondo solo quando filtra o ricerca gli strumenti. Esamineremo cinque gateway che vale la pena valutare, i rispettivi costi e come implementarne uno senza compromettere il funzionamento degli agenti.

Che cos’è un gateway MCP?

Quando arriva una richiesta, il gateway verifica chi la sta inviando e quali strumenti quell’utente o agente può visualizzare. Recupera le definizioni degli strumenti da ciascun server a monte e aggiunge un prefisso ai nomi in modo che github_create_issue e jira_create_issue non entrino in conflitto. Tutto ciò che è stato filtrato viene scartato, così il modello vede un unico elenco pulito.

Quando il modello seleziona uno strumento, il gateway instrada la richiesta al server che lo ospita e allega le credenziali di quel server. Nella maggior parte dei prodotti, l’agente non le detiene mai. Ogni richiesta passa attraverso un unico punto, quindi il gateway può registrare cosa è stato richiesto, da chi e quale risposta è stata ricevuta.

La selezione dello strumento e la sicurezza del server dipendono comunque da come si configurano il filtraggio e le autorizzazioni, argomenti che tratteremo nella sezione "Come fare per..." qui di seguito.

In che modo un gateway MCP si differenzia da un registro, da un gateway LLM o da un gateway API?

Tutti e quattro fungono da intermediari tra un client e ciò di cui ha bisogno, ed è per questo che i team tendono a confonderli.

La differenza sta nel tipo di traffico gestito da ciascuno. Un gateway MCP decide se un agente può richiamare uno strumento, mentre un registry si limita a indicare ai client quali server sono disponibili e non trasmette mai una richiesta. I gateway LLM e API gestiscono tipi di traffico diversi: il primo seleziona il modello che risponde a un prompt, mentre il secondo protegge le normali chiamate HTTP ai vostri servizi.

In pratica, i confini sono sfumati. Ad esempio, strumenti come Kong AI Gateway instradano il traffico LLM e MCP attraverso un unico piano di controllo, mentre ContextForge gestisce un registro insieme al proprio gateway. Quando si confrontano i prodotti, è importante verificare quali livelli ciascuno di essi copra effettivamente.

Il Registro MCP ufficiale è stato lanciato nel settembre 2025, con il sostegno di Anthropic, GitHub, PulseMCP e Microsoft. A distanza di un anno, è ancora in fase di anteprima. Usatelo per individuare i server, ma mantenete il vostro elenco personale di quelli approvati.

Un gateway MCP riduce l'utilizzo dei token?

Sì, ma solo quando filtra o cerca gli strumenti. Ogni server MCP è dotato di una serie di strumenti, e ciascuno di essi ha una descrizione scritta che l'IA deve leggere prima di poterlo utilizzare. E quelle descrizioni consumano token. Un gateway riunisce tutti i vostri server in un unico posto. A meno che non lo configuriate per filtrare, continua a mostrare all'IA ogni strumento proveniente da ogni server, quindi l'IA legge la stessa mole di descrizioni di prima.

Si risparmiano token solo quando il gateway nasconde gli strumenti di cui un'attività non ha bisogno.

Il costo è solo metà del problema. Un punto di errore comune si verifica quando il modello sceglie lo strumento sbagliato o passa parametri errati. Ciò accade soprattutto quando i nomi degli strumenti sono simili, come notification-send-user e notification-send-channel. Il documento di Anthropic indica che la selezione degli strumenti inizia a peggiorare quando si superano i 30-50 strumenti disponibili, e bastano pochi server per superare tale soglia.

La soluzione raccomandata da Anthropic consiste nel caricare uno strumento di ricerca in anticipo e richiamare solo i tre-cinque strumenti necessari per un'attività. In un test con oltre 50 strumenti MCP, il contesto totale è sceso da circa 77.000 token a circa 8.700, il che, secondo Anthropic, corrisponde a una riduzione dell’85%. Anche l’accuratezza nelle valutazioni interne di MCP è aumentata: Opus 4 è passato dal 49% al 74% con la ricerca degli strumenti abilitata, mentre Opus 4.5 è passato dal 79,5% all’88,1%.

Le conclusioni dell’azienda sull’esecuzione del codice con MCP vanno ancora oltre. Quando un agente ha esaminato una cartella di file di strumenti e ha letto solo le definizioni di cui aveva bisogno, un flusso di lavoro da Google Drive a Salesforce è sceso da 150.000 token a 2.000. Tuttavia, questo approccio richiede un ambiente in sandbox per il codice scritto dall’agente, il che comporta un costo operativo a sé stante.

I gateway offrono due modi per affrontare la questione.

Il primo consiste nel ridurre manualmente l’elenco degli strumenti. I profili di Docker consentono di inserire singoli strumenti nella lista dei consentiti per ogni server, i server virtuali di ContextForge pubblicano un insieme selezionato con cura attingendo da diversi server a monte, mentre il Tool Router di Composio può vincolare una sessione a un elenco fisso.

Il secondo aspetto riguarda la ricerca al momento della chiamata. AgentCore Gateway include uno strumento di ricerca semantica integrato che gli agenti query in linguaggio naturale, e Composio è in grado di individuare gli strumenti anche in fase di esecuzione.

La linea guida di Anthropic è quella di intervenire quando le definizioni superano i 10.000 token o quando si dispone di 10 o più strumenti di IA. La maggior parte delle configurazioni di automazione dei flussi di lavoro basate sull’IA supera rapidamente tale soglia, mentre i flussi di lavoro multi-agente la superano ancora prima.

Quali sono i migliori gateway MCP?

Molti prodotti si definiscono gateway MCP, ma alcuni sono più simili a semplici directory di server. Questo elenco si limita agli strumenti che si collocano al centro della vostra configurazione. I vostri agenti si connettono a un unico endpoint, il gateway raggiunge i server che si trovano dietro di esso e voi ottenete almeno un controllo effettivo su ciò che passa attraverso il sistema.

Tale controllo potrebbe consistere in un'autenticazione, un elenco di strumenti consentiti o un registro di audit.

Cinque hanno superato la selezione. Risolvono tutti lo stesso problema, ma in modi diversi. La scelta giusta dipende da dove sono già in esecuzione i vostri agenti: il laptop di uno sviluppatore, la vostra infrastruttura, una configurazione Kong esistente, AWS o applicazioni SaaS.

1. Gateway MCP di Docker (ideale per lo sviluppo locale su Docker desktop)

Docker MCP Gateway è il motore open source alla base del MCP Toolkit in Docker Desktop. Se si utilizza già Desktop con il toolkit attivato, il gateway funziona in background senza alcuna configurazione aggiuntiva. La sua risposta alla proliferazione dei server è rappresentata dai container. Ogni server MCP viene eseguito nel proprio container con privilegi, accesso alla rete e risorse limitati, e il gateway lo avvia solo quando un agente necessita di uno dei suoi strumenti.

I profili mantengono la configurazione in un unico posto. Un profilo raggruppa i server necessari a un progetto e ogni client a cui ci si connette, che sia Cursor, VS Code, Claude Desktop o Claude Code, utilizza quella stessa configurazione. È possibile caricare un profilo su un registro OCI affinché i colleghi possano scaricarlo, sostituendo così 15 file di configurazione modificati manualmente con un'unica definizione condivisa.

All’interno di un profilo, è possibile attivare singoli strumenti, come `github.create_issue`, lasciando disattivato il resto del server. È così che Docker mantiene breve l’elenco degli strumenti del modello.

Le credenziali non vengono inserite nei file di configurazione. Il gateway preleva le credenziali dall’archivio di Docker Desktop e le aggiunge all’avvio di un server, gestendo inoltre l’accesso OAuth per i server che ne hanno bisogno. La registrazione integrata e il tracciamento delle chiamate mostrano quali strumenti sono stati eseguiti. Il gateway si limita a instradare le chiamate, mentre l’elaborazione avviene negli agenti AI che si utilizzano per l’automazione. Per iniziare, il Catalogo MCP di Docker elenca oltre 200 strumenti e servizi.

Dove fallisce: il gateway è progettato per gli sviluppatori che eseguono server sui propri computer. La versione dedicata alla governance, venduta come parte di Docker AI Governance, è disponibile solo su invito tramite il reparto commerciale di Docker, quindi non è possibile registrarsi autonomamente per ottenere i controlli sulle politiche a livello di team. È possibile eseguire il gateway senza Docker Desktop tramite un’installazione manuale, ma la gestione delle credenziali sensibili dipende comunque da Desktop.

Cosa dicono gli utenti reali riguardo a Docker MCP Gateway

Una recensione di un utente recita:

Il gateway MCP di Docker è davvero ottimo per lo sviluppo locale – isolamento dei container per server, gestione delle credenziali integrata in Docker Desktop – ma non è realmente progettato per la governance dell’azienda che coinvolge più team e più regioni.

2. IBM ContextForge (Ideale per set di strumenti self-hosted e specifici per ogni team)

IBM ContextForge è un gateway e un registro open source che si esegue sulla propria infrastruttura. Raggruppa server MCP, servizi agent-to-agent (A2A) e normali API REST o gRPC dietro un unico endpoint. È possibile installarlo da PyPI, eseguirlo come container o distribuirlo su Kubernetes utilizzando il chart Helm del progetto.

Ciò che lo contraddistingue è il server virtuale. Si scelgono gli strumenti tra tutti quelli registrati nel gateway, li si raggruppa sotto un unico nome e si indirizza un client all’endpoint di quel pacchetto. Un agente del reparto finanziario ottiene gli strumenti finanziari, un agente dell’assistenza ne riceve un set diverso, e nessuno dei due carica le definizioni dell’altro. Ogni server virtuale può essere privato, condiviso con un team o pubblico.

Inoltre, trasforma le API già in vostro possesso in strumenti MCP. È sufficiente indirizzarlo verso un endpoint REST e lo strumento estrae automaticamente lo schema JSON. Lo strumento traduce anche i servizi gRPC tramite la riflessione del server. Ciò vi evita di dover scrivere un server wrapper per ogni API interna.

Ogni server a monte mantiene le proprie impostazioni OAuth e ContextForge memorizza i token per utente, consentendo così a due server di utilizzare provider di identità diversi. L'interfaccia dell'amministratore include un visualizzatore di log in tempo reale e le tracce vengono inviate tramite OpenTelemetry a backend quali Jaeger, Zipkin e Datadog. Oltre 40 plugin aggiungono ulteriori protocolli di trasporto e integrazioni.

I limiti: È necessario gestirlo, aggiornarlo e scalarlo autonomamente. Il gateway non si avvierà finché non si generano chiavi segrete sicure. Il progetto raccomanda PostgreSQL per l’ambiente di produzione, mentre il supporto viene fornito tramite problemi e discussioni su GitHub.

Cosa dicono gli utenti reali di IBM ContextForge

Una recensione di un utente recita:

Con licenza Apache, progettato per chi gestisce già infrastrutture Kubernetes su larga scala. È maturato fino a diventare uno strumento davvero efficiente: offre governance e monitoraggio effettivi ed è in grado di gestire l’MCP insieme alle altre API aziendali. È però più impegnativo da implementare rispetto alle opzioni più leggere: non è un progetto da realizzare in un fine settimana.

3. Kong AI Gateway (Ideale per i team che utilizzano già Kong)

Kong tratta il traffico MCP come un altro tipo di traffico API. Se il vostro team utilizza già Kong Gateway o Kong Konnect, il supporto MCP è disponibile sotto forma di plugin sul gateway che già gestite. Utilizzerà le stesse funzionalità di autenticazione, limitazione della frequenza e registrazione dei log che utilizzate per le vostre API.

L'elemento centrale è il plugin AI MCP Proxy. Può essere posizionato davanti a un server MCP già in esecuzione oppure trasformare qualsiasi API con uno schema OpenAPI in strumenti MCP senza codice personalizzato. È inoltre possibile combinare strumenti provenienti da diverse API in un unico endpoint MCP, in modo che gli agenti si connettano una sola volta anziché una volta per ogni servizio.

Il controllo degli accessi funziona strumento per strumento. Si impostano elenchi di autorizzazioni e di negazioni per singolo utente o gruppo di utenti e, quando un agente richiede l’elenco degli strumenti a sua disposizione, Kong restituisce solo gli strumenti che quel specifico chiamante può utilizzare. Ogni tentativo autorizzato o negato viene registrato nel log di audit del plugin. Poiché un agente non carica mai strumenti che non può chiamare, l’elenco filtrato mantiene anche il contesto più snello.

L'accesso avviene tramite i plugin di autenticazione di Kong, tra cui OpenID Connect e il plugin AI MCP OAuth2. I log di traffico MCP registrano gli ID di sessione, i metodi JSON-RPC, i payload, le latenze e gli errori, ed è possibile inviare le tracce a OpenTelemetry. Se si instrada anche il traffico LLM attraverso l'AI Gateway di Kong, il traffico dei modelli e quello degli strumenti condividono un unico piano di controllo.

Limiti: su Konnect, l’SSO e i log di audit della piattaforma sono disponibili solo nella versione Enterprise. Il plugin AI MCP Proxy non supporta gli upstream WebSocket o gRPC, e le protezioni AI non si applicano alle richieste MCP. La conversione REST richiede uno schema OpenAPI valido per ogni API, mentre le ACL per singolo strumento richiedono Kong Gateway 3.13 o versioni successive. Anche i ping provenienti dai client MCP vengono conteggiati nel totale mensile delle richieste.

Cosa dicono gli utenti reali di Kong IA Gateway

Una recensione di un utente recita:

Ha senso se state già utilizzando Kong. Non si tratta più solo di MCP aggiunto come un'appendice, ma di un vero e proprio supporto progettato appositamente, che include il traffico da agente ad agente; inoltre, a metà luglio hanno stretto una partnership con un'azienda specializzata in governance basata sull'IA per integrare direttamente nel gateway i controlli delle policy. Alcune delle funzionalità/funzionalità più avanzate, tuttavia, richiedono probabilmente un piano a pagamento.

4. Amazon Bedrock AgentCore Gateway (Ideale per gli agenti in esecuzione su AWS)

Amazon Bedrock AgentCore Gateway è l’opzione completamente gestita da AWS, quindi non c’è nulla da ospitare o scalare. Offre agli agenti un unico endpoint per i loro strumenti. AgentCore trasforma inoltre le specifiche OpenAPI e Smithy, le funzioni Lambda e i server MCP esistenti in strumenti MCP senza codice personalizzato. Include integrazioni con un solo clic per Salesforce, Slack, Jira, Asana e Zendesk.

La ricerca degli strumenti è integrata. Se si attiva la ricerca semantica durante la creazione di un gateway, gli agenti ottengono uno strumento di ricerca (x_amz_bedrock_agentcore_search) che possono queryare in linguaggio naturale. In questo modo, recuperano solo gli strumenti necessari per un'attività, invece di caricare l'intero catalogo. Si tratta dello stesso modello on-demand descritto da Anthropic, eseguito sul gateway anziché sul client.

L'autenticazione funziona in entrambe le direzioni. In entrata, il gateway verifica chi sta effettuando la chiamata tramite AWS IAM o un JWT proveniente dal proprio provider di identità. In uscita, effettua l'accesso a ciascuno strumento tramite OAuth, una chiave API o un ruolo IAM e aggiunge autonomamente tali credenziali, in modo che gli agenti non le conservino mai. AgentCore Identity non comporta alcun costo aggiuntivo quando lo si utilizza tramite il gateway, mentre AgentCore Policy può verificare ogni chiamata agli strumenti in base alle regole scritte in Cedar.

Il gateway funziona con framework open source, tra cui CrewAI, LangGraph, LlamaIndex e Strands Agents, e con qualsiasi modello. Un aggiornamento del giugno 2026 ha aggiunto prompt e risorse MCP, gestione dello streaming e delle sessioni, richiesta di approvazioni durante l’esecuzione delle attività e scambio di token OAuth «on-behalf-of».

I suoi limiti: funziona solo su AWS, quindi non è possibile ospitarlo autonomamente. Il prezzo è basato sull’utilizzo per diversi servizi di AgentCore, il che rende i costi mensili più difficili da prevedere rispetto a un canone forfettario. Nell’esempio fornito dalla stessa AWS, un agente che gestisce 50 milioni di interazioni al mese, con una ricerca e quattro chiamate agli strumenti ciascuna, costa circa 2.250 dollari al mese, e la ricerca rappresenta più della metà di tale importo. La ricerca semantica è disponibile in 18 regioni AWS. Ogni gateway accetta solo le versioni del protocollo MCP configurate dall’utente, mentre l’osservabilità viene gestita tramite CloudWatch a un costo separato.

Cosa dicono gli utenti reali di Amazon Bedrock AgentCore Gateway?

Una recensione di un utente recita:

La complessità deriva da diversi aspetti: 1) gli utenti devono configurare le credenziali e gli ambienti AWS; 2) gli sviluppatori devono scrivere e annotare integralmente il proprio codice agente per utilizzare AgentCore; e 3) la gestione del contesto richiede modelli di programmazione specifici che potrebbero non funzionare con tutti i framework.

5. Composio (Ideale per la connessione degli agenti alle app SaaS senza dover gestire server)

Composio è una piattaforma gestita che collega gli agenti a oltre 1.500 applicazioni, tra cui Gmail, Slack, GitHub, HubSpot e Salesforce. Non è necessario gestire alcun server. Il vostro agente o client IA si connette a un unico URL MCP e Composio gestisce l'accesso a ciascuna applicazione, dai flussi OAuth e dalle chiavi API all'aggiornamento dei token.

La maggior parte del lavoro del gateway avviene nel Tool Router. Si crea una sessione per ogni utente con i toolkit di cui ha bisogno e Composio restituisce un endpoint MCP con ambito definito. All’interno di una sessione, è possibile fissare un elenco preciso di strumenti, bloccarne alcuni specifici o filtrare in base a indicazioni MCP quali “sola lettura” o “distruttivo”. Lo strumento può anche effettuare ricerche nel proprio catalogo in fase di esecuzione e caricare solo gli strumenti necessari per un’attività, mantenendo così ridotto il contesto dell’agente.

Le autorizzazioni possono richiedere che un utente approvi le chiamate degli strumenti ad ogni singola chiamata o una volta per sessione, con opzioni di override "sempre consentito" o "sempre negato" per singolo strumento. Le sessioni vengono create per utente, quindi gli account collegati di ogni utente rimangono separati e un utente può collegare più di un account alla stessa app. Se un'app non è presente nel catalogo ma dispone di un server MCP, è possibile aggiungerla gratis come server personalizzato.

Funziona con Claude, ChatGPT, Cursor, Claude Code e qualsiasi altro client MCP, oltre che con framework quali LangChain, LlamaIndex, CrewAI e l’OpenAI Agents SDK. Per le attività in più fasi, Composio offre un runtime remoto in cui ogni esecuzione avviene in una propria sandbox isolata. L’azienda dichiara la conformità SOC 2 Tipo II e la certificazione ISO 27001:2022.

Funzionalità distintive

Prezzi

Valutazioni

Limiti: Trattandosi di un servizio gestito, le chiamate agli strumenti e le credenziali memorizzate degli utenti passano attraverso il cloud di Composio, a meno che non si configuri una distribuzione "bring-your-own-cloud". Durante la connessione tramite MCP, gli hook delle chiamate agli strumenti dell’SDK e le modifiche allo schema non vengono eseguiti, e gli strumenti personalizzati definiti nel proprio codice non sono disponibili sull’endpoint MCP. Nel maggio 2026, Composio ha reso noto un incidente di sicurezza che ha esposto circa lo 0,3% delle connessioni attive, per lo più relative a GitHub, e ha richiesto ai clienti di aggiornare le proprie chiavi API. Includete il relativo rapporto nella vostra revisione della sicurezza.

Cosa dicono gli utenti reali di Composio

Una recensione di un utente recita:

Una piattaforma MCP gestita con una vasta libreria, che comprende oltre 1.000 app come Gmail e Slack. Il grande vantaggio è che non è necessario sviluppare e gestire autonomamente ogni integrazione; inoltre, Composio offre supporto per l’hosting autonomo in VPC e un SDK integrato per opzioni di implementazione flessibili.

Quanto costa un gateway MCP?

Il prezzo dipende dal fatto che si paghi per un servizio gestito o che si gestisca l'infrastruttura autonomamente.

I gateway open source non prevedono costi di licenza, ma è comunque necessario pagare per l’hosting, la manutenzione e la sicurezza. I gateway gestiti applicano costi per le chiamate agli strumenti, le ricerche, i piani di controllo o altre attività di utilizzo.

Quale gateway sia più conveniente dipende da ciò che già utilizzate. Composio e Amazon Bedrock AgentCore Gateway trasferiscono gran parte del carico di lavoro relativo all’infrastruttura al fornitore e applicano tariffe basate sull’utilizzo. Docker MCP Gateway e IBM ContextForge non prevedono costi di licenza, ma dovrete sostenere i costi di hosting e manutenzione. Kong rappresenta la scelta economicamente più vantaggiosa se il vostro team utilizza già Kong, poiché adottarlo solo per l’MCP comporta l’aggiunta di una nuova piattaforma e di costi di licenza.

Come scegliere un gateway MCP

Il prezzo restringe l’elenco, ma raramente determina la scelta al posto vostro.

Un punto di partenza migliore è il problema che vi ha spinto a cercare una soluzione. La maggior parte dei team si trova di fronte a una delle due situazioni seguenti: non riescono a vedere o a controllare chi richiama quale strumento, oppure i loro agenti caricano così tante definizioni di strumenti da iniziare a scegliere quelle sbagliate. Alcuni si trovano ad affrontare entrambe le situazioni.

Una volta individuato il problema più grave, saprete quali sono le funzionalità/funzioni che il gateway deve fare al meglio e di quali funzionalità/funzioni potete fare a meno.

Inizia da dove sono già in esecuzione i tuoi agenti

I cinque gateway descritti in questa guida coprono le stesse funzionalità di base, quindi il fattore decisivo è solitamente lo stack di cui già disponete.

Se i vostri agenti operano prevalentemente all’interno di applicazioni SaaS per conto di singoli utenti, Composio vi fa risparmiare il massimo lavoro, poiché gestisce per voi le connessioni OAuth di ciascun utente. Il compromesso è che tali credenziali risiedono nel cloud di Composio, aspetto che il vostro team di sicurezza vorrà valutare.

Per i team alle prese con flussi di lavoro disgiunti e distribuiti sui portatili degli sviluppatori, Docker MCP Gateway rappresenta il primo passaggio naturale. È ideale per i team che utilizzano già Docker Desktop, esegue ogni server nel proprio container e consente all’intero team di effettuare la condivisione di un unico profilo. Se in seguito avrete bisogno di una governance a livello di team, sarà necessario un colloquio separato con il reparto commerciale di Docker.

I team di piattaforma che preferiscono gestire autonomamente la propria infrastruttura tenderanno a scegliere IBM ContextForge. I suoi server virtuali offrono a ciascun team il proprio set di strumenti e consentono di trasformare i servizi REST e gRPC interni in strumenti MCP. Ci si assume inoltre la responsabilità delle operazioni di patch, scalabilità e reperibilità che derivano dall’hosting autonomo.

Kong AI Gateway sottopone il traffico MCP alle stesse politiche che il vostro team applica già alle proprie API. Se avete bisogno di SSO o di log di audit della piattaforma, prevedete un budget per la versione Enterprise, poiché entrambe le funzionalità sono disponibili solo in questa versione.

Per i team che sviluppano su AWS, Amazon Bedrock AgentCore Gateway garantisce la gestione completa e aggiunge la ricerca semantica degli strumenti direttamente sul gateway. Pianificate in anticipo il costo in base all’utilizzo, poiché le chiamate di ricerca, quelle agli strumenti e CloudWatch vengono fatturate separatamente.

Se gestisci una manciata di server stabili per un piccolo team, forse non hai ancora bisogno di un gateway. Una configurazione condivisa nel sistema di controllo delle versioni, abbinata a un gestore di secret, può soddisfare le tue esigenze fino a quando non avrai bisogno di autorizzazioni specifiche per ogni team o di log centralizzati.

Cosa dovresti verificare prima di effettuare il commit?

Una volta individuato il candidato favorito, testatelo sulla vostra configurazione prima di firmare qualsiasi accordo. Le pagine dedicate alle funzionalità/funzioni spesso tralasciano i dettagli che si riveleranno importanti in seguito, quindi esaminate alcune domande specifiche insieme ai vostri responsabili della sicurezza e della piattaforma:

Le risposte di solito chiariscono la questione. Se un gateway si limita a registrare le modifiche alle impostazioni e non è in grado di mostrare quali strumenti siano stati effettivamente utilizzati dai vostri agenti, non reggerà a un audit. E se connette i vostri server senza ridurre l’elenco degli strumenti, i vostri agenti continueranno a caricare tutte le definizioni degli strumenti, quindi l’utilizzo dei token rimarrà invariato.

Come si effettuano le migrazioni dei server MCP esistenti verso un gateway?

L'implementazione più sicura consiste nel trasferire prima un server a basso rischio e mantenere attivo il vecchio percorso fino a quando quello nuovo non si dimostrerà affidabile.

Iniziate con un inventario

Per ogni server, prendete nota di chi ne è il proprietario, quali strumenti offre, a quali dati può accedere e, approssimativamente, quanti token costano le definizioni dei suoi strumenti. Questo è anche il momento giusto per fare pulizia. La maggior parte dei cataloghi contiene strumenti che nessuno utilizza da mesi e rimuoverli prima della migrazione riduce il carico di governance.

Raggruppare i server in base al confine di fiducia

Inserite i server che leggono dati privati, quelli che gestiscono contenuti non attendibili e quelli in grado di inviare dati all’esterno in set di strumenti separati, in modo che un singolo agente non ne gestisca mai tutti e tre. È proprio questa combinazione che ha reso possibile la demo di iniezione di prompt MCP su GitHub realizzata da Invariant Labs. Inoltre, verificate che ogni server sia ancora sottoposto a manutenzione. Diversi server di riferimento MCP originali, tra cui GitHub e Slack, sono ora archiviati e non ricevono più aggiornamenti.

Una volta creati i gruppi, avviate un breve progetto pilota

Una volta superato il progetto pilota, trasferite i server con capacità di scrittura uno alla volta. Stabilite i criteri di rollback prima di ogni trasferimento, in modo da non dover decidere se ripristinare lo stato precedente nel bel mezzo di un incidente. Mantenete la configurazione diretta fino a quando il percorso del gateway non avrà funzionato senza intoppi per alcune settimane, quindi revocate le vecchie credenziali e le connessioni dei client.

Una regola vale indipendentemente dal gateway che scegliete. La specifica MCP vieta il passthrough dei token. Il gateway dovrebbe accettare solo i token emessi per esso e dovrebbe chiamare i server a valle utilizzando le proprie credenziali autorizzate separatamente, invece di inoltrare il token del client. Verificate che la configurazione del vostro gateway rispetti questa regola prima di trasferire il traffico di produzione.

Come funziona ClickUp con un gateway MCP?

ClickUp ha una connessione con MCP da entrambi i lati del gateway.

Le app di IA esterne a ClickUp, come Claude, Cursor e ChatGPT, raggiungono il tuo spazio di lavoro tramite il server MCP di ClickUp, che si trova dietro al tuo gateway come qualsiasi altro server. All’interno di ClickUp, i Super Agent e Brain² possono utilizzare strumenti provenienti da server MCP esterni a cui ti connetti, e il tuo gateway può essere uno di questi.

Posiziona il server MCP di ClickUp dietro il tuo gateway

Il server MCP di ClickUp è disponibile all'indirizzo https://mcp.clickup.com/mcp ed è incluso in tutti i piani, compreso il piano Free Forever. Accetta solo OAuth, quindi il tuo gateway non dovrà mai memorizzare chiavi API personali né sostituirle quando un utente lascia l'organizzazione. Se stai sviluppando un client personalizzato, questo dovrà supportare OAuth 2.1 con PKCE. ClickUp mantiene un elenco bianco di client approvati, quindi qualsiasi client non presente nell’elenco deve essere prima sottoposto a revisione.

Una volta connessi, i vostri agenti possono creare e indirizzare attività, generare aggiornamenti di stato basati su attività e documenti, registrare il tempo impiegato, cercare attività, documenti e commenti, nonché riassumere i thread di chat. In questo modo, un agente può consultare direttamente il contesto del progetto, senza doverlo incollare in ogni prompt.

I limiti di frequenza meritano un'analisi più approfondita dietro un gateway. Il limite copre l’intero spazio di lavoro e ogni client connesso consuma la stessa quota condivisa. Senza il componente aggiuntivo Everything IA, ClickUp limita le chiamate MCP ogni 24 ore consecutive, da 100 nel piano Free Forever fino a 5.000 nel piano Enterprise.

Con il componente aggiuntivo, le richieste MCP seguono invece i limiti al minuto dell’API pubblica. Questi vanno da 100 richieste al minuto per i piani Free Forever, Unlimited e Business fino a 10.000 per il piano Enterprise. ClickUp non mostra ancora l’utilizzo di MCP. Se più team accedono a ClickUp tramite un unico gateway, imposta dei limiti per ogni team a livello del gateway, in modo che un agente particolarmente attivo non possa esaurire la quota a disposizione di tutti gli altri.

Collega i Super Agent ai tuoi server MCP

Inversamente, puoi collegare server MCP esterni dall’App Center di ClickUp, sia per l’intero spazio di lavoro, sia solo per te stesso. Gli amministratori decidono chi può aggiungere ciascun tipo di connessione. Una volta collegato un server, puoi scegliere quali dei suoi strumenti assegnare a ciascun Super Agente: tutti o solo alcuni specifici. Si tratta dello stesso principio illustrato in precedenza in questa guida riguardo alla riduzione degli elenchi di strumenti, applicato agli agenti all’interno del tuo spazio di lavoro.

Se il server a cui ti connetti è il tuo gateway, verifica prima due dettagli. ClickUp si connette da indirizzi IP cloud variabili, quindi una lista di indirizzi IP consentiti non ne consentirà il passaggio. Il tuo gateway necessita inoltre di un URL pubblico protetto con OAuth o una chiave API. I log di audit dell’area di lavoro di ClickUp registrano chi si è connesso, ha aggiornato o disconnesso un server. Per avere un registro degli strumenti effettivamente richiamati da ciascun agente, avrai bisogno dei log del tuo gateway.

Monitora l'implementazione su ClickUp

Le fasi di inventario e di test descritte sopra comportano numerose piccole decisioni di cui è facile perdere traccia. Aggiungete ogni server come attività in un elenco, con campi personalizzati per titolare, accesso ai dati, gruppo di fiducia e costo del token. Quindi descrivete i criteri di rollback in un documento collegato a ciascuna attività di migrazione. Se un test fallisce o un server a monte viene archiviato, il titolare e la cronologia completa sono tutti in un unico posto.

Scegli il gateway più adatto al tuo problema

Ogni sezione di questa guida torna sempre alle stesse due attività.

Il primo aspetto è il controllo: un unico endpoint, un unico posto per le credenziali e un unico registro che indichi quale agente ha richiamato quale strumento. Tutti e cinque i gateway presenti in questa guida lo garantiscono in qualche modo, e la differenza principale sta nella quantità di infrastruttura che gestisci autonomamente. Il secondo compito è mantenere ridotto l’elenco degli strumenti di ciascun agente, e un gateway aiuta in questo senso solo quando si effettuano impostazioni di filtri o funzioni di ricerca.

Prima di firmare qualsiasi cosa, fai un inventario dei tuoi strumenti e verifica quanti token utilizzano le loro definizioni.

Elimina quelli che nessuno utilizza, raggruppa gli altri in base ai confini di fiducia e trasferisci per primo un server in sola lettura attraverso il gateway. Se ClickUp è uno di quei server, collegalo tramite il server MCP di ClickUp e verifica come un agente gestisce le tue attività, i tuoi documenti e la chat con il contesto completo del progetto.

Domande frequenti sui gateway MCP

Qual è il miglior gateway MCP?

La scelta del miglior gateway MCP dipende da dove sono già in esecuzione i vostri agenti. Docker MCP Gateway è adatto allo sviluppo locale. IBM ContextForge è indicato per i team che desiderano l’hosting autonomo. Kong AI Gateway è adatto ai team che già utilizzano Kong, mentre Amazon Bedrock AgentCore Gateway è indicato per gli agenti su AWS. Composio è adatto agli agenti che operano su numerose applicazioni SaaS. Per i settori regolamentati, cercate opzioni di hosting autonomo o di distribuzione privata, controlli di accesso per singolo strumento e registri delle chiamate dei singoli strumenti.

MCP è un gateway API?

No. Il Model Context Protocol è una specifica che definisce il modo in cui le app di intelligenza artificiale si connettono a strumenti e dati. Un gateway MCP è un software basato su tale specifica. Si colloca tra gli agenti e i server MCP e gestisce l’accesso, le credenziali e la registrazione degli eventi. Funziona come HTTP e un gateway API: HTTP stabilisce le regole per le richieste e il gateway decide quali richieste vengono autorizzate.

Hai bisogno di un gateway MCP?

Un gateway MCP è necessario se si desidera controllare chi può utilizzare quali strumenti su più server o mantenere un registro centralizzato delle attività svolte dagli agenti. Se un piccolo team gestisce una manciata di server stabili, una configurazione condivisa nel sistema di controllo delle versioni, abbinata a un gestore di segreti, soddisfa gran parte delle stesse esigenze. Un gateway inizia a dare i suoi frutti quando è necessario un accesso agli strumenti specifico per ogni team o un unico punto di gestione delle credenziali.

I server MCP sono sicuri dietro un gateway?

Un gateway semplifica la sicurezza dei server MCP. Di per sé, però, non li rende sicuri. Conserva le credenziali in un unico posto, pone un limite agli strumenti che ogni chiamante può utilizzare e registra le chiamate a livello centrale. L'iniezione di prompt può comunque avvenire tramite un server affidabile, come ha dimostrato Invariant Labs con il server MCP di GitHub. Gli strumenti che leggono dati privati, gestiscono contenuti non attendibili o inviano dati all'esterno dovrebbero essere tenuti in insiemi di strumenti separati. Assicuratevi che il gateway non inoltri mai il token di un client. E smettete di utilizzare server che non ricevono più aggiornamenti.

La ricerca degli strumenti sostituisce il controllo degli accessi?

No. È la ricerca degli strumenti a determinare quali strumenti un agente visualizza per un'attività. Il controllo degli accessi decide se a quell'agente è consentito richiamarli. Amazon Bedrock AgentCore Gateway, ad esempio, gestisce la ricerca semantica e l'autenticazione come funzionalità separate. Esegui la ricerca solo tra gli strumenti che un chiamante è autorizzato a utilizzare e verifica nuovamente le autorizzazioni quando lo strumento viene effettivamente eseguito. Se nascondere uno strumento dalla ricerca è la sua unica protezione, allora non è protetto.

Cosa dovrebbero registrare i log di audit di un gateway MCP?

I log di audit del gateway MCP dovrebbero registrare chi ha effettuato ogni chiamata, quali agenti e strumenti sono stati coinvolti, quale server l’ha gestita, se la chiamata è stata autorizzata o negata, quando è avvenuta e quale risposta è stata ricevuta. Il plugin AI MCP Proxy di Kong, ad esempio, registra ogni tentativo di accesso degli strumenti, sia autorizzato che negato. Prima dell’acquisto, verificate che i log coprano le singole chiamate degli strumenti e non solo le modifiche all’account e alla configurazione, quindi controllate per quanto tempo vengono conservati e se è possibile esportarli.