Le flux de travail de l'agent IA : support MCP natif dans les tunnels locaux

L’année 2026 a introduit un besoin très spécifique, mais de plus en plus courant dans les flux de travail des développeurs : des agents IA capables d’ouvrir, gérer et détruire des tunnels réseau locaux sans intervention humaine pour coller des URLs entre une fenêtre de terminal et une interface de chat. Avec des assistants de codage comme Claude Code, Cursor et Windsurf qui prennent davantage accès au terminal et à l’environnement, leur capacité à interagir directement avec l’infrastructure locale devient un vrai goulot d’étranglement pour tester des webhooks ou partager un serveur de développement.

Plutôt que de s’appuyer sur des méthodes traditionnelles de port forwarding conçues pour des opérateurs humains, quelques services de tunneling — rustunnel et Pinggy en tête — proposent désormais des serveurs Model Context Protocol (MCP) dédiés, permettant à un agent d’opérer des tunnels directement. Anthropic a aussi lancé son propre produit sous le nom littéral “MCP tunnels,” bien qu’il résolve un problème différent de celui dont cet article parle principalement — plus d’explications ci-dessous.

Ce guide explique ce qu’est réellement un tunnel MCP (il existe désormais deux significations distinctes de cette expression), ce que les outils d’agent de rustunnel et Pinggy exposent réellement, comment les instructions d’installation diffèrent selon le client, et où s’intègrent des passerelles MCP comme Bifrost lorsque vous gérez plus de quelques serveurs.

---

1. L’évolution du flux de travail de l’agent IA

L’ancien processus n’a pas disparu : lancer un tunnel inversé depuis le CLI, attendre la connexion, copier l’URL publique générée, et la coller dans un tableau de bord tiers et une fenêtre de chat. Cela fonctionne pour un cas unique, mais cela brise le flux autonome d’un agent qui pilote déjà le terminal — si Claude Code implémente et teste un endpoint webhook, il ne devrait pas devoir s’arrêter pour demander une URL publique.

Le protocole Model Context Protocol, que Anthropic a open-sourcé le 25 novembre 2024, a changé cela. MCP définit trois rôles : un hôte (l’application IA — Claude Code, Cursor, Claude Desktop, Windsurf, et désormais ChatGPT et GitHub Copilot aussi), un client (la connexion protocolée que l’hôte maintient avec un serveur donné), et un serveur (un processus exposant un ensemble spécifique d’outils, ressources ou prompts). Avant l’existence d’un protocole partagé, connecter M applications IA à N outils signifiait presque M×N intégrations personnalisées ; MCP réduit cela à environ M+N, puisque chaque côté n’a qu’à implémenter le protocole une seule fois. L’adoption a été rapide — Microsoft et GitHub ont rejoint le comité de pilotage de MCP lors de Build 2025, et OpenAI a ajouté le support MCP à son SDK Agents et API Responses la même année.

Pour le tunneling spécifiquement, cela signifie qu’un agent peut appeler un outil comme create_tunnel directement et recevoir des données structurées (une URL publique, un ID de tunnel, un statut) au lieu d’exécuter une commande CLI et d’analyser la sortie stdout.

---

2. Démystifier le “MCP Tunnel” — Deux choses différentes en 2026

Voici où une version préliminaire de cet article nécessitait la correction la plus importante : “MCP tunnel” désigne désormais deux architectures vraiment différentes, et les confondre enverra les lecteurs vers le mauvais outil.

2a. Tunnels gérés par l’agent (le sujet principal de cet article)

C’est le modèle que rustunnel et Pinggy construisent : un client de fournisseur de tunneling fonctionne à côté d’un service local et compose sortant via TLS vers un serveur edge public. L’agent appelle un outil MCP pour ouvrir, lister et fermer ces tunnels. Direction du trafic : machine locale → internet public, avec l’agent IA comme opérateur.

• Pas de règles entrantes. Rien n’est exposé tant que le client ne compose pas ; les pare-feux d’entreprise permettant HTTPS sortant n’ont pas besoin d’être modifiés.
• Exposition limitée. Contrairement à un VPN, un tunnel expose une seule instance de service, pas tout le réseau.
• Transport chiffré, généralement avec l’authentification propre au fournisseur de tunnel (OAuth, tokens bearer, ou un token API lié à un compte) en couche supplémentaire.

2b. “MCP tunnels” d’Anthropic (un produit différent, dans l’autre sens)

