MCP Gateway avant adoption : agréger plusieurs serveurs MCP et API REST en une surface d'outils fixe (licence non commerciale)

Si vous branchez plusieurs serveurs MCP et API REST sur un même client IA, vous constatez vite que ce sont les définitions d'outils elles-mêmes qui saturent le contexte. L'approche de MCP Gateway consiste à placer un unique binaire Rust entre le client et l'ensemble de ses outils : les différents backends se raccrochent derrière lui, et l'agent voit une méta-surface compacte de 14 à 16 outils au lieu de la définition complète de chaque backend. Plus les définitions d'outils occupent le contexte, moins il reste de budget pour la tâche réelle ; les condenser en une petite surface fixe, c'est précisément le problème qu'il résout. Avant de vous lancer, vérifiez une prémisse : il est fourni par défaut sous licence non commerciale — l'usage personnel et non commercial (y compris faire tourner la passerelle complète) est gratuit, et toute exploitation commerciale exige une licence commerciale.

À qui ça s'adresse

• Convient à ceux qui connectent déjà — ou prévoient de connecter — plusieurs serveurs MCP et API REST et veulent que la taille de la liste d'outils reste stable : quels que soient les backends raccrochés derrière, l'agent fait face à un petit ensemble fixe de méta-outils, et non à la somme de toutes les définitions de backends.
• Convient à ceux qui peuvent faire tourner un service en résident sur leur machine : la passerelle fonctionne comme un service HTTP local, et les clients s'y connectent via un point de terminaison local.
• Ne convient pas à un usage commercial direct : toute exploitation commerciale exige une licence commerciale, une prémisse à régler avant toute adoption ; seul un petit noyau MIT de briques génériques est proposé sous licence MIT.
• Avec peu de backends et une liste d'outils déjà courte, l'agrégation apporte peu ; les preuves ne donnent aucune donnée comparative sur les gains concrets à petite échelle.
• La liste des clients pris en charge, le déploiement à distance et les méthodes d'authentification ne sont pas couverts par les preuves : ce sont des points non confirmés, ne partez pas d'hypothèses non fondées.

Premier essai en 3 minutes

• Prérequis : un environnement où Homebrew est disponible. Le point d'entrée d'installation officiel est un tap Homebrew ; les preuves ne mentionnent aucun autre mode d'installation.
• Exécutez dans l'ordre les trois commandes du chemin officiel :

brew install MikkoParkkola/tap/mcp-gateway   # 1. install
mcp-gateway setup wizard --configure-client   # 2. import existing servers + wire up clients
mcp-gateway serve                            # 3. run

• Le setup wizard de la deuxième étape importe vos serveurs existants et raccorde les clients. Attention, c'est une écriture dans l'état local : il réécrit la configuration locale de la passerelle et des clients, ce n'est pas une opération en lecture seule ; quels fichiers sont écrits exactement et comment ils sont sauvegardés n'est pas détaillé dans les preuves.
• Une fois la troisième étape lancée, la passerelle tourne comme un service HTTP local. Côté client, connectez-vous selon l'extrait de configuration officiel. L'extrait déclare un service nommé gateway de type http, pointant vers le chemin /mcp sur le port local 39400 :

{
  "mcpServers": {
    "gateway": {
      "type": "http",
      "url": "http://localhost:39400/mcp"
    }
  }
}

• Signal de succès : une fois le client connecté à http://localhost:39400/mcp, la liste d'outils se condense en un petit ensemble fixe ; appelez alors une fois gateway_search_tools — officiellement, il sert à rechercher des outils backend — et si la recherche renvoie les outils de vos backends raccordés, la liaison client-passerelle est établie. Les preuves n'indiquent pas de readOnlyHint pour cet outil : son caractère en lecture seule reste non confirmé ; limitez le premier essai à la recherche, sans action en écriture. À ce stade, l'agent charge un petit ensemble fixe de méta-outils, et non toutes les définitions de backends.

Cas d'usage

• Cas 1 : alléger une pile d'outils multi-serveurs. Situation : le client est déjà relié à plusieurs serveurs MCP et chaque définition d'outils de backend consomme du contexte. Méthode : confiez vos serveurs existants à l'assistant pour import, et ne gardez côté client que http://localhost:39400/mcp comme unique point de terminaison. Résultat attendu : la surface d'outils de l'agent se fixe autour de 14 à 16 outils au lieu de la somme de toutes les définitions ; pour une capacité précise, localisez-la d'abord avec gateway_search_tools. Critère de jugement : le nombre d'outils affiché par le client est-il nettement inférieur au total des outils des backends raccordés ?
• Cas 2 : chercher puis invoquer une fois un vrai outil. Situation : vous voulez exécuter une capacité offerte par un backend connecté (serveur MCP ou API REST). Méthode : localisez d'abord l'outil cible avec gateway_search_tools, puis invoquez-le avec gateway_invoke — l'usage décrit officiellement tient en ces deux méta-outils, chercher puis invoquer. Résultat attendu : l'appel est transmis au backend correspondant, qui renvoie son résultat ; la sortie concrète dépend des backends que vous avez raccordés, et les preuves ne contiennent aucune sortie d'exemple fixe. Si la recherche ne trouve pas l'outil attendu, vérifiez d'abord que le backend a bien été importé via l'assistant, puis relancez la recherche.

Limites d'usage

• Licence et restrictions : l'usage personnel et non commercial est gratuit, y compris faire tourner la passerelle complète ; toute exploitation commerciale exige une licence commerciale ; seul un petit noyau MIT de briques génériques est ouvert sous MIT. Ce point décide de l'usage possible et de son périmètre : placez-le avant tout autre jugement.
• Nature lecture/écriture et effets de bord : la passerelle elle-même est un service local résident ; l'assistant écrit dans la configuration locale ; gateway_invoke pilote réellement les outils backend, et ses effets de bord dépendent du backend invoqué — avant d'exécuter, clarifiez la nature de l'opération visée et ses points de confirmation.
• Dépendances : l'installation passe par Homebrew ; le raccordement des serveurs existants se fait via l'import de l'assistant.
• Points non confirmés : liste des clients pris en charge, format de configuration concret pour raccorder des API REST, déploiement au-delà de localhost, mécanismes d'authentification, et présence éventuelle d'un readOnlyHint sur chaque méta-outil : rien de tout cela n'est précisé dans les preuves. L'existence d'un contrôle d'accès sur la passerelle elle-même et la manière dont les journaux sont tenus ne sont pas précisées non plus. L'absence de documentation n'est pas l'absence de risque ; avant toute adoption, référez-vous à la documentation actuelle du dépôt officiel.