Guide visuel pour débuter avec l’architecture MCP

Le Model Context Protocol (MCP) a ouvert de nombreuses possibilités pour étendre les capacités des grands modèles de langage, mais il a aussi semé une certaine confusion. J’ai donc entrepris de créer un guide pour débutants qui explique visuellement, schémas à l’appui, à quoi ressemble une architecture MCP.

Si vous êtes développeur, vous avez probablement entendu parler des serveurs MCP qui règnent en maîtres dans le développement logiciel en mode agentique, avec des outils comme Cursor, Windsurf et même les nouveaux workflows agentiques de VS Code. Mais ils ne se limitent pas au développement logiciel : ils permettent également de créer des expériences LLM riches et fluides pour les utilisateurs finaux, en enrichissant le modèle au-delà des données sur lesquelles il a été entraîné et en exploitant ses capacités de raisonnement pour déclencher des actions.

Comprendre MCP

Les LLM sont essentiellement une base de connaissances compressée regroupant toutes les données sur lesquelles ils ont été entraînés. Pour reprendre une analogie avec le fonctionnement de notre cerveau, ils apprennent selon un principe similaire à celui des réseaux de neurones, ce qui leur permet de raisonner et d’effectuer d’importants sauts logiques qui évoquent l’intelligence. Aussi impressionnants soient-ils, les grands modèles de langage restent limités à leurs propres données.

Les MCP font le lien entre les LLM et les connaissances et les actions qui dépassent leurs capacités. Certains diront que cette possibilité existait déjà, depuis qu’OpenAI a introduit les fonctionnalités d’appel de fonctions ou d’appel d’outils. Mais les MCP ont repris ce concept pour en faire une norme de communication ouverte, fondée sur des interfaces structurées, qui permet le déploiement et la découverte d’outils distribués et dynamiques. Nous reviendrons plus loin sur la différence entre MCP et appel de fonctions.

Hôtes, clients et serveurs MCP

Maintenant que nous avons présenté l’objectif des MCP, nous pouvons examiner leurs différents éléments. MCP fait intervenir trois entités :

• L’hôte MCP est l’application basée sur l’IA qui s’intègre aux MCP. Claude Desktop, Cursor, Windsurf et VS Code en sont des exemples concrets. Ces applications s’intègrent aux MCP en implémentant un client MCP.

• Le client MCP : le client MCP est la couche d’implémentation brute, souvent intégrée à des applications d’IA avancées, à des frameworks agentiques et à d’autres applications du même type. C’est l’interface qui communique avec les serveurs MCP.

• Le serveur MCP : le serveur MCP fournit des capacités d’interaction avec le « monde réel ». Le LLM n’a pas accès à vos fichiers locaux, n’est-ce pas ? Mais si un serveur MCP les met à sa disposition, le LLM peut alors les répertorier, les lire et les modifier. Les serveurs MCP implémentent ces capacités étendues, ces connaissances et ces actions auxquelles le LLM peut désormais accéder.

Remarque : vous constaterez probablement que les hôtes MCP sont souvent simplement appelés clients MCP, car ce terme a été étendu pour désigner l’application basée sur l’IA dans son ensemble.

En bref : appels de fonctions et outils

Les serveurs MCP mettent le plus souvent des outils à la disposition des clients MCP. Parmi ces outils, on peut citer « lire un fichier » ou « répertorier toutes les branches d’un dépôt git distant ».

Comment s’y prennent-ils ? Ils indiquent au LLM : « Hé, voici les outils dont je dispose. L’un d’eux s’appelle read_file ». Le LLM peut alors déclencher spécifiquement cet outil via le Model Context Protocol, qui le relie à une implémentation de fonction réelle dans le code du serveur MCP :

function tool_read_file(filepath) {
   // implementation
}

Mais les outils ne sont pas nouveaux. L’appel d’outils, également appelé appel de fonctions, a été introduit par OpenAI fin 2023. L’appel de fonctions a ensuite été implémenté dans chaque application basée sur l’IA et devait être orchestré spécifiquement par l’application pour le LLM. Point encore plus important : les appels de fonctions n’étaient pas pris en charge par tous les modèles.

Nous verrons plus loin en quoi les MCP offrent une solution plus complète que les appels de fonctions.

Types de transport des serveurs MCP : STDIO ou HTTP

Les serveurs MCP peuvent d’abord laisser penser qu’il s’agit de véritables serveurs réseau. Pourtant, leur succès tient aux processus qui s’exécutent localement et communiquent via le transport d’entrée et de sortie standard.