Anthropic propose une fonctionnalité en version préliminaire de recherche sur Claude Platform (anciennement Claude Developer Platform / Console) qui porte littéralement le nom “MCP tunnels,” et elle résout le problème inverse : connecter Claude à un serveur MCP qui réside dans un réseau privé, sans ouvrir de ports entrants sur ce réseau. Direction du trafic : Claude → votre réseau privé.

L’architecture : une pile de tunnels légère (un proxy plus un conteneur cloudflared) tourne dans votre réseau et ouvre une connexion sortante vers Cloudflare, utilisé par Anthropic comme sous-traitant pour cette fonctionnalité. Vous la déployez avec Helm (Kubernetes) ou Docker Compose, en enregistrant un certificat CA via la Claude Console, et votre serveur MCP privé devient accessible à quelque chose comme https://<sous-domaine>.<domaine-tunnel>/mcp — visible uniquement par les agents gérés Claude et l’API Messages, jamais sur internet public. Le proxy est délibérément conservateur : par défaut, il ne compose qu’avec des adresses dans les plages privées RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

À l’heure actuelle, les MCP tunnels sont en version de recherche, accessibles aux organisations sur le plan Claude Enterprise sur demande, et explicitement déployés “tel quel” — sans engagement de disponibilité, de support ou de continuité, dépendant de la disponibilité de Cloudflare. Si vous construisez une architecture où l’agent accède à une base de données privée, il vaut mieux demander l’accès avant d’utiliser une solution tierce ; si vous construisez un workflow où l’agent expose mon ordinateur portable à internet pour une démo ou un test webhook, c’est la section 2a, et le reste de cet article.

---

3. rustunnel et l’essor de l’agent-opérateur

La plupart des services de tunneling supposent encore qu’un humain soit à la console. rustunnel — un serveur de tunneling auto-hébergé, sous licence AGPLv3, écrit en Rust, avec un service géré en option pay-as-you-go — a été conçu avec l’agent comme opérateur principal. C’est un projet vraiment modeste (635 étoiles GitHub à l’écriture) mais son intégration MCP est exceptionnellement bien documentée pour une taille aussi réduite.

Comment il se déploie

Une correction importante à signaler d’emblée : le serveur MCP de rustunnel (rustunnel-mcp) n’est pas un package npm que l’on exécute avec npx. C’est un binaire Rust natif, distribué de la même manière que le client CLI rustunnel — via Homebrew (brew tap joaoh82/rustunnel && brew install rustunnel qui installe les deux binaires) ou compilé depuis la source avec cargo build --release -p rustunnel-mcp. Il communique via MCP sur stdio.

L’outil couvre tout le cycle de vie du tunnel — six outils, pas quatre :

Outil	Description
create_tunnel	Ouvre un tunnel et retourne l’URL publique — HTTP/TCP/UDP, P2P, pools équilibrés avec vérification de santé
list_tunnels	Liste tous les tunnels actifs
close_tunnel	Ferme un tunnel par ID
list_regions	Liste les régions serveur disponibles
get_connection_info	Retourne la commande CLI pour agents cloud/sandbox
get_tunnel_history	Récupère l’historique des tunnels

Le service hébergé opère dans trois régions — eu (Helsinki), us (Hillsboro, OR), et ap (Singapour) — et le client sélectionne automatiquement la plus proche sauf si vous la fixez. Tarification : gratuit jusqu’à 3 tunnels sans sous-domaines personnalisés, pay-as-you-go à 3 $/mois minimum + 0,10 $/GB (tunnels illimités, sous-domaines personnalisés), ou auto-hébergé gratuitement. Les déploiements auto-hébergés peuvent exposer des métriques Prometheus et un journal d’audit JSON-lines — ces options de configuration dépendent du serveur que vous exécutez, et ne sont pas par défaut dans le plan géré, à vérifier.

La boucle autonome, corrigée

