Les 10 meilleures passerelles et proxys MCP pour l’IA locale en 2026

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Top 10 MCP Gateways and Proxies for Local AI in 2026 - Zima Store Online

Un serveur MCP, c’est simple. Dix serveurs peuvent transformer chaque client d’IA en un véritable casse-tête de points de terminaison, de jetons, de schémas d’outils, de particularités de transport et d’autorisations dupliquées.

Une passerelle MCP place un point de contrôle unique au milieu. Vos agents se connectent une seule fois ; la passerelle gère les serveurs auxquels ils peuvent accéder, les outils qu’ils peuvent voir, l’injection des identifiants et le routage ou l’audit de chaque appel d’outil.

Qu’est-ce qu’une passerelle MCP et pourquoi l’IA locale en a-t-elle besoin ?

Le Model Context Protocol fournit aux clients d’IA une méthode standard pour découvrir et appeler des outils, des ressources et des prompts. Le protocole n’exige pas que chaque déploiement dispose d’une passerelle.

Si vous utilisez un client d’IA et un ou deux serveurs MCP, les connexions directes sont généralement plus simples :

Client d’IA
   |
   +---- MCP du système de fichiers
   |
   +---- MCP GitHub

Le problème apparaît lorsque les deux côtés se multiplient.

Claude Code ----\
Codex -----------\
OpenClaw ---------> Passerelle MCP
Cline ------------/      |
                     +----+-------+-------+
                     |            |       |
                  GitHub       Fichiers    Base de données
                    MCP         MCP       MCP

Au lieu de configurer séparément GitHub, le système de fichiers, les bases de données, les navigateurs, l’automatisation et les serveurs MCP internes dans chaque client, la passerelle devient la couche de contrôle partagée.

Cela est particulièrement utile pour les agents d’IA locaux. Le modèle peut s’exécuter sur votre propre matériel, mais dès qu’il peut appeler des outils privilégiés, le fait qu’il soit local ne suffit pas à résoudre les problèmes d’authentification, d’autorisation, d’isolation ou d’audit.

La question architecturale la plus importante devient alors :

Intention du modèle
     |
     v
Passerelle MCP
     |
Authentification / Politique / Filtre d’outils
Identifiants / Journaux / Routage
     |
     v
Outils privilégiés

Cette couche de passerelle est étroitement liée à la limite de confiance de l’exécution des outils : un modèle peut demander une action, mais une couche d’exécution distincte doit décider si cette action est réellement autorisée.

Comment nous avons classé les meilleures passerelles et proxys MCP

Il ne s’agit pas d’un classement selon le nombre d’étoiles GitHub, et les dix projets ne répondent pas tous exactement au même besoin.

Certaines sont des plateformes MCP complètes. D’autres sont des passerelles de sécurité, des agrégateurs, des passerelles pour agents ou de légers proxys de transport. Nous les avons classées selon les critères les plus importants pour l’IA locale et auto-hébergée :

Hébergement autonome : Pouvez-vous exécuter la passerelle sur une infrastructure que vous contrôlez ?
Agrégation MCP : Plusieurs serveurs MCP peuvent-ils apparaître derrière un seul point de terminaison ?
Filtrage des outils : Pouvez-vous limiter les outils qu’un agent voit réellement ?
Authentification et autorisation : Prend-il en charge l’identité des clients, OAuth, les jetons, le RBAC, les ACL ou les moteurs de politiques ?
Gestion des identifiants : les secrets peuvent-ils être centralisés au lieu d’être copiés dans chaque client IA ?
Prise en charge des transports : peut-il fonctionner avec stdio, SSE, HTTP diffusable ou d’autres modèles de déploiement ?
Isolation : les serveurs MCP ou l’exécution des outils peuvent-ils être séparés de l’hôte ?
Observabilité : les journaux, traces, métriques ou enregistrements d’audit sont-ils disponibles ?
Flexibilité du déploiement : convient-il à un ordinateur portable, un serveur domestique, un hôte Docker, une machine virtuelle ou un cluster Kubernetes ?
Orientation actuelle : le projet est-il toujours pertinent pour la pile MCP 2026, qui évolue rapidement ?

L’ordre numérique est éditorial et ne constitue pas un score issu d’une analyse comparative synthétique.

Top 10 des passerelles et proxys MCP pour l’IA locale en un coup d’œil

Classement	Passerelle / proxy	Idéal pour	Auto-hébergé	Agrégation	Sécurité / politiques	Différence clé
1	Docker MCP Gateway	IA locale basée sur Docker	Oui	Oui	Solide	Isolation des conteneurs + gestion du cycle de vie
2	ToolHive	Plateformes MCP autohébergées gérées	Oui	Oui	Solide	Passerelle + registre + environnement d’exécution + portail
3	agentgateway	Infrastructure d’agents unifiée	Oui	Oui	Solide	Passerelle MCP + LLM + A2A
4	MCPJungle	Point de terminaison MCP partagé simple	Oui	Oui	Modéré à fort	Migration locale vers une équipe en douceur
5	IBM ContextForge	Fédération des protocoles et des API	Oui	Oui	Solide	Fédération MCP + A2A + REST/gRPC
6	Microsoft MCP Gateway	Infrastructure MCP Kubernetes	Oui	Oui	Solide	Routage tenant compte des sessions + gestion du cycle de vie
7	OpenZiti MCP Gateway	Accès MCP distant selon le modèle Zero Trust	Oui	Oui	Solide	Aucun port public requis
8	MetaMCP	Réduction du contexte des schémas d’outils	Oui	Oui	Ciblé	Regroupe de nombreux outils MCP en quatre méta-outils
9	Kong AI Gateway	Piles de passerelles d’entreprise existantes	Oui, selon le déploiement	Oui	Solide	Gouvernance des API, de l’IA et de MCP
10	Supergateway	Conversion des transports MCP	Oui	Limité	Basique	stdio ↔ HTTP / SSE / WebSocket diffusables

