Au cœur du Model Context Protocol (MCP) : architecture, motivation et utilisation interne

Présentation

Les applications alimentées par LLM ont créé un besoin pressant de modèles permettant d'accéder à des données actualisées et spécifiques à un domaine provenant de diverses sources. MCP y remédie en fournissant un protocole unifié normalisant la manière dont les applications peuvent exposer dynamiquement les données et les fonctionnalités à toute application alimentée par LLM.

Vue d'ensemble du MCP

À la base, MCP suit une architecture client-serveur basée sur JSON-RPC dans laquelle une application hôte peut se connecter à plusieurs serveurs :

• Hôtes MCP sont des applications alimentées par LLM telles que Claude Desktop, les IDE ou les outils d'IA qui souhaitent accéder aux données via MCP.
• Clientèle MCP implémenter le protocole MCP côté client dans différents langages de programmation. Ils constituent le pont par lequel les hôtes MCP se connectent aux serveurs MCP.
• Serveurs MCP exposer des données et des fonctionnalités spécifiques via le protocole MCP. Il peut fournir trois principaux types de fonctionnalités :
  • Ressources sont des données que les serveurs MCP mettent à disposition pour que les applications puissent les lire. Elles peuvent inclure le contenu des fichiers, les réponses de l'API, etc. Les ressources sont contrôlées par les applications ; les applications décident de la manière de les inclure dans le flux utilisateur.
  • Outils sont des fonctionnalités et des données exposées par les serveurs MCP. Par exemple, un serveur Kubernetes MCP peut exposer des outils permettant d'obtenir tous les pods et de supprimer un pod. Les outils sont contrôlés par un modèle. Les LLM décident de les appeler en fonction du contexte donné.
  • Promptes sont des interactions utilisateur ou des flux de travail modélisables exposés par le serveur MCP. Ils sont contrôlés par l'utilisateur. Les applications LLM décident de la manière de les exposer afin que l'utilisateur puisse sélectionner l'invite appropriée.

Transport

Les transports définissent la façon dont un client et un serveur MCP communiquent entre eux.

STUDIO

Dans cette configuration, le client MCP de l'hôte MCP est chargé de faire tourner le serveur MCP sur la même machine. La communication entre le client MCP et le serveur MCP s'effectue via STDIN et STDOUT. Ici, un serveur MCP ne communique qu'avec un seul client MCP.

Une configuration typique ressemble à ceci :

Exemple : vous pouvez exécuter le serveur MCP de GitHub localement à l'aide de Docker et d'un jeton d'accès personnel (PAT)

GitHub - github/github-mcp-server : le serveur MCP officiel de GitHub

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

Autorisation

En règle générale, l'autorisation peut se faire de deux manières

1. Les utilisateurs peuvent utiliser des variables d'environnement pour transmettre leur jeton au processus du serveur MCP. Il s'agit de la méthode la plus utilisée.
2. Le serveur MCP peut implémenter le flux de périphériques OAuth2. Cependant, la spécification officielle du MCP ne décrit rien.

Restrictions

• L'appareil de l'utilisateur, qui exécute l'application alimentée par LLM, doit installer Docker ou Node/Python. Bien que cela ne soit pas un problème pour un développeur, cela réduit considérablement le nombre de personnes pouvant utiliser le serveur MCP.
• Étant donné que le serveur MCP est présent et fonctionne sur l'appareil de l'utilisateur, les mises à niveau deviennent fastidieuses et l'itération rapide en est affectée.
• Les applications Web exécutées sur le navigateur ne peuvent pas l'utiliser.
• Sans flux de périphériques OAuth2, les utilisateurs doivent configurer leurs jetons pour chaque serveur MCP. Les jetons ne sont souvent pas stockés en toute sécurité sur l'appareil et la rotation est fastidieuse.

Compte tenu de ses limites, le transport STDIO n'est pas adapté à la création de serveurs MCP personnalisés en plus du service et de la source de données d'une entreprise ou des abonnements SaaS tels que GitHub ou Slack. Cependant, cela sera utile pour les cas d'utilisation des outils de développement dans les IDE.

HTTP diffusable

Streamable HTTP permet aux serveurs MCP de gérer plusieurs clients MCP se connectant et communiquant à l'aide du protocole HTTP. Cela supprime de nombreuses limites du transport STDIO. Principalement :