Qu’est-ce que STDIO ?

STDIO (entrée, sortie et erreur standard) est un mécanisme fondamental de communication textuelle entre les processus système. Il s’agit concrètement de commandes ou de programmes, comme l’exécution de git dans l’invite de commandes.

Lorsqu’un programme s’exécute, le système d’exploitation établit trois canaux par défaut : stdin pour recevoir les entrées (généralement depuis le clavier ou la sortie d’un autre programme), stdout pour les sorties normales (en général vers le terminal ou un fichier) et stderr pour les messages d’erreur et de diagnostic (également vers le terminal, mais souvent séparés).

En bref, STDIO permet aux programmes d’interagir avec le système d’exploitation ou avec d’autres programmes. Par exemple, vous pouvez rediriger la sortie d’une commande (son stdout) vers l’entrée (stdin) d’une autre commande. De la même façon, vous pouvez rediriger stdout ou stderr d’un programme vers un fichier afin de consigner les données ou de les examiner ultérieurement. De nombreux outils en ligne de commande s’appuient largement sur STDIO pour les chaînes de traitement des données et les interactions de base.

Dans les systèmes basés sur une architecture client-serveur, comme les serveurs MCP, STDIO peut offrir une méthode simple : le serveur MCP est un processus qui reçoit des requêtes (via stdin) et les renvoie au client MCP sous forme de réponses textuelles (via stdout).

Serveurs MCP locaux utilisant STDIO

Les serveurs MCP qui communiquaient via STDIO dépendaient d’un processus en cours d’exécution. Ils étaient donc, pour la plupart, dérivés d’un serveur MCP exécuté et installé localement.

De nombreuses applications basées sur l’IA (autrement dit, des hôtes MCP) demandaient donc aux utilisateurs de fournir des définitions de serveurs MCP axées sur l’exécution de processus. Voici un exemple simple tiré d’une définition de serveur MCP du fichier mcp.json de Cursor :

// This example demonstrated an MCP server using the stdio format
// Cursor automatically runs this process for you
// This uses a Node.js server, ran with `npx`
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Déployer des serveurs MCP dans le cloud

Les serveurs MCP peuvent enfin répondre pleinement aux attentes grâce à l’adoption généralisée du transport HTTP par des applications d’IA comme Cursor et Claude Desktop, ainsi qu’à la prise en charge de l’hébergement des serveurs MCP par des infrastructures cloud telles que Vercel et Cloudflare.

À l’origine, les serveurs MCP ont introduit un transport HTTP basé sur le réseau, qui s’appuyait sur un mécanisme appelé SSE (Server-Sent Events) pour synchroniser et orchestrer les messages entre le LLM et le serveur MCP. Toutefois, comme les WebSockets, SSE nécessite des serveurs à exécution continue, difficiles à utiliser avec des plateformes de déploiement modernes comme Vercel Functions ou AWS Lambda. Une nouvelle spécification, Streamable HTTP, a donc vu le jour pour permettre le fonctionnement sans serveur des serveurs MCP via HTTP.

Les serveurs MCP basés sur HTTP sont faciles à configurer : une adresse d’hôte distant suffit, sans avoir à définir des arguments complexes en ligne de commande. Ils sont également plus faciles à partager et à utiliser, car leur configuration et leur exécution locales ne nécessitent plus d’environnement de développement particulier.

Par exemple, Cursor attend que les serveurs MCP distants utilisant HTTP soient définis simplement comme suit :  