1. Docker MCP Gateway — Meilleur choix global pour l’IA locale basée sur Docker

Docker MCP Gateway : une infrastructure unifiée et sécurisée pour l’IA agentique Docker MCP Gateway : une infrastructure open source et sécurisée pour l’IA agentique | Docker

Docker MCP Gateway est l’un des points de départ les plus naturels pour un environnement IA local, car les serveurs MCP sont en définitive des programmes qui ont besoin d’un emplacement sûr et prévisible pour s’exécuter.

La passerelle de Docker se situe entre les clients IA et les serveurs MCP, en centralisant la configuration, les identifiants, le routage, l’authentification et la gestion du cycle de vie des serveurs.

Pour les adeptes de l’auto-hébergement, l’isolation est la fonctionnalité essentielle. Au lieu d’installer directement sur l’hôte chaque serveur MCP et ses dépendances, Docker peut exécuter les serveurs dans des conteneurs restreints, avec des contrôles sur les privilèges, l’accès réseau, les ressources CPU et les secrets.

La passerelle peut également n’exposer que certains outils, au lieu de déverser dans le client tous les outils de chaque serveur. Les outils MCP de Docker incluent des contrôles des profils et des outils conçus pour réduire le bruit et l’utilisation superflue de jetons.

Un client peut se connecter à une seule passerelle :

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

tandis que Docker gère les processus des serveurs MCP en arrière-plan.

Cela convient particulièrement bien à un serveur domestique :

Claude Code / Codex / Cline
            |
     Docker MCP Gateway
            |
    +-------+-------+
    |       |       |
 Système de fichiers GitHub  n8n
 Conteneur  Serveur  Serveur

Idéal pour : les utilisateurs d’IA locale qui exécutent déjà Docker et souhaitent une seule passerelle, ainsi qu’une exécution isolée des serveurs MCP, la gestion des secrets, le filtrage des outils et des journaux centralisés.

Compromis : Docker propose désormais plusieurs expériences MCP associées, notamment MCP Toolkit, Gateway, Sandboxes et de nouvelles fonctionnalités de gouvernance. Certaines fonctionnalités de gouvernance IA de Docker sont soumises à des restrictions distinctes ; vérifiez donc l’ensemble de fonctionnalités réellement inclus dans votre déploiement au lieu de supposer que toutes les capacités MCP de Docker sont disponibles dans chaque édition.

2. ToolHive — Meilleure plateforme complète de gestion MCP auto-hébergée

GitHub - stacklok/toolhive : ToolHive est une plateforme de niveau entreprise pour exécuter et gérer des serveurs Model Context Protocol (MCP). · GitHub

ToolHive va bien au-delà d’un proxy léger.

Son architecture est divisée en plusieurs couches :

Passerelle : exposer des points de terminaison MCP contrôlés aux clients ;
Registre : gérer un catalogue de serveurs MCP et de compétences approuvés ;
Environnement d’exécution : déployer et exploiter des serveurs MCP ;
Portail : fournir une interface de gestion et de découverte.

La passerelle peut agréger plusieurs outils, s’intégrer à des fournisseurs d’identité OAuth/OIDC, appliquer des politiques d’accès, filtrer les outils et leurs descriptions, et centraliser les audits.

L’environnement d’exécution peut lancer localement des serveurs MCP via Docker ou Podman, tandis que l’opérateur Kubernetes étend la même approche à des clusters plus importants. La prise en charge d’OpenTelemetry et de Prometheus lui confère une gestion opérationnelle bien plus solide qu’un simple proxy inverse.

Cela rend ToolHive particulièrement intéressant pour les équipes. Un développeur n’a plus besoin de trouver un dépôt MCP quelconque, de l’installer manuellement, de coller les identifiants dans la configuration d’un client et d’espérer que tous les autres reproduisent correctement la même configuration.

À la place :

Registre de confiance
      |
    Environnement d’exécution
      |
 Serveurs MCP
      |
   Passerelle
      |
+-----+------+------+
Claude     Codex   VS Code

Idéal pour : les équipes qui souhaitent réunir la découverte MCP, le déploiement, la sécurité, les politiques, l’observabilité et l’accès via une passerelle au sein d’une seule plateforme auto-hébergée.

Compromis : ToolHive est nettement plus complet que nécessaire pour une configuration mono-utilisateur. Si vous voulez seulement cinq serveurs derrière un seul point de terminaison, MCPJungle est plus simple.

3. agentgateway — Idéal pour le trafic MCP, LLM et inter-agents sur une seule couche

Agentgateway v1.0.x – agentgateway | Connectivité des agents résolue

agentgateway est l’un des projets les plus importants à suivre, car il pose une question plus vaste :

Pourquoi créer une passerelle pour MCP, une autre pour les API LLM et une autre pour le trafic agent à agent ?

Son architecture combine trois catégories de trafic de plus en plus importantes :

Agent
  |
  +--> Passerelle LLM
  |
  +--> Passerelle MCP
  |
  +--> Passerelle A2A

Pour MCP, il prend en charge la fédération d’outils ainsi que les transports stdio, HTTP, SSE et HTTP diffusé en continu. Les options d’authentification comprennent OAuth, JWT et les clés API, tandis que le RBAC précis, la limitation du débit, TLS et OpenTelemetry fournissent la couche de gouvernance.