Le scénario décrit dans une version préliminaire — demander à Claude Code d’implémenter un gestionnaire webhook Stripe, de l’exposer, et de mettre à jour un script de tableau de bord — est réel et fonctionne grosso modo ainsi, avec deux corrections : le pattern d’URL du tunnel est régional (https://abc123.eu.edge.rustunnel.com, pas un domaine .rustunnel.net seul), et get_connection_info ne retourne pas “latence, données régionales, et logs de requêtes” — selon la documentation, il retourne la commande CLI qu’un agent cloud ou sandbox doit utiliser pour se reconnecter, ce qui est plus précis.

Son installation

Trois méthodes documentées, par ordre croissant d’effort manuel :

Plugin Claude Code (le plus simple, selon le README de rustunnel) :

/plugin install rustunnel

Le plugin demande une fois votre adresse serveur et votre token API, les stocke, et démarre le serveur MCP en arrière-plan — pas besoin de modifier .mcp.json. Attention : cela diffère du schéma en deux étapes utilisé par la plupart des plugins Claude Code (/plugin marketplace add <owner>/<repo> puis /plugin install <name>@<marketplace>). Si la commande en une ligne ne fonctionne pas, utilisez /plugin marketplace add joaoh82/rustunnel et vérifiez le nom exact dans plugins/claude-code/.

Enregistrement stdio manuel :

claude mcp add --transport stdio rustunnel \
  --env RUSTUNNEL_TOKEN=VOTRE_TOKEN \
  -- rustunnel-mcp --server edge.rustunnel.com:4040 --api https://edge.rustunnel.com:8443

Claude Desktop (ou Windsurf, Cline — même format JSON), modifié directement :

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "<votre-token>" }
    }
  }
}

Pour Cursor, rustunnel propose aussi un lien profond “Ajouter à Cursor” en une clic sur son README, pré-remplissant cette config — il ne reste plus qu’à coller votre token API.

---

4. Comparaison de l’écosystème de tunneling en 2026

ngrok

Le support MCP de ngrok en première partie n’est pas la création de tunnels par l’agent — c’est l’inverse. Le pattern documenté de ngrok consiste à utiliser ngrok comme passerelle MCP : vous exécutez l’agent ngrok à côté de votre propre serveur MCP auto-hébergé, déclarez un Point d’Agent interne, et utilisez le moteur de Politique de Trafic de ngrok pour authentifier et restreindre les clients (par ex., seules les plages IP d’Anthropic). C’est une couche de sécurité et d’observabilité devant un serveur MCP que vous gérez déjà, plus proche du rôle de Kong ou Bifrost (section 7) que de ce que fait rustunnel. Si vous souhaitez qu’un agent opère votre compte ngrok — créant et détruisant des tunnels comme le font les outils rustunnel — cela existe aussi, mais uniquement via des serveurs communautaires (ex. ngrok-mcp sur GitHub, ou la boîte à outils ngrok de Composio), pas via des outils officiels ngrok.

Pinggy