1. Nous n'avons plus besoin d'héberger le serveur MCP sur l'appareil de l'utilisateur ; il peut être hébergé n'importe où.
2. Les nouvelles fonctionnalités ajoutées au serveur MCP sont instantanément disponibles pour tous les utilisateurs.
3. Les applications Web exécutées sur le navigateur peuvent l'utiliser.

Autorisation

L'autorisation pour ce transport est activement développée. La dernière spécification publiée le 26/03/2025 mentionne :

1. L'implémentation de MCP Auth doit suivre OAuth 2.1.
2. L'implémentation de MCP Auth doit suivre l'enregistrement dynamique des clients.

Un flux d'authentification typique ressemblerait à ceci :

Dans le flux ci-dessus, le serveur MCP qui émet des jetons agit en tant que serveur de ressources et de serveur d'autorisation. Cela n'est pas pratique pour les serveurs MCP pour Slack, GitHub, etc., où le fournisseur implémente déjà son serveur d'autorisation OAuth2. Les services hébergés en interne d'une entreprise sur des serveurs d'autorisation fournis par des IDP présentent le même problème (par exemple, l'installation d'ArgoCD derrière un serveur d'autorisation fourni par Okta).

La spécification permet de déléguer cette tâche à un serveur d'autorisation tiers, mais le serveur MCP doit émettre son jeton et gérer la relation avec le jeton tiers. Cela annule tous les avantages d'un serveur d'autorisation tiers, car le serveur MCP doit implémenter une gestion sécurisée des jetons et les routes OAuth2.

Limitation

• Les serveurs MCP avec authentification nécessitent une infrastructure telle qu'une base de données pour stocker et gérer en toute sécurité le cycle de vie de leurs jetons. Chaque serveur MCP deviendrait en fait son propre serveur d'autorisation, ce qui est redondant et impossible à gérer au sein d'une entreprise. La communauté travaille activement à la modification de la spécification d'autorisation afin d'améliorer cela.
• Des fournisseurs tels qu'Atlassian, Sentry, Slack, Github, etc., ne prennent pas en charge l'enregistrement dynamique des clients (DCR) ni même le client public OAuth2. La création de serveurs MCP sur ces fournisseurs devient plus difficile pour la communauté et plus de travail pour le fournisseur. Atlassian a récemment publié son propre serveur MCP, mais son implémentation DCR permet uniquement hôte local et quelques URI de redirection sélectionnés, comme Claude, etc.

L'approche de TrueFoundry

Chez TrueFoundry, nous voulons que nos collègues puissent activement connecter leurs comptes Atlassian, Sentry, Slack, GitHub, etc. à LLM pour ajouter du contexte. Nous voulons également nous assurer que chaque employé ne peut accéder aux ressources ou agir sur les ressources que via des LLM auxquels il est autorisé. MCP + OAuth2 semble être le moyen idéal pour exposer cela.

• Nous voulons nous concentrer sur la création de serveurs MCP de bonne qualité afin d'exposer les données et les fonctionnalités de manière plus efficace aux LLM. Nous voulons le faire en toute sécurité, en respectant les limites RBAC définies par le fournisseur.
• Nous ne souhaitons pas gérer de serveurs d'autorisation supplémentaires pour différents serveurs MCP. Nous souhaitons réutiliser les fonctionnalités OAuth2 des fournisseurs.
• Les fournisseurs ne prennent généralement en charge que les clients confidentiels OAuth2. DCR et client public ne sont même pas une option.
• La spécification d'autorisation MCP est toujours en train de changer et est en cours d'élaboration. Nous sommes impatients de voir la situation se stabiliser pour y travailler.

Compte tenu de ce qui précède, nous avons proposé l'architecture suivante.

Il y a quelques éléments ici.

Serveurs MCP

Nous avons créé des serveurs HTTP MCP pour des fournisseurs tels que Slack, Sentry, Atlasian, Github, etc., en suivant le transport HTTP Streamable.