Il possède également une dimension directement liée à l’IA locale : agentgateway peut acheminer l’inférence vers des modèles auto-hébergés et une infrastructure d’inférence Kubernetes, au lieu de supposer que chaque appel de modèle est destiné à un fournisseur cloud.

Le projet s’adapte également activement aux nouvelles générations du protocole MCP, notamment aux changements beaucoup plus importants du protocole en 2026 et au problème de compatibilité créé lorsque les clients et les serveurs sont mis à jour à des moments différents.

Idéal pour : une infrastructure IA auto-hébergée avancée lorsque les agents ont besoin d’une seule couche de connectivité pour les modèles, les outils et les autres agents.

Compromis : si votre seul problème consiste à regrouper quelques serveurs MCP locaux, agentgateway peut représenter une architecture plus complexe que nécessaire.

4. MCPJungle — Meilleure passerelle auto-hébergée simple pour plusieurs serveurs MCP

🚀 Présentation de MCPJungle Aujourd’hui, j’ai publié en open source un projet sur lequel je travaillais depuis un certain temps. SCÉNARIO Vous déployez des agents IA dans votre entreprise. Différentes équipes de votre organisation exposent leurs services internes… |

MCPJungle est probablement le projet le plus facile à expliquer de cette liste :

enregistrez vos serveurs MCP une seule fois, puis laissez vos clients IA se connecter à un seul point de terminaison.

GitHub MCP ------\
Postgres MCP -----\
Filesystem MCP ----> MCPJungle ----> /mcp
Browser MCP -------/                    |
n8n MCP ----------/          +----------+---------+
                              Claude   Cursor   Codex

Le projet prend en charge les serveurs MCP distants et stdio, tout en offrant une découverte unifiée des outils, des invites et des ressources.

Les groupes d’outils permettent à un déploiement d’exposer uniquement un sous-ensemble sélectionné des outils disponibles pour un cas d’utilisation donné, plutôt que de fournir à chaque client l’intégralité du catalogue d’outils.

MCPJungle offre également une évolution utile, de l’infrastructure personnelle à l’infrastructure partagée. Vous pouvez commencer avec Docker Compose et un point de terminaison local, puis passer aux identités des clients, aux jetons d’accès, aux listes blanches explicites de serveurs, à PostgreSQL et à OpenTelemetry à mesure que le déploiement gagne en importance.

Cela le rend particulièrement adapté à un home lab. Vous n'avez pas besoin de commencer par installer Kubernetes ou par créer une architecture d'identité d'entreprise.

Idéal pour : les développeurs et les petites équipes qui souhaitent un point de terminaison MCP unique et bien structuré sans adopter une plateforme d'infrastructure d'IA beaucoup plus vaste.

Compromis : ses fonctionnalités de gouvernance avancées sont liées à ses modes orientés production ou entreprise, et son modèle de sécurité n'est pas aussi étendu que celui de ToolHive, d'agentgateway ou d'une passerelle d'API mature.

5. IBM ContextForge — Idéal pour fédérer MCP avec des API et des agents existants

GitHub - IBM/mcp-context-forge : MCP ContextForge est une passerelle d'IA, un registre et un proxy qui se place devant n'importe quelle API MCP, A2A ou REST/gRPC, en exposant un point de terminaison unifié avec découverte, garde-fous et gestion centralisés. Optimise les agents

IBM ContextForge devient particulièrement utile lorsque votre infrastructure n'est pas composée exclusivement de serveurs MCP.

Les environnements réels combinent généralement plusieurs éléments :

Serveur MCP
API REST
Service gRPC
Agent A2A
API interne existante
       |
       v
  ContextForge
       |
       v
   Clients d’IA

ContextForge fait office de registre, de proxy et de couche de fédération pour les services MCP, A2A, REST et gRPC.

Son architecture actuelle comprend des fonctions de passerelle d'outils, la traduction d'API, le routage des agents, l'extensibilité par plugins, la limitation du débit, l'authentification, les nouvelles tentatives et l'observabilité fondée sur OpenTelemetry.

Le projet a atteint un jalon de disponibilité générale 1.0 en 2026, avec un renforcement supplémentaire de la sécurité, des travaux sur les protocoles, des améliorations du catalogue et des changements de déploiement axés sur la production.

Il peut être exécuté via un paquet Python ou Docker, puis évoluer vers des déploiements Kubernetes et multiclusters.

Idéal pour : les organisations ou les home labs avancés qui doivent exposer des systèmes REST/gRPC existants à des agents sans réécrire chaque service sous forme de serveur MCP dédié.

Compromis : ContextForge est plus large qu'une passerelle uniquement dédiée à MCP. Cette flexibilité ajoute une complexité opérationnelle par rapport à MCPJungle ou Supergateway.

6. Passerelle MCP de Microsoft — Idéale pour les serveurs MCP avec état sur Kubernetes

GitHub - microsoft/mcp-gateway : MCP Gateway est un proxy inverse et une couche de gestion pour les serveurs MCP, permettant un routage évolutif, avec gestion des sessions et conservation de l'état, ainsi que la gestion du cycle de vie des serveurs MCP dans les environnements Kubernetes. · GitHub

Passerelle MCP de Microsoft est particulièrement pertinente lorsque les serveurs MCP eux-mêmes doivent devenir une infrastructure gérée.

Le projet combine une passerelle de données et un plan de contrôle.

