7 bugs de la passerelle MCP : fuites de session, SSE mort et OAuth en mode passerelle

Après les démos sur le chemin heureux, un utilisateur Reddit a rencontré sept bugs spécifiques en plaçant une passerelle MCP entre des clients et serveurs réels. Les correctifs n'étaient pas du prompt engineering — il s'agissait de frontières de session explicites, de timeouts par outil, d'idempotence, de journaux d'actions structurés, de traces au niveau de la passerelle et de tests contre les appels d'outils simultanés. Le résultat a été une réduction importante du temps d'exécution parallèle des outils, mais le gain le plus important était de savoir où se situait la défaillance.

Les sept bugs qui comptaient vraiment

• Fuite d'état de session entre clients — l'état partagé entre sessions a provoqué une contamination des données.
• Connexions SSE se terminant silencieusement — aucune erreur n'était signalée lorsqu'une connexion SSE tombait.
• Flux OAuth fonctionnant en tests locaux mais échouant en mode passerelle — les URI de redirection ou la validation du jeton échouaient derrière le proxy.
• Sondes de découverte renvoyant des métadonnées obsolètes du serveur — les capacités mises en cache ne reflétaient pas les mises à jour du serveur.
• Écritures SQLite bloquant les appels d'outils parallèles — les verrous de base de données sérialisaient les requêtes concurrentes.
• Logique de réessai dupliquant les effets de bord des outils — les tentatives répétaient les mutations comme les écritures ou les appels API.
• Latence des outils cachée dans la passerelle au lieu de l'appel du modèle — la surveillance attribuait le temps à la mauvaise couche.

Le correctif : une infrastructure solide, pas de meilleurs prompts

L'approche de l'auteur pour chaque bug :

• Frontières de session explicites — état séparé par client, pas d'objets partagés.
• Politique de timeout par outil — timeouts individuels pour empêcher un outil lent de bloquer les autres.
• Idempotence lorsque possible — clés de déduplication ou comportement transactionnel pour rendre les tentatives sûres.
• Journaux d'actions structurés — journaux détaillés et analysables de chaque action de la passerelle pour le débogage.
• Traces au niveau de la passerelle — traçage distribué pour attribuer correctement la latence entre les couches.
• Tests contre les appels d'outils simultanés — tests d'intégration qui envoient des requêtes parallèles pour révéler les conditions de concurrence.

Ce sont des modèles spécifiques et pratiques pour quiconque utilise une passerelle MCP en production. L'idée clé du post : les problèmes difficiles sont l'isolation d'état, les défaillances silencieuses et l'observabilité — pas les prompts de modèles.