Une version préliminaire de cet article décrivait Pinggy comme “très efficace pour exposer des outils, mais moins axé sur la gestion de tunnel par l’agent.” Ce qui sous-estimait l’offre actuelle de Pinggy : il fournit deux outils séparés — une compétence Agent (npx skills add https://pinggy.io, que l’agent lit avant d’exécuter ses commandes) et un serveur MCP en accès anticipé (pinggy_mcp, un package Python/uv) qui enregistre treize outils pour l’authentification, la gestion des tunnels (start_tunnel, stop_tunnel, list_tunnels, get_tunnel_info), partage WebDAV, et gestion des tokens. L’authentification se fait via OAuth 2.0 Device Authorization Grant (RFC 8628) plutôt qu’une clé API collée. C’est explicitement marqué expérimental par son mainteneur, et les tunnels sont liés au processus MCP — ils ne survivent pas à un redémarrage du serveur, ce qui peut être vu comme une feature : pas de daemon persistant laissant un sous-domaine public obsolète.

Pour le pattern plus étroit “exposer un serveur MCP privé existant à un agent cloud distant” (pas gestion de tunnel, juste création pour un serveur spécifique), la méthode SSH classique fonctionne toujours :

ssh -p 443 -R0:localhost:5000 a.pinggy.io

claude mcp add --transport http MyLocalDB https://rndm-string.pinggy.link/mcp

Cloudflare Tunnel

Absente des versions antérieures, et à inclure : Cloudflare propose un ensemble d’outils pour toute sa plateforme développeur — pas spécifique au tunnel — via un plugin Skills (/plugin marketplace add cloudflare/skills puis /plugin install cloudflare@cloudflare). La compétence cloudflare couvre Workers, stockage, IA, et réseau, y compris Tunnel et Spectrum, ainsi que leurs propres serveurs MCP gérés pour opérations de compte (DNS, règles WAF, etc.) via OAuth. Il n’existe pas d’outil dédié create_tunnel comme rustunnel ou Pinggy — un agent utilisant Cloudflare Tunnel pilote encore principalement cloudflared via la CLI classique que la compétence lui enseigne, plutôt qu’une gestion dédiée.

LocalCan, LocalXpose, frp, Playit.gg, et localhost.run

Ces solutions restent conformes à la description initiale. LocalCan (intégration macOS native .local) et LocalXpose (GUI/CLI multiplateforme, avec client officiel node-localxpose) sont efficaces pour les développeurs humains mais n’ont pas de serveur MCP officiel intégré — il faut construire une couche autour de leur CLI ou API REST. frp reste la solution auto-hébergée standard pour les charges UDP et jeux, et Playit.gg, avec son routage anycast, couvre la même niche sans port forwarding ; ce sont des infrastructures de bas niveau nécessitant un serveur MCP personnalisé pour mapper des requêtes en langage naturel vers des modifications de fichiers de config. localhost.run remplit toujours la même niche SSH, zéro installation, pour exposer rapidement un MCP gateway existant (comme Bifrost, ci-dessous) à un client distant.

---

5. Intégration des tunnels MCP avec Claude Code

Claude Code supporte trois transports MCP : stdio (par défaut, pour processus locaux), HTTP (recommandé pour serveurs distants/cloud), et SSE, qui est en cours de suppression au profit de HTTP. Tous sont enregistrés via claude mcp add, ou en modifiant manuellement .mcp.json / ~/.claude.json.

Certificats auto-signés et TLS en développement local

Si vous pointez Claude Code vers un proxy de tunnel local avec un certificat auto-signé, vous rencontrerez unable to verify the first certificate — les clients MCP basés sur Node.js (incluant Claude Code) rejettent par défaut les certificats auto-signés. La solution documentée est exactement ce que montre une version préliminaire :

{
  "env": {
    "NODE_TLS_REJECT_UNAUTHORIZED": "0"
  }
}

dans ~/.claude/settings.json. À noter : cette option désactive la vérification des certificats pour toutes les connexions sortantes de Claude Code pour cette session — y compris api.anthropic.com et le registre MCP, pas seulement votre tunnel local. La communauté technique d’Anthropic a signalé que cette portée est plus large que prévu ; utilisez-la strictement comme un drapeau temporaire en développement local, en lançant NODE_TLS_REJECT_UNAUTHORIZED=0 claude pour une seule session si possible, ou en utilisant NODE_EXTRA_CA_CERTS avec votre vrai certificat CA pour limiter la confiance.

---

6. Intégration avec Cursor et Windsurf

Cursor et Windsurf configurent MCP via des fichiers JSON plutôt qu’une CLI. Les chemins ne sont pas interchangeables :

• Cursor — global : ~/.cursor/mcp.json ; par projet : .cursor/mcp.json à la racine du projet.
• Windsurf — ~/.codeium/windsurf/mcp_config.json.

Les deux utilisent la même structure JSON mcpServers que Claude Desktop :

{
  "mcpServers": {
    "rustunnel": {
      "command": "rustunnel-mcp",
      "args": ["--server", "edge.rustunnel.com:4040", "--api", "https://edge.rustunnel.com:8443"],
      "env": { "RUSTUNNEL_TOKEN": "votre_token_api" }
    }
  }
}

Attention : VS Code utilise un schéma différent (servers, pas mcpServers, et un champ explicite "type": "stdio") dans ~/.vscode/mcp.json ou .vscode/mcp.json. Ne pas réutiliser une config Cursor telle quelle pour VS Code — elle ne sera pas lue correctement.

Une fois sauvegardée, l’agent de Cursor ou Windsurf détecte automatiquement le nouveau serveur. Demandez-lui d’“exposer le frontend Next.js à Internet” et il appellera create_tunnel (ou celui de Pinggy, start_tunnel) tout seul.

---

7. Scalabilité avec les passerelles MCP : Bifrost et Kong

Connecter un agent à un serveur MCP de tunneling, une base de données, et un moteur de recherche, peut sembler trivial au début — mais cela devient complexe dès que vous gérez dix ou quinze serveurs MCP. Chaque serveur expose généralement 10 à 30 définitions d’outils, et Claude Code charge le catalogue complet de chaque serveur connecté dans le contexte avant de traiter votre prompt. C’est là que les passerelles MCP interviennent.

Bifrost

Bifrost est une passerelle AI open-source en Go de Maxim AI, qui agit à la fois comme client MCP (se connectant à votre serveur de tunneling, outils de base de données, etc.) et comme serveur MCP (exposant un point /mcp agrégé en interne pour Claude Code). La configuration se fait en une commande — notez le schéma corrigé, http plutôt que https pour une instance locale :

claude mcp add --transport http bifrost http://localhost:8080/mcp

Bifrost ajoute environ 11 microsecondes de surcharge par requête à 5000 requêtes/sec, et son “Mode Code” — où le modèle écrit du code en fonction des définitions d’outils plutôt que d’injecter chaque schéma dans le contexte — a été mesuré pour réduire jusqu’à 92% le nombre de tokens d’entrée dans ses propres benchmarks tout en maintenant le taux de réussite des tâches. Il gère aussi la gouvernance par clés virtuelles (limites et budgets par équipe) et le routage multi-fournisseurs LLM (Anthropic, OpenAI, Bedrock, Vertex AI, etc.) via la même déploiement.

Kong AI Gateway

Kong a intégré le support MCP natif dans Kong Gateway 3.12 (octobre 2025) dans le cadre de son AI Gateway : le plugin AI MCP Proxy, qui peut transformer une API REST existante en outils MCP ou faire du proxy vers un serveur MCP existant, et le plugin AI MCP OAuth2, pour l’authentification OAuth 2.0. C’est idéal si vous utilisez déjà Kong pour la gestion d’API et souhaitez faire transiter le trafic AI/MCP sous la même gouvernance ; il est plus lourd opérationnellement que Bifrost, car c’est un API Gateway complet avec des capacités AI, plutôt qu’une infrastructure dédiée à l’agent.

---

8. Modes de permission : ce que “Autonome” signifie réellement aujourd’hui

Une précision importante : la configuration par défaut de Claude Code n’exécute pas silencieusement chaque appel d’outil MCP, y compris create_tunnel. La majorité des clients MCP — Cursor inclus — demandent une confirmation avant d’exécuter un outil. Claude Code supporte un mode complet de contournement (--dangerously-skip-permissions, ou --permission-mode bypassPermissions) qui évite toute demande d’approbation pour les modifications de fichiers, commandes bash, et appels MCP pour une session ; la documentation d’Anthropic décrit ce mode comme destiné à des environnements isolés — conteneurs, VM, sandbox — où une action compromise ne peut pas atteindre quelque chose d’important, avec un avertissement unique avant exécution.

De plus, à partir du 14 août 2026, Anthropic a mis en place un mode “auto” par défaut pour Pro, Max, et les plans d’équipe, plutôt que de demander une approbation manuelle à chaque fois — la raison officielle étant qu’un classificateur détecte la majorité des commandes dangereuses en test, contre un taux de détection beaucoup plus faible par des humains. La conséquence pratique pour les workflows “l’agent ouvre un tunnel sans s’arrêter pour demander” : si cette commande s’exécute silencieusement ou demande une approbation dépend désormais du mode de permission du session, pas seulement de la capacité technique du MCP.

---

9. Conclusion

La transition des commandes CLI de tunnel pilotées par l’humain vers des appels d’outils MCP pilotés par l’agent est réelle et en cours de déploiement. Cependant, elle n’est pas encore uniforme entre tous les fournisseurs. rustunnel et Pinggy sont actuellement les deux fournisseurs proposant de véritables serveurs MCP de gestion de tunnels, tous deux encore en phase expérimentale ou préliminaire. ngrok et Cloudflare ont adopté une approche inverse — des passerelles et plateformes plutôt que la création de tunnels par l’agent — ce qui constitue une réponse différente à un problème similaire. Et le “MCP tunnels” d’Anthropic en version de recherche ne résout aucun de ces deux cas ; c’est une fonctionnalité de connectivité réseau privé-auxiliaire à Claude, qui partage un nom avec toute cette catégorie, ce qui mérite d’être signalé pour éviter toute confusion dans un diagramme d’architecture.

---

Changelog

Corrections et ajouts vérifiés selon le README et la documentation GitHub de rustunnel, la documentation MCP de Pinggy, la documentation officielle MCP de Claude Code, la documentation ngrok, la documentation d’installation agent de Cloudflare, la documentation des plugins Kong, la documentation Bifrost de Maxim AI, et la documentation Claude Platform d’Anthropic :

• Suppression des métadonnées : la ligne SEO “Target Keywords” et la référence à l’image de couverture fictive, conformément au style de la série.
• Plus grande correction structurelle : séparation de “MCP tunnel” en deux significations distinctes en 2026 — tunnels gérés par l’agent tiers (ce que couvre le reste de l’article) versus la fonctionnalité de recherche “MCP tunnels” d’Anthropic, qui fonctionne dans l’autre sens (connecter Claude à un serveur MCP privé via un tunnel Cloudflare, en mode Enterprise, en version de recherche).
• Distribution rustunnel-mcp corrigée : le brouillon montrait npx rustunnel-mcp ; rustunnel-mcp est un binaire Rust natif distribué via Homebrew ou compilé depuis la source, pas un package npm. Toutes les instructions d’installation ont été réécrites en conséquence.
• Tableau des outils MCP de rustunnel complété : le brouillon listait quatre outils (create_tunnel, list_tunnels, close_tunnel, get_connection_info) ; la documentation en liste six, ajoutant list_regions et get_tunnel_history. La description de get_connection_info a été corrigée — le brouillon disait qu’il récupérait “latence, données régionales, et logs de requêtes” ; il retourne en fait la commande CLI pour que les agents cloud/sandbox se reconnectent.
• Correction du domaine de tunnel : l’URL d’exemple (https://random-id.rustunnel.net) a été remplacée par le vrai pattern régional (https://abc123.eu.edge.rustunnel.com).
• Tarification et régions rustunnel ajoutées : niveau gratuit (3 tunnels, pas de sous-domaines personnalisés), pay-as-you-go (3 $/mois minimum + 0,10 $/GB), auto-hébergé gratuit ; trois régions hébergées (eu/Helsinki, us/Hillsboro OR, ap/Singapour) — tout cela absent du brouillon.
• Installation du plugin Claude Code signalée comme non standard : /plugin install rustunnel est documenté tel quel dans le README de rustunnel, mais saute l’étape /plugin marketplace add que la majorité des plugins requièrent ; ajout de cette nuance et d’une méthode de secours.
• Histoire de Pinggy corrigée et enrichie : le brouillon décrivait Pinggy comme “moins axé sur la gestion de tunnel par l’agent” — Pinggy propose en fait deux outils séparés : une compétence Agent (npx skills add https://pinggy.io) et un serveur MCP expérimental (pinggy_mcp, 13 outils) distinct de son Agent Skill. Les exemples SSH pour Pinggy sont toujours valides pour ce cas précis.
• Correction de la première partie MCP d’ngrok : le brouillon laissait entendre que ngrok évoluait vers la création de tunnels pilotés par l’agent (“wrap dans un serveur MCP”); en réalité, la pattern officiel est inverse — une passerelle MCP devant un serveur MCP auto-hébergé, utilisant la Politique de Trafic pour l’authentification/IP restriction. La création de tunnels par l’agent ngrok existe uniquement via des serveurs MCP communautaires, pas via des outils officiels.
• Ajout de Cloudflare Tunnel : absent du brouillon, ajouté en tant qu’alternative, précisant que l’outil d’agent Cloudflare est global (Plugins Skills pour Workers, stockage, réseau, Tunnel, Spectrum) plutôt qu’un serveur MCP dédié.
• Correction de la syntaxe de la commande Bifrost : le brouillon utilisait https://localhost:8080/mcp ; le schéma correct pour une instance locale est http://.
• Performance de Bifrost sourcée : environ 11 microsecondes de surcharge par requête à 5000 req/sec, et réduction jusqu’à 92% des tokens d’entrée en Mode Code, selon ses propres benchmarks.
• Correction de la section Kong et de la date : le brouillon mentionnait “plugins AI Gateway” ; précisé avec les noms exacts (AI MCP Proxy, AI MCP OAuth2) et la version (Kong Gateway 3.12, octobre 2025).
• Avertissement sur NODE_TLS_REJECT_UNAUTHORIZED : la note indique que cette option désactive la vérification TLS pour toutes les connexions sortantes, pas seulement le tunnel local, et recommande NODE_EXTRA_CA_CERTS comme alternative.
• Différenciation des schémas de config Cursor et VS Code : précisé que VS Code utilise un schéma différent (servers, "type": "stdio") dans un autre fichier, pour éviter la réutilisation incorrecte.
• Ajout d’une section sur les modes de permission de Claude Code : clarifié que par défaut, chaque appel MCP demande une confirmation, mais un mode bypass complet existe, et qu’à partir d’août 2026, un mode “auto” est la configuration par défaut pour certains plans.
• Ajout du contexte historique du protocole MCP : date de lancement, terminologie, évolution, et étape clé Build 2025.
• Suppression du ton promotionnel excessif : aligné avec le style de la série.