La couche de données achemine le trafic MCP, tandis que la couche de gestion peut représenter les serveurs comme des ressources gérées et gérer les opérations de déploiement, de mise à jour et de suppression.

Sa fonctionnalité phare est le routage avec état et gestion des sessions.

Certains serveurs MCP ne sont pas de simples endpoints HTTP sans état interchangeables. Une session client peut devoir continuer à communiquer avec la même instance backend. Microsoft MCP Gateway peut acheminer les requêtes partageant un identifiant de session vers la même instance serveur, tout en permettant l’exécution de plusieurs instances derrière la passerelle.

Session client A ----> Passerelle ----> Pod MCP 1
Session client A ----> Passerelle ----> Pod MCP 1

Session client B ----> Passerelle ----> Pod MCP 2

Le projet comprend également l’autorisation, la télémétrie, l’intégration du contrôle d’accès et la gestion du cycle de vie, conçues pour les environnements Kubernetes.

Idéal pour : les équipes qui utilisent déjà Kubernetes et exécutent des flottes de serveurs MCP avec état ou gérées dynamiquement.

Compromis : ce n’est pas le choix le plus évident pour un serveur domestique unique. Docker MCP Gateway ou MCPJungle seront généralement beaucoup plus faciles à exploiter.

7. OpenZiti MCP Gateway — Idéal pour l’accès distant zero trust aux outils MCP privés

Nous venons de publier une passerelle LLM et une passerelle MCP open source basées sur OpenZiti et zrok : r/OpenSourceeAI

OpenZiti MCP Gateway résout l’un des problèmes les plus pratiques de l’IA locale :

Que se passe-t-il lorsque l’agent et le serveur MCP ne sont pas sur le même réseau local ?

Une configuration privée courante se présente ainsi :

Ordinateur portable / client IA
        |
      Internet
        |
 Serveur domestique / NAS
        |
 Outils MCP privés

La réponse conventionnelle consiste souvent à exposer un endpoint HTTPS, à configurer des règles de pare-feu, à mettre en place un VPN ou à placer un autre proxy inverse devant le service.

OpenZiti adopte plutôt une approche de réseau superposé zero trust. Sa passerelle MCP peut exposer des outils internes sous forme de services invisibles, qui n’écoutent pas sur des adresses IP publiques et ne nécessitent pas de redirection de ports traditionnelle.

Les identités cryptographiques, mTLS, l’isolation par client et les contrôles au niveau des outils constituent la couche d’accès. Le projet peut également agréger plusieurs backends et transformer des serveurs locaux en stdio en services MCP accessibles à distance.

Cela est particulièrement pertinent pour un espace de travail privé pour agent IA, où l’environnement d’exécution de l’agent, les fichiers et les services résident sur un serveur domestique toujours allumé, mais doivent être accessibles en toute sécurité depuis un autre appareil.

Idéal pour : les utilisateurs qui souhaitent accéder à distance à des outils MCP privés sans exposer directement ces outils à l’Internet public.

Compromis : vous adoptez le modèle de réseau OpenZiti/zrok dans le cadre de la solution. Si un réseau local privé classique ou un VPN existant résout déjà le problème de connectivité, cela peut être inutile.

8. MetaMCP — Idéal pour réduire la surcharge de contexte liée aux schémas d’outils

Documentation de MetaMCP - MetaMCP

MetaMCP s’attaque à un autre problème de mise à l’échelle de MCP.

Supposons qu’un agent se connecte directement à :

MCP Playwright      52 outils
MCP de base de données        20 outils
MCP GitHub          30 outils
MCP du système de fichiers      15 outils
MCP de supervision      18 outils

Le modèle peut devoir recevoir une grande collection de schémas d’outils JSON avant même de commencer à effectuer un travail utile.

Cela consomme du contexte et peut rendre la sélection des outils plus confuse.

MetaMCP place ces serveurs enfants derrière une petite interface stable. Sa conception actuelle expose quatre méta-outils principaux pour la découverte, le provisionnement, l’appel et l’exécution en plusieurs étapes, au lieu d’exposer directement les schémas de chaque outil en aval.

L’architecture devient :

               +-- Playwright
               +-- GitHub
LLM local --> MetaMCP -- Base de données
               +-- Fichiers
               +-- Plus de serveurs

Le modèle voit : 4 méta-outils

Cela est particulièrement intéressant pour les modèles locaux. Les modèles cloud de pointe disposent de contextes de plus en plus vastes et d’une forte capacité de sélection des outils, mais les modèles auto-hébergés plus petits peuvent être davantage sensibles à la taille des invites et aux catalogues d’outils volumineux.

La documentation de MetaMCP montre que la surcharge liée aux schémas peut rester à peu près constante à mesure que des serveurs MCP enfants supplémentaires sont ajoutés, au lieu d’augmenter linéairement avec chaque outil en aval.

Idéal pour : les déploiements d’IA locaux utilisant de nombreux serveurs MCP, lorsque les schémas d’outils consomment trop de contexte ou perturbent la sélection des outils par le modèle.

Compromis : cette abstraction modifie la façon dont le modèle interagit avec les outils. Vous gagnez en efficacité du contexte, mais ajoutez une couche de découverte et de routage entre le modèle et les véritables outils MCP.

9. Kong AI Gateway — Idéal si vous utilisez déjà une passerelle d’API

Kong Gateway | Documentation Kong

Kong AI Gateway est une proposition différente de celle des projets axés d’abord sur le laboratoire domestique présentés ci-dessus.