// This example demonstrated an MCP server using the SSE format
// The user should manually setup and run the server
// This could be networked, to allow others to access it too
{
  "mcpServers": {
    "server-name": {
      "url": "http://example.com/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Architecture MCP : tout assembler

Maintenant que nous avons présenté les éléments constitutifs des MCP — clients et serveurs MCP, types de transport utilisés pour communiquer et exemples pratiques — nous pouvons mieux comprendre le modèle de déploiement et l’architecture globale des MCP.

L’architecture MCP permet de déployer les MCP localement ou à distance, ce qui ouvre la voie à de nombreuses configurations et stratégies de déploiement. Par exemple, vous pouvez exécuter localement des applications d’IA entièrement compatibles avec MCP. Prenons un exemple concret : vous installez une application locale basée sur l’IA, comme l’application de productivité Raycast ou l’IDE Cursor. Vous connectez Raycast ou Cursor à un LLM exécuté localement via Ollama. Les applications Raycast ou Cursor exécutent un client MCP local, auquel vous configurez un serveur MCP exécuté localement, comme un serveur MCP SQLite, pour parcourir les enregistrements d’une base de données stockés dans des fichiers.

L’exemple ci-dessus montre une application basée sur l’IA qui s’exécute entièrement sur un ordinateur portable, sans nécessiter d’accès au cloud ni à un réseau.

Vous pouvez aussi combiner différentes configurations. Vous pouvez déployer le serveur MCP sur une infrastructure cloud et le rendre accessible via un transport HTTP. Le client et le serveur MCP communiquent via le Model Context Protocol, conformément à la spécification, ce qui permet de les dissocier complètement.

En outre, même si la grande majorité des applications basées sur l’IA hébergent l’implémentation du client MCP au sein de l’application elle-même, ce n’est pas une obligation : le client MCP peut également être dissocié de l’application d’IA.

MCP et appels de fonctions : pourquoi les MCP ne sont pas de simples wrappers d’API

Beaucoup qualifient les MCP de « simples wrappers d’API REST ». Cette vision est réductrice et à courte vue. Voyons pourquoi les MCP sont plus nuancés et parfaitement adaptés aux applications d’IA.

Avant d’aborder la confusion entre MCP et API REST à un niveau plus général, certains développeurs voudront mieux comprendre en quoi et pourquoi les MCP diffèrent des appels de fonctions d’origine, rendus possibles par OpenAI et ses SDK depuis 2023.

MCP et appels de fonctions

Avec les appels de fonctions, l’application basée sur l’IA devait implémenter chaque outil. Imaginez qu’une application d’IA comme Cursor doive implémenter un outil git permettant de « répertorier les branches distantes ». Une application comme Cursor pourrait choisir d’exécuter la commande git ls-remote, tandis qu’une autre, comme Windsurf, pourrait s’appuyer sur l’API GitHub. Ces deux approches offriraient une expérience développeur totalement différente, une gestion des erreurs différente, etc.

Ce manque d’organisation et de standardisation des fonctionnalités d’appel de fonctions a entraîné une duplication inutile du code et de la logique entre les différentes applications basées sur l’IA.

En résumé, voici les avantages qui distinguent les MCP des appels de fonctions traditionnels :

• Dans les SDK d’appel de fonctions, les outils étaient étroitement liés à l’intégration du LLM. Par conséquent :

• Il n’y a pas de mise à l’échelle prête à l’emploi. Avec les MCP, en revanche, vous pouvez déployer le serveur MCP et le mettre à l’échelle indépendamment de vos applications d’IA.

• La séparation des responsabilités entre l’implémentation d’un outil dans l’application d’IA et le reste de la logique de l’application est inexistante. Les deux ne font qu’un. Techniquement, vous pouvez créer des wrappers et des interfaces entre eux et les exposer via JSON-RPC, mais vous ne feriez alors que recréer les MCP. C’est précisément ce que les MCP fournissent, et bien plus encore.

• Il n’existe pas de moyen simple pour permettre aux utilisateurs qui consomment ou exploitent l’intégration du LLM d’étendre les outils. Comme l’implémentation des appels de fonctions fait partie intégrante de l’intégration du LLM, elle y est étroitement liée. Permettre l’ajout d’outils tiers reviendrait à réinventer les MCP.

La nature étroitement liée des appels de fonctions traditionnels, initialement introduits pour définir des outils, soulève également des problèmes de sécurité. Les opérations potentiellement dangereuses et sensibles que les outils doivent implémenter font partie de l’application d’IA qui les fournit. Une convention de codage non sécurisée ou une pratique de sécurité défaillante au niveau de l’outil pourrait compromettre l’ensemble de l’application d’IA.

Au-delà de la standardisation des spécifications qu’ils visent à apporter, les MCP introduisent une forme d’IoC (inversion de contrôle) qui dissocie les appels de fonctions et les capacités étendues pour les répartir entre différents services.

Les MCP ne sont-ils que des wrappers d’API REST ?

Réduire les MCP à de simples API REST traditionnelles, c’est ignorer les complexités liées à la création d’applications d’IA. De nombreuses propriétés des MCP sont similaires à celles des API REST. Les MCP communiquent via HTTP. Le protocole repose sur le format JSON-RPC. Il suit un modèle client-serveur. Et, comme les applications Web traditionnelles, il sert des navigateurs côté client et d’autres clients qui consomment des API.

Cependant, les MCP sont souvent utilisés à un niveau de granularité différent de celui des API REST classiques et nécessitent des capacités natives de l’IA que les API REST ne possèdent pas :

1. Les MCP répondent à des cas d’usage, pas à des opérations : autrement dit, voyez les MCP comme des facilitateurs de cas d’usage conçus pour résoudre un problème. Les points de terminaison d’API REST représentent le plus souvent de manière granulaire des entités et leur univers. Les MCP finissent par créer une matrice TxE (outil x points de terminaison), dans laquelle une seule implémentation d’outil exposée peut correspondre à plusieurs points de terminaison d’API REST. Par exemple, un serveur MCP qui expose un outil « get_open_issues » pour un dépôt Git devra probablement appeler plusieurs points de terminaison d’API REST : 1) répertorier tous les problèmes ouverts ; 2) pour chaque identifiant de référence d’un problème ouvert, récupérer toutes ses données et métadonnées. Les serveurs MCP sont souvent moins granulaires qu’une API RESTful.

2. Les MCP déclenchent des actions au-delà du web : il est facile de penser que tout est connecté au web, mais de nombreuses démonstrations impressionnantes de MCP portent sur des interactions qui ne relèvent ni du web ni des API REST. Par exemple, la démonstration virale de Blender MCP, qui permettait à l’application d’IA Claude de créer des scènes 3D complètes, reposait sur l’API Python de Blender. Répondre au cas d’usage de Blender à l’aide d’une API native au langage permet au LLM de mobiliser ses capacités de raisonnement en programmation pour obtenir de meilleurs résultats.

3. Les MCP exploitent nativement les LLM, contrairement aux API REST : la spécification MCP définit une fonctionnalité appelée échantillonnage, qui permet au serveur MCP d’interroger le LLM pour une opération donnée. Voici un exemple concret, possible avec les MCP mais pas avec les API existantes, qui reprend l’exemple précédent de Git : « récupérer les problèmes ouverts ayant le plus fort impact sur la sécurité ». Comment une API REST pourrait-elle répondre à l’exigence « ayant le plus fort impact sur la sécurité » ? S’il n’existe aucun filtre ou libellé sécurité-de ce type pour les problèmes, il est impossible d’obtenir les informations pertinentes. Avec les MCP, en revanche, l’implémentation d’un outil récupère la liste des problèmes ouverts, envoie une requête d’échantillonnage au LLM avec une invite telle que « parmi les problèmes ouverts suivants, renvoie une liste classée par ordre décroissant d’impact sur la sécurité au format JSON », puis le LLM fait ce qu’il sait faire de mieux et fournit un résultat fondé sur une analyse approfondie. Le MCP a fait appel à un LLM dans le cadre de son traitement, une fonctionnalité qui n’est pas disponible nativement dans une implémentation d’API REST existante. L’échantillonnage et la communication bidirectionnelle avec les LLM permettent bien plus que de simples analyses de similarité ou de sentiment : ils tirent également parti des capacités multimodèles des LLM et permettent des améliorations itératives.

Enjeux de sécurité liés aux MCP

Les MCP soulèvent également des enjeux de sécurité. Du fait de leur omniprésence, les serveurs MCP suscitent des préoccupations liées à la sécurité de la chaîne d’approvisionnement, notamment :

1. Serveurs MCP malveillants : comment s’assurer qu’un serveur MCP est fiable ? Que se passe-t-il si le serveur MCP exécute secrètement du code et exfiltre des informations sensibles de votre environnement local ou déployé ? Le serveur MCP pourrait-il héberger une porte dérobée ? Comment évaluer ces risques de sécurité ?

2. Serveurs MCP vulnérables : les serveurs MCP peuvent fonctionner comme prévu sans pour autant être exempts de vulnérabilités de sécurité et de défauts de codage. Une pratique de codage non sécurisée dans un serveur MCP peut être exploitée par ses utilisateurs et entraîner une compromission de la sécurité ou une violation de données.

Ce ne sont là que quelques-uns des enjeux de sécurité liés aux MCP. Les risques de sécurité associés aux MCP et à l’IA s’étendent également aux vulnérabilités de sécurité concrètes liées au vibe coding, à la manière dont les LLM peuvent être détournés par injection de prompt, ainsi qu’aux risques de sécurité du code généré avec ChatGPT.

Tous ces enjeux de sécurité liés à l’IA, et bien d’autres, justifient la mise en place de garde-fous de sécurité pour l’IA et la sécurisation du code généré par l’IA, que Snyk contribue à atténuer.