Architecture Technique du MCP

Comprendre les rouages du protocole

Utiliser un connecteur ne demande aucune connaissance technique. Le diagnostiquer quand il se comporte mal, choisir le bon mode d’authentification ou décider d’où héberger votre propre serveur suppose en revanche de savoir ce qui se passe sous le capot.

Les modes de transport

Le protocole définit deux grandes familles de transport. La première, STDIO (Standard Input/Output), est destinée aux serveurs qui tournent sur la même machine que le client : la communication emprunte les flux d’entrée et de sortie standard du système d’exploitation. On la retrouve dans les outils en ligne de commande, l’accès au système de fichiers local et l’intégration d’applications de bureau. L’avantage est évident — aucun réseau, exécution immédiate — mais la limite l’est tout autant : STDIO ne fonctionne qu’en local et reste inutilisable avec Le Chat, qui est un service cloud. C’est le mode privilégié des IDE comme VS Code ou Cursor, où le serveur s’exécute directement sur le poste du développeur.

La seconde famille, Streamable HTTP, est le standard actuel pour les serveurs distants. Elle a succédé au protocole SSE (Server-Sent Events), dont l’inconvénient majeur était d’exiger une connexion permanente entre le client et le serveur. Streamable HTTP s’en affranchit, ce qui le rend plus robuste et plus facile à mettre à l’échelle ; il convient aux services cloud, aux API tierces et aux outils partagés entre équipes, et expose son point d’accès à l’URL /mcp. Le SSE reste accepté par la plupart des clients, mais il est considéré comme déprécié et devrait disparaître dans les prochains mois : n’écrivez plus de nouveau serveur sur cette base.

Pour Le Chat, la conséquence est directe : application cloud, il ne dialogue qu’avec des serveurs distants, et un serveur sur votre localhost n’a aucune signification pour lui. Si vous développez un serveur MCP et souhaitez le tester, deux voies s’offrent à vous — le déployer sur un service cloud, ou l’exposer temporairement avec une URL publique via un outil comme ngrok.

Les mécanismes d’authentification

Trois niveaux de sécurité coexistent. Le plus simple est l’absence d’authentification : le serveur est accessible à quiconque connaît son URL, ce qui convient à des outils publics manipulant des données non sensibles, par exemple un serveur qui récupère des informations publiques sur Reddit ou qui renvoie la météo.

Le deuxième niveau repose sur un token d’accès que vous générez depuis le service concerné, avec un périmètre de droits précis — lecture seule, écriture, accès à certains repositories. Le connecteur GitHub en est l’illustration typique : vous créez un Personal Access Token en cochant exactement ce que Le Chat pourra faire, lire vos repos, créer des issues, ouvrir des pull requests. Ce token est stocké de manière sécurisée et rattaché à votre compte utilisateur, jamais à l’organisation.

Le troisième niveau, OAuth 2.0, offre l’intégration la plus aboutie. Plutôt que de manipuler un token à la main, vous autorisez Le Chat à accéder à votre compte via un flux standardisé. Sur le connecteur Linear, un clic sur « Connect » ouvre une fenêtre d’autorisation ; une fois confirmée, Le Chat obtient des droits complets sur votre compte et vous pouvez les révoquer à tout instant. Le bénéfice est double : aucune manipulation manuelle de secret, et une révocation immédiate en cas de doute.

Architecture multi-serveurs

Dans la pratique, Le Chat ne parle jamais à un seul serveur mais à plusieurs simultanément, chacun apportant ses propres outils, prompts et ressources. Lorsqu’un serveur est activé, Le Chat lui envoie d’abord une requête de découverte, à laquelle le serveur répond en décrivant textuellement chaque outil disponible :

{
  "name": "get_weather",
  "description": "Retourne la météo pour une position donnée",
  "parameters": {
    "latitude": { "type": "float", "description": "Latitude" },
    "longitude": { "type": "float", "description": "Longitude" }
  },
  "returns": "string"
}

Cette description est le seul élément dont le modèle dispose pour décider quand et comment employer l’outil. Un description vague comme « fait des choses avec les données » condamne l’outil à ne jamais être appelé au bon moment. Les créateurs de serveurs MCP doivent donc soigner autant la formulation que le typage et les exemples.

À chaque message, le modèle déroule ensuite une boucle décisionnelle : il analyse la requête, détermine si un ou plusieurs outils sont nécessaires, sélectionne le plus pertinent et prépare ses arguments, envoie la requête au serveur et attend le résultat, puis décide s’il faut appeler autre chose ou s’il peut formuler sa réponse, avant de synthétiser le tout en langage naturel. Cette boucle peut tourner plusieurs fois et solliciter des serveurs différents au sein d’une même conversation.

Considérations de performance

Deux facteurs conditionnent la qualité de l’expérience. Le premier est le nombre d’outils : comme tout système d’agents, le modèle perd en précision quand la liste s’allonge. N’activez que les connecteurs utiles à la tâche du moment, coupez ceux dont vous n’avez plus besoin, et préférez des outils spécifiques et bien décrits à des outils génériques. Le second est la latence : chaque appel MCP est une requête réseau, dont le coût dépend de la localisation et des performances du serveur. Sur un workflow critique, choisissez des serveurs optimisés et géographiquement proches.

Points clés à retenir

• Le Chat utilise le mode Streamable HTTP pour communiquer avec les serveurs MCP distants
• Trois niveaux d’authentification sont supportés : aucune, token et OAuth 2.0
• Le Chat peut se connecter à plusieurs serveurs MCP simultanément
• Le modèle utilise les descriptions textuelles des outils pour décider quand les utiliser
• Limitez le nombre de connecteurs actifs pour optimiser la précision du modèle