Si votre organisation utilise déjà Kong pour ses API, son authentification, son routage ou la gouvernance de ses services, ajouter MCP au même plan de contrôle peut être plus intéressant que de déployer une plateforme MCP complètement distincte.

L’architecture actuelle d’AI Gateway de Kong reconnaît MCP et A2A en plus du trafic de modèles conventionnel. Sa configuration de serveur MCP prend en charge l’agrégation et le contrôle d’accès au niveau des outils, tandis que les fonctionnalités existantes de la passerelle peuvent fournir l’authentification, le routage, les métriques et une gouvernance plus large.

Un schéma utile ressemble à ceci :

Clients d’IA
     |
Kong AI Gateway
     |
+----+-------+--------+
|            |        |
MCP A       MCP B    API REST
|            |
Outils       Outils

Cela devient particulièrement intéressant lorsque la même plateforme régit 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

Activité · supercorp-ai/supergateway · GitHub

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

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

La situation devient compliquée lorsque le serveur doit s’exécuter 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 un 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 jeton bearer, les points de terminaison de santé, 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’audits.

Quelle passerelle MCP devriez-vous choisir ?

Si vous avez besoin de…	Commencer par	Pourquoi
Serveurs MCP locaux basés sur Docker	Docker MCP Gateway	Isolation des conteneurs, cycle de vie, secrets, profils et filtrage des outils
Une plateforme complète de gestion MCP	ToolHive	Passerelle, registre, environnement d’exécution, politiques et portail dans une seule pile
Routage MCP + modèle + agent à agent	agentgateway	Unifie trois couches de trafic agentique
Un seul point de terminaison MCP auto-hébergé	MCPJungle	Agrégation simple avec une mise à niveau fluide pour l’équipe
REST, gRPC, MCP et agents réunis	IBM ContextForge	Fédère les API existantes au lieu d’imposer une infrastructure exclusivement MCP
Parcs MCP Kubernetes	Microsoft MCP Gateway	Routage tenant compte des sessions et gestion du cycle de vie des serveurs
Outils privés distants sans ports ouverts	OpenZiti MCP Gateway	Connectivité en réseau superposé zero trust
Moins de schémas d’outils dans le contexte du modèle	MetaMCP	Réduit les grands catalogues d’outils à des méta-outils
Gouvernance MCP au sein d’une passerelle d’API existante	Kong AI Gateway	Utilise une infrastructure établie d’authentification, de contrôle d’accès, de routage et de passerelle
Conversion de transport stdio / HTTP	Supergateway	Pont de transport simple sans plateforme complète

Docker MCP Gateway, ToolHive ou MCPJungle

Ce sont trois des choix les plus pertinents pour un environnement auto-hébergé, mais ils ciblent des niveaux de complexité différents.

Domaine	Docker MCP Gateway	ToolHive	MCPJungle
Idée principale	Exécuter et gouverner des serveurs MCP conteneurisés	Exploiter une plateforme MCP	Placer de nombreux serveurs MCP derrière un seul point de terminaison
Adapté aux laboratoires domestiques	Excellente	Bonne	Excellente
Isolation des serveurs	Intégration poussée avec Docker	Docker / Podman / Kubernetes	Dépend du déploiement
Registre	Écosystème Docker MCP	Registre de premier ordre	Catalogue de serveurs enregistrés
Identité / politiques	Contrôles solides	Solides, adaptées aux équipes	Contrôle d’accès des clients
Observabilité	Journalisation et traçage	OpenTelemetry / Prometheus	Options OpenTelemetry
Choix le plus adapté	Utilisateurs de Docker	Équipes / ingénierie de plateforme	Serveur personnel à petite équipe

Choisissez Docker MCP Gateway lorsque Docker constitue déjà la base de votre pile d’IA auto-hébergée et que l’isolation des conteneurs est importante.

Choisissez ToolHive lorsque plusieurs développeurs ont besoin d’un catalogue MCP approuvé, d’un déploiement centralisé, d’une intégration de l’identité, de politiques et de fonctions de supervision.

Choisissez MCPJungle lorsque votre principal problème est simplement d’éviter que Claude, Codex, Cursor et d’autres clients contiennent des configurations MCP en double.

Passerelle MCP ou proxy, agrégateur ou pont de transport

La terminologie entourant l’infrastructure MCP reste incohérente, les noms des produits peuvent donc être trompeurs.

Couche	Fonction principale	Exemple
Passerelle	Point d’entrée central avec routage, identité, sécurité et gouvernance	Docker MCP Gateway, ToolHive
Proxy	Acheminer le trafic MCP tout en ajoutant certains contrôles	Kong, proxys de sécurité légers
Agrégateur	Combiner plusieurs serveurs MCP derrière un seul point de terminaison	MCPJungle
Méta-routeur	Masquer les grands catalogues d’outils en aval derrière une interface plus restreinte	MetaMCP
Pont de transport	Convertir stdio, SSE, HTTP diffusable en continu ou d’autres transports	Supergateway
Passerelle d’agents	Gouverner le trafic MCP ainsi que celui des modèles et des agents entre eux	agentgateway, ContextForge

Un projet peut remplir plusieurs de ces fonctions à la fois. La question utile n’est pas le nom que le dépôt se donne, mais le problème de contrôle qu’il résout réellement.

Comment créer une architecture de passerelle MCP locale

Une configuration locale pratique ne doit pas commencer par une plateforme gigantesque.

Commencez par quatre couches :

Clients d’IA
Claude Code / Codex / OpenClaw
             |
             v
        Passerelle MCP
             |
    +--------+--------+
    |        |        |
 Fichiers     GitHub   Automatisation
 MCP       MCP       MCP
    |