Ces serveurs MCP assurent le proxy entre le LLM et les API HTTP du fournisseur. Notez qu'il ne s'agit pas d'une traduction 1:1. Les API HTTP de ces fournisseurs contiennent beaucoup de contenu inutile qui peut facilement faire dérailler le LLM et remplir la fenêtre contextuelle. Par exemple, un outil de liste de pods sur un serveur Kubernetes MCP contiendra beaucoup de contenu dupliqué car la spécification du pod se répète sur plusieurs pods. De grands champs, comme Champs gérés, ne sera pas requise pour la plupart des demandes des utilisateurs. D'autres fournisseurs SaaS auront des entités parents imbriquées, des champs qui ne sont pas fonctionnels, comme l'URL de l'avatar, etc. C'est là que nous voulons consacrer la majeure partie de notre temps de développement. À terme, nous avons besoin d'un système dans MCP qui puisse aider les LLM à découvrir le modèle de données d'un système, puis à effectuer des requêtes dynamiques pour des domaines de ressources spécifiques.

Ces serveurs MCP attendent un en-tête d'autorisation HTTP et le transmettent directement à l'API HTTP du fournisseur.

Enregistrement de serveurs MCP sur TrueFoundry

Après avoir déployé les serveurs MCP, nous créons des applications OAuth2 ou des clients confidentiels pour chaque fournisseur. Voici à quoi cela ressemble pour Slack.

Ci-dessus, vous pouvez également remarquer que l'URI de redirection de l'autorisateur est configuré. Cela ressemble généralement à quelque chose comme https://base-url/mcp-integrations/oauth2/callback.

Ensuite, nous intégrons le serveur MCP avec l'URL.

Nous pouvons utiliser les étendues pour rendre l'ensemble de cette intégration en lecture seule, si nous le voulons ou si nous autorisons des types de ressources spécifiques. Même si le serveur MCP dispose d'outils pour « écrire » toutes les ressources et que l'utilisateur dispose d'un accès « écriture », les LLM ne pourront pas obtenir les mêmes privilèges.

Sélection du serveur MCP sur la passerelle TrueFoundry et autorisation

Une fois intégré, nous pouvons sélectionner le serveur MCP sur le Gateway Playground.

Si l'utilisateur n'est pas autorisé, nous utilisons les informations du client OAuth2 dans l'intégration et lui indiquons le flux de code d'autorisation OAuth2. À la fin du processus, TrueFoundry enregistre en toute sécurité les jetons d'accès et d'actualisation (s'ils sont pris en charge et activés).

Nous pouvons supprimer nos informations d'identification de TrueFoundry ou même les révoquer directement auprès du fournisseur.

Commencez à l'utiliser !

Une fois autorisé, vous pouvez utiliser le contexte des serveurs MCP directement sur notre Playground.

Notez que nous ne transmettons aucune information d'identification OAuth2 au frontend. Le frontend appelle une API :

curl -X POST "https://base-url/api/llm/agent/responses" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-main/gpt-4o-mini",
    "messages": [
      {
        "role": "user",
        "content": "what are the issues in my app"
      }
    ],
    "tools": [
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:sentry",
        "tools": ["list_projects", "list_issues"]
      },
      {
        "type": "mcp-server",
        "integration_fqn": "truefoundry:custom:devtest-mcp-servers:mcp-server:slack"
      }
    ]
  }'

‍

LLM Gateway implémente la boucle « agentic » en envoyant les messages initiaux et les descriptions des outils du serveur MCP au LLM. L'utilisateur peut également filtrer les outils exposés au LLM. Sur la base de la réponse du LLM, LLM Gateway peut communiquer avec les serveurs MCP et transmettre les informations d'identification des appelants. Nous actualisons automatiquement toutes les informations d'identification de courte durée. Les mises à jour sont envoyées au frontend à l'aide de SSE.

Conclusion

Ce flux MCP + OAuth2 a permis à nos collègues d'intégrer en toute sécurité les données de fournisseurs tels que Slack, GitHub, Sentry, etc., dans leur flux de travail centré sur le LLM.

Quelques cas d'utilisation,

• Les LLM peuvent accéder à Sentry via MCP pour récupérer les détails des erreurs et les corréler avec les modifications de code associées depuis GitHub pour un débogage plus rapide.
• Les LLM créent, mettent à jour et interrogent des tickets Jira via MCP, rationalisant ainsi les flux de travail des développeurs.
• Les LLM peuvent accéder aux conversations Slack via MCP pour analyser et résumer les longs fils de discussion, aidant ainsi les équipes à comprendre rapidement les décisions et les actions à entreprendre sans avoir à lire l'intégralité des journaux de discussion.