Stockage local / NAS

Gardez la passerelle à proximité des outils

Si la plupart des serveurs MCP accèdent à des fichiers locaux, Docker, Home Assistant, des bases de données, des dépôts Git ou des API privées, la passerelle appartient généralement au même réseau de serveurs de confiance plutôt que sur chaque ordinateur portable de développeur.

Cela reprend l’architecture d’un espace de travail privé pour agent IA : le client peut se déplacer, mais le stockage privé, l’environnement d’exécution, les journaux et les services d’automatisation restent sur un hôte toujours actif.

Séparer l’hébergement du modèle de celui de MCP

La passerelle MCP n’a pas besoin de fonctionner sur la même machine que le LLM.

Hôte de l’agent             Serveur GPU
    |                       |
Passerelle MCP              Ollama
    |                     vLLM
Outils locaux
    |
Fichiers / bases de données / API

Cela compte, car le trafic MCP est généralement léger comparé à l’inférence. Un serveur toujours actif aux ressources modestes peut héberger la passerelle et les services d’outils, tandis qu’un poste de travail ou un nœud GPU prend en charge le modèle.

Utiliser des ensembles d’outils sélectionnés plutôt que de tout exposer

Un agent de programmation n’a probablement pas besoin de contrôler la maison connectée. Un agent de recherche n’a probablement pas besoin d’administrer Docker. Un assistant dédié aux connaissances personnelles ne devrait pas hériter automatiquement d’un accès à une base de données de production.

Créer des profils ou des groupes d’outils distincts :

programmation
  - GitHub
  - système de fichiers — développement
  - documentation

recherche
  - navigateur
  - articles scientifiques
  - connaissances locales

opérations domestiques
  - supervision
  - home assistant
  - docker en lecture seule

Cela s’intègre naturellement aux flux de travail IA locaux : la couche MCP détermine les capacités disponibles, tandis que les compétences et les instructions de l’agent déterminent comment et quand ces capacités doivent être utilisées.

Pourquoi le filtrage des outils est important pour les modèles locaux

La sécurité n’est qu’une des raisons de limiter les outils.

Le contexte en est une autre.

Chaque outil peut contribuer un nom, une description, des arguments, un schéma JSON et d’autres métadonnées à l’ensemble des outils disponibles pour le modèle.

Avec une poignée d’outils, c’est trivial.

Avec des centaines d’outils, cela peut occuper une partie du budget du prompt :

5 serveurs MCP
x 20 outils
= 100 schémas d’outils

20 serveurs MCP
x 20 outils
= 400 schémas d’outils

Cela peut réduire le contexte disponible pour la conversation, le code du dépôt, les documents récupérés, le raisonnement et la sortie.

Cela peut également compliquer la sélection des outils. Si un agent voit plusieurs outils de recherche, d’interrogation, de récupération, de lecture ou d’exécution aux noms similaires, choisir le bon devient une tâche de raisonnement supplémentaire.

Il existe trois solutions principales :

Filtrage des outils : n’exposer que les outils pertinents pour un agent donné.
Groupes ou profils d’outils : fournir différents catalogues à différents clients.
Méta-routage : exposer une petite interface de découverte et d’appel, puis résoudre les outils en aval à la demande.

Docker MCP Gateway et ToolHive mettent l’accent sur le filtrage et l’exposition contrôlée. MCPJungle propose des groupes d’outils. MetaMCP va plus loin en transformant de nombreux outils enfants en une petite surface stable de méta-outils.

C’est encore plus important lorsque MCP se connecte à une base de connaissances locale, car les schémas d’outils sont désormais en concurrence avec les documents et le contexte récupéré dans la même fenêtre de contexte du modèle.

Liste de contrôle de sécurité d’une passerelle MCP pour l’IA locale

Une passerelle n’est pas utile simplement parce que tout le trafic passe par elle. Sa valeur vient de ce qu’elle applique réellement.

Authentifiez le client

La passerelle doit savoir si l’appelant est Codex sur le poste d’un développeur, un agent actif en permanence, un processus CI ou un autre service.

Ne considérez pas « à l’intérieur de mon réseau local » comme une identité.

Autorisez séparément les serveurs et les outils

L’accès au serveur MCP GitHub ne signifie pas nécessairement l’accès à tous les outils GitHub.

Une politique utile peut autoriser :

read_issue
list_pull_requests
search_code

tout en refusant :

merge_pull_request
delete_repository
change_branch_protection

Gardez les identifiants hors des fichiers de configuration des agents

L’un des principaux avantages d’une passerelle est de retirer les clés d’API et les identifiants de service de chaque client d’IA individuel.

Le flux idéal est le suivant :

Agent
  |
Demande d’outil
  |
Passerelle
  |
Injectez des identifiants à portée limitée
  |
Serveur MCP

Le modèle n’a pas besoin de voir le jeton sous-jacent.

Isolez les serveurs MCP non fiables

Un serveur MCP est un logiciel exécutable.

Si un serveur est installé depuis un dépôt tiers, traitez-le comme toute autre dépendance logicielle. Examinez le paquet, verrouillez les versions lorsque c’est possible, limitez l’accès au réseau et au système de fichiers, et utilisez des conteneurs ou une autre forme d’isolation lorsque cela est approprié.

Consignez les appels d’outils, pas seulement les erreurs HTTP

Lorsqu’un agent modifie un fichier ou met à jour un système externe, vous devez disposer de suffisamment d’informations pour reconstituer :

quel client a effectué la demande ;
quel outil a été sélectionné ;
quels arguments ont été approuvés ;
quel résultat a été renvoyé ;
si l’effet secondaire s’est réellement produit.

C’est pourquoi l’observabilité est un facteur de classement de premier ordre, et non un simple complément réservé aux entreprises.

Supprimez les chemins de contournement

Une passerelle MCP soigneusement configurée ne définit pas la véritable limite de sécurité si le même agent dispose également des accès suivants :

un shell hôte sans restriction ;
un socket Docker accessible en écriture ;
des identifiants administrateur ;
un accès root direct à la base de données ;
une autre connexion MCP sans restriction.

La limite de confiance de l’exécution des outils n’a de sens que lorsque les actions privilégiées passent réellement par elle.

Avez-vous réellement besoin d’une passerelle MCP ?

Probablement pas si votre configuration ressemble à ceci :

Un client d’IA
   |
Deux serveurs MCP

Ajouter une passerelle créerait un service supplémentaire à installer, mettre à jour, sécuriser, surveiller et déboguer.

Une passerelle commence à devenir pertinente lorsque plusieurs de ces conditions sont réunies :

vous utilisez plusieurs clients d’IA ;
vous disposez de plusieurs serveurs MCP ;
les mêmes serveurs MCP sont configurés à plusieurs reprises ;
les identifiants sont dupliqués sur les machines clientes ;
différents agents doivent voir des outils différents ;
des appareils distants doivent accéder à des services MCP privés ;
vous avez besoin de journaux d’audit ;
certains serveurs MCP doivent fonctionner de manière isolée ;
les schémas des outils consomment trop de contexte du modèle ;
vous devez relier les transports stdio et réseau ;
le déploiement devient une infrastructure partagée.

Une règle utile est la suivante :

1 client + 2 serveurs
        ↓
Le MCP direct convient

Plusieurs clients + plusieurs serveurs
        ↓
La passerelle commence à être utile

Équipes + identifiants + politiques + audit
        ↓
La passerelle devient une infrastructure

Où se situe Soth MCP Proxy ?

Soth MCP Proxy mérite également d’être surveillé, en particulier si votre priorité est de placer une couche de politique de sécurité devant un déploiement MCP existant.

Sa conception actuelle comprend l’application de politiques OPA/Rego, la journalisation d’audit persistante, le contrôle des sessions, les métriques Prometheus, des points de terminaison d’état et TLS.

Il s’agit d’une architecture utile :

Agent
  |
Soth Policy Proxy
  |
Serveur MCP existant

Nous ne l’avons pas incluse dans le Top 10 principal, car il s’agit encore d’un projet bien plus précoce que la plupart des passerelles ci-dessus et que plusieurs fonctionnalités de transport et d’administration figurent encore sur sa feuille de route.

Pour l’instant, considérez-la comme un proxy de sécurité léger et prometteur plutôt que comme une plateforme mature de gestion du MCP.

Le changement de 2026 : la passerelle MCP devient une infrastructure pour les agents

La première question concernant le MCP était :

Comment connecter mon assistant IA à cet outil ?

La question la plus récente est :

Comment gouverner chaque outil utilisé par chaque agent ?

Cela modifie l’architecture.

2025

Agent
  |
Serveur MCP
  |
Outil


2026

Agents
  |
Passerelle d’agents / MCP
  |
Identité
Politique
Routage
Identifiants
Découverte d’outils
Observabilité
Traduction de protocoles
  |
De nombreux serveurs MCP
  |
API / Fichiers / Bases de données / Services

C’est pourquoi des projets tels qu’agentgateway et ContextForge ne s’arrêtent plus au MCP. Ils s’étendent également vers le routage des modèles et les protocoles agent-à-agent.

La passerelle devient la couche de connectivité et de gouvernance entre le raisonnement probabiliste de l’IA et les systèmes capables d’exécuter concrètement des tâches.

Pour les utilisateurs qui expérimentent déjà avec des outils d’IA en ligne de commande et des agents de codage, cela deviendra probablement de plus en plus important. Un agent de codage doté de cinq outils est une application. Dix agents partageant cinquante outils constituent une infrastructure.

Verdict final

Choisissez Docker MCP Gateway si votre architecture d’IA locale s’exécute déjà sur Docker et que vous voulez une combinaison pratique de gestion du cycle de vie des serveurs MCP, d’isolation des conteneurs, de gestion des identifiants, de filtrage et d’accès centralisé.

Choisissez ToolHive si MCP devient une infrastructure d’équipe partagée et que vous avez besoin d’un registre, d’un environnement d’exécution, d’une passerelle, d’une couche de politiques et d’observabilité plutôt que d’un simple proxy.

Choisissez agentgateway si vous prévoyez que le trafic MCP, le trafic des modèles et les communications d’agent à agent convergent derrière une passerelle native pour l’IA.

Choisissez MCPJungle si vous voulez passer le plus simplement possible de configurations client MCP dispersées à un point d’accès auto-hébergé unique.

Choisissez IBM ContextForge si votre environnement comprend des API REST ou gRPC existantes qui devraient devenir utilisables avec MCP et les services d’agents.

Choisissez Microsoft MCP Gateway si votre parc de serveurs MCP appartient déjà à Kubernetes et nécessite un routage tenant compte des sessions ainsi qu’une gestion du cycle de vie.

Choisissez OpenZiti MCP Gateway si les agents ont besoin d’un accès à distance à des outils MCP privés sans exposer ces services sur des ports publics.

Choisissez MetaMCP si votre problème principal n’est pas la connectivité, mais le nombre de schémas d’outils qui consomment du contexte et déconcertent les modèles locaux.

Choisissez Kong AI Gateway si MCP doit devenir une autre catégorie de trafic gouvernée au sein d’une plateforme API et IA existante basée sur Kong.

Choisissez Supergateway si vous avez simplement besoin d’un pont fiable entre les transports MCP stdio et réseau.

La meilleure passerelle MCP n’est donc pas nécessairement celle qui possède la liste de fonctionnalités la plus longue. C’est la couche de contrôle la plus légère qui répond au problème que votre architecture d’agents a effectivement atteint.

FAQ

Qu’est-ce qu’une passerelle MCP ?

Une passerelle MCP se place entre les clients d’IA et les serveurs MCP. Elle peut regrouper plusieurs serveurs derrière un point d’accès unique et ajouter des fonctionnalités telles que le routage, l’authentification, le contrôle d’accès, la gestion des identifiants, le filtrage des outils, la journalisation, l’observabilité, l’isolation ou la conversion de protocole de transport.

Ai-je besoin d’une passerelle MCP pour l’IA locale ?

Pas toujours. Un seul client d’IA connecté à un ou deux serveurs MCP fonctionne généralement bien sans passerelle. Les passerelles deviennent plus utiles lorsque plusieurs clients partagent plusieurs serveurs MCP, des identifiants, des politiques, un accès à distance ou des exigences d’audit.

Quelle est la meilleure passerelle MCP pour un serveur domestique ?

Docker MCP Gateway et MCPJungle sont deux excellents points de départ. Docker MCP Gateway convient aux utilisateurs qui exécutent déjà Docker et offre l’isolation des conteneurs ainsi que la gestion de leur cycle de vie. MCPJungle est intéressant lorsque l’objectif principal est de regrouper plusieurs serveurs MCP derrière un point d’accès unique et épuré.

Quelle est la différence entre une passerelle MCP et un proxy MCP ?

Un proxy se contente principalement de transférer le trafic et peut ajouter certains contrôles. Une passerelle agit généralement comme un plan de contrôle plus large, avec du routage, la gestion des identités, des politiques, l’agrégation, la gestion des identifiants, la découverte, l’observabilité ou la gestion du cycle de vie. En pratique, les projets utilisent souvent ces termes indifféremment.

Une même passerelle MCP peut-elle connecter plusieurs clients d’IA ?

Oui. L’un des principaux avantages d’une passerelle est de permettre à Claude, Codex, Cursor, Cline, OpenClaw ou à des agents personnalisés de réutiliser une infrastructure MCP partagée au lieu de configurer chaque serveur MCP séparément dans chaque client.

Une passerelle MCP peut-elle réduire la consommation de jetons ?

Oui, si elle filtre ou abstrait les schémas d’outils avant qu’ils n’atteignent le modèle. Docker MCP Gateway et ToolHive peuvent exposer des ensembles d’outils sélectionnés, MCPJungle prend en charge les groupes d’outils, et MetaMCP réduit un vaste catalogue d’outils en aval à un petit ensemble de méta-outils.

Quelle est la meilleure passerelle MCP pour les modèles locaux ?

Pour l’IA locale à usage général, Docker MCP Gateway et MCPJungle sont des options pratiques. MetaMCP est particulièrement intéressant lorsque les petits modèles locaux ont du mal avec les vastes catalogues d’outils, tandis qu’agentgateway est pertinent lorsque le routage de l’inférence auto-hébergée et la gouvernance MCP doivent résider dans la même couche d’infrastructure.

Puis-je exposer un serveur MCP stdio via HTTP ?

Oui. Supergateway peut convertir les serveurs MCP stdio en transports HTTP diffusables, SSE ou WebSocket. D’autres passerelles peuvent également relayer ou faire office de proxy pour des serveurs locaux stdio afin de les rendre accessibles sur le réseau via des points de terminaison MCP.

Comment accéder de manière sécurisée à un serveur MCP situé en dehors de mon réseau domestique ?

Utilisez un réseau privé authentifié ou une passerelle conçue pour l’accès distant, plutôt que de simplement rediriger un port public. OpenZiti MCP Gateway est spécialement conçue pour rendre des services MCP privés accessibles à distance via un réseau superposé zero trust, sans exposer directement le serveur sur une adresse IP publique.

Une passerelle MCP constitue-t-elle une frontière de sécurité ?

Cela peut en faire partie, mais uniquement si l’accès aux outils privilégiés passe réellement par elle. Si le même agent d’IA dispose également d’un accès illimité au shell, d’identifiants administrateur, d’un socket Docker accessible en écriture ou de connexions directes qui contournent la passerelle, celle-ci ne définit pas la véritable frontière d’exécution.

Les serveurs MCP doivent-ils s’exécuter dans Docker ?

Les conteneurs sont utiles pour isoler les dépendances des serveurs MCP, l’accès au système de fichiers, l’accès réseau et l’utilisation des ressources. Docker MCP Gateway et ToolHive placent tous deux l’exécution conteneurisée de MCP au cœur de leur approche, mais les conteneurs ne remplacent ni l’authentification, ni l’autorisation, ni le filtrage des outils, ni l’audit.

Quelle est la différence entre MetaMCP et une passerelle MCP classique ?

Une passerelle conventionnelle agrège et administre généralement les serveurs MCP tout en exposant leurs outils. MetaMCP va plus loin en masquant de vastes catalogues d’outils en aval derrière un très petit ensemble de méta-outils, ce qui réduit la surcharge des schémas dans le contexte du modèle.