Comprendre le Model Context Protocol (MCP) : connecter les LLMs à vos données et outils

Introduction

Depuis l’apparition de ChatGPT en 2022, les grands modèles de langage (LLMs) se sont progressivement inscrits dans notre quotidien. Pourtant, malgré leurs capacités en matière de conversation et de raisonnement, ces modèles restent aujourd’hui isolés, déconnectés des données en temps réel et des services externes pourtant essentiels à de nombreuses applications. Une question demeure donc centrale : comment connecter efficacement ces intelligences artificielles à notre monde hyperconnecté ?

Plusieurs approches tentent déjà de répondre à cette problématique : du fine-tuning au Retrieval-Augmented Generation (RAG), en passant par les systèmes agentiques. Toutefois, ces méthodes présentent encore des limites importantes : coût élevé, manque de flexibilité, et surtout, des intégrations souvent complexes et spécifiques à chaque cas d’usage.

Face à ces difficultés persistantes, un nouveau standard a émergé : le Model Context Protocol (MCP). Inspiré du Language Server Protocol (LSP), MCP propose une solution ouverte et universelle permettant aux LLMs d’interagir simplement avec des ressources externes très variées (APIs, bases de données, fichiers locaux…) grâce à une architecture claire et modulaire.

Pour mieux saisir le potentiel, nous suivrons Pierre, passionné de parapente, qui rêve d’un assistant pour planifier ses sorties en montagne en combinant intelligemment des informations météorologiques, topographiques et aéronautiques.

À travers l’exemple de Pierre, nous découvrirons les concepts clés du MCP, ses forces et ses limites, puis nous détaillerons pourquoi ce protocole pourrait devenir le nouveau standard incontournable pour connecter durablement les LLMs à notre monde.

Nous conclurons sur les principaux enjeux autour du MCP : la sécurité, la nécessité de mécanismes robustes d’authentification et d’autorisation, ainsi que l’importance de former explicitement les modèles à utiliser ce protocole. Nous verrons aussi comment l’ouverture du MCP favorise son adoption rapide par la communauté et sa pérennité à long terme, en posant les bases d’une véritable interopérabilité entre tous les acteurs du domaine.

Ainsi, entre avancées prometteuses et défis majeurs, le MCP constitue un moment pivot dans l’évolution de l’intelligence artificielle : il pourrait bien être ce standard universel que toute la communauté attendait pour franchir définitivement le pas vers un monde où les LLMs sont pleinement intégrés à notre quotidien.

Les LLMs isolés et déconnectés de notre monde

Les LLMs, bien qu’entraînés sur des ensembles de données immenses, n’ont pas réponses à tout et n’ont surtout pas accès aux données les plus actuelles ou à celles qui ne faisaient pas partie du set d'entraînement. Ils sont isolés vis-à-vis de nombreuses sources d'information (les plus récentes présentes sur Internet, celles internes à une entreprise …). Un LLM ne doit pas être utilisé comme une base de connaissance mais comme un moteur d'inférence. Prenons l’exemple de Pierre, un passionné de sortie en montagne qui désire planifier en utilisant un LLM sa sortie de la journée. S’il demande purement et simplement à un LLM quelle est la météo aujourd’hui, ce dernier ne saurait pas lui répondre. L’enjeu a donc été de trouver des solutions permettant de donner accès aux LLMs à ces données dont ils n’avaient, de base, pas accès et pas connaissance.

On pourrait penser que la solution la plus évidente pour adresser cette problématique serait de donner dans le prompt toutes les informations qui pourraient être utiles au LLM, mais cette technique, au vu de la fenêtre de contexte limitée des premiers grands modèles de langage et surtout au vu des coûts qui pourraient être engendrés par une telle pratique, a très vite été écartée.

La nécessité d’un standard ?

Les différentes approches qui ont émergé pour répondre à la problématique des LLMs (fine-tuning, RAG et agentique)

Pour pallier au problème d’isolation des LLMs vis-à-vis des sources de données, de nombreuses approches regroupant pour chacune des outils et des frameworks toujours plus performants ont été proposées.

La première approche qui pourrait être utilisée pour donner accès à un LLM à de nouvelles données est le fine-tuning d’un modèle existant. Elle consiste à entraîner un modèle de langage sur des données spécifiques additionnelles pour qu’il internalise de nouvelles connaissances ou aptitudes. Nous n’allons pas nous attarder sur cette méthode, car elle peut se révéler très coûteuse dans certains cas et demande de ré-entraîner ou ré-affiner le modèle si l’on veut le garder à jour des nouvelles données. De plus, les données sur lesquelles le modèle a été fine-tuné peuvent évoluer et cela demanderait donc de ré-entraîner encore une fois le modèle pour qu’il reste à jour. En d’autres termes, le fine-tuning reste très peu utilisé.

La seconde approche que l’on pourrait citer est la technique RAG, qui est la première à avoir vu le jour. Elle consiste à apporter un contexte approprié au LLM provenant d’une base de données externe en fonction de la demande de l’utilisateur. La base de données qui est dans la majorité des cas une base de donnée vectorielle, est interrogée par ce qu’on appelle un retriever. Ce dernier a pour but de ramener les documents de la base les plus pertinents en fonction de la demande de l’utilisateur pour ensuite créer le contexte qui sera envoyé au LLM.

Fig 1 : Schéma représentant le fonctionnement de la technique RAG

Cette technique est extrêmement utilisée dans de nombreuses entreprises, car elle permet de mettre en place des agents conversationnels beaucoup plus performants que les “systèmes d’experts” anciennement proposés. Le RAG présente cependant un angle mort notable. Le processus n’est pas réellement interactif ni standardisé : chaque implémentation RAG a sa logique qui dépend notamment du use case et de la base de données utilisée (format et structure des données, choix de la base, besoins métiers …).

Revenons-en à Pierre : s’il veut implémenter un RAG pour accéder à des données météorologiques présentées dans une base de données vectorielles, il devra s’adapter aux formats de ces dernières ainsi qu’à la base utilisée. Cela différera donc d’un autre use case ou les données et la base pourraient être différentes. De plus, le lien entre le LLM et la source de données est hard-codé et le LLM ne peut donc pas choisir s’il a besoin ou non d’informations supplémentaires.

Enfin, la dernière approche est l'utilisation de systèmes agentiques. Il y a encore quelque temps, on aurait pu dire que cette approche n'était pas assez mature mais on voit désormais se développer de nombreux projets l’utilisant et certains de ces projets arrivent même à l’étape du déploiement en production bien qu’ils proposent des problématiques certaines. Cette approche place un LLM dans un environnement avec lequel il peut interagir grâce à des tools. Un tool est une fonction ou un service externe que l'agent peut appeler pour obtenir des informations ou effectuer des actions spécifiques.

Le tool calling aussi connu sous le nom de function calling, est le processus par lequel l'agent identifie le besoin d'utiliser un outil, sélectionne l'outil approprié, exécute la fonction correspondante et intègre le résultat dans sa réponse. Les tools peuvent donc intégrer des appels APIs, de la recherche Internet ou bien de requêtes à une base de données spécifique pour récupérer des informations nécessaires à la réalisation d’une tâche.

On pourrait imaginer un LLM à qui on donne la possibilité de réaliser une recherche Internet pour récupérer les dernières informations en lien avec la météo. Cela serait donc un agent, car le LLM peut interagir avec Internet en réalisant une recherche et en récupérant des données. Cette approche (agentique) a et continue d’être poussée par de nombreux outils et frameworks qui simplifient la création d’agents et de systèmes multi-agents (un système qui permet de mettre en relation différents agents qui peuvent interagir entre eux dans le but de réaliser une tâche spécifique).

Il y a peu, un protocole appelé Agent2Agent a même été proposé par Google pour standardiser la communication entre différents agents (Google, 2025) .

Voici des outils qui permettent cela :

• Langchain avec Langraph,
• PydanticAI,
• Smolagents,
• Composio,
• Microsoft avec Autogen,
• PraisonAI,
• …

Cette approche, bien que plus complète que l’approche RAG, possède toujours des limites certaines. Elle nécessite de développer manuellement et pour chaque outil une logique spécifique afin de permettre au modèle d’y accéder. Elle est donc chronophage à implémenter et peu scalable – il faut répéter le travail pour chaque nouvel outil​. Le « standard » de LangChain par exemple s'applique au niveau du langage de programmation, mais du point de vue du modèle, rien ne lui permettait de découvrir dynamiquement un outil inconnu en cours d’exécution – il fallait l’avoir codé explicitement à l’avance​.

Les difficultés persistantes pour connecter les LLMs à notre monde

Les différentes approches citées précédemment, bien qu’utiles dans de nombreux cas, laissent de nombreux problèmes non adressés.

On pourrait tout d’abord penser au fait qu’en l’absence de protocole universel, chaque nouvelle source de données ou outil doivent être raccordés via une intégration ad hoc. Chaque connecteur est développé sur mesure, ce qui multiplie les efforts et rend les systèmes connectés difficiles à faire évoluer​. Lorsque l’on veut utiliser un outil pour donner à un LLM un moyen d’interagir avec son environnement, on doit nous-même le créer. On ne peut pas ré-utiliser un outil déjà implémenté par une autre personne, car les tools sont spécifiques à un projet et doivent donc être conçus en fonction des contraintes de ce dernier. On peut donc voir différents projets qui recréent des tools similaires pour réaliser une tâche identique mais avec une implémentation différente à chaque fois car les spécificités de leurs projets varient.

On pourrait prendre l'exemple d’une API quelconque telle que celle de Google Drive. De nombreux projets intégrant des LLMs utilisent cette API et doivent, pour chacun d’entre eux, recréer le lien qui permet au LLM d'interagir avec cette API. Si un protocole universel existait, cela permettrait à l’API de Google Drive d’être directement accessible par tous les projets respectant les normes et les conventions de ce même protocole sans qu’ils aient besoin de recréer le lien / le code permettant au LLM d’interagir avec Google Drive.

Faute de langage commun, les modèles ne peuvent pas communiquer de manière fluide avec divers services ou applications externes. Chaque plateforme impose sa méthode, aboutissant à des intégrations fragmentées peu fiables et peu scalables. Cet obstacle d’interopérabilité entre les systèmes d’IA et les outils figure parmi les freins majeurs de ces approches au déploiement avancé de l’IA.

Pour pallier ces problématiques, un standard universel appelé Model Context Protocol (MCP) et proposé par Anthropic émerge et permet aux LLMs de se connecter aux données et aux services. Ce protocole a pour vocation de se différencier des approches déjà existantes (fine-tuning, RAG, agentique).

Model Context Protocol

Pour introduire notre propos et servir de fil rouge, parlons de Pierre.

Pierre se demande si demain, il pourra pratiquer son activité préférée : monter en haut d’une montagne en courant et redescendre en parapente (Hike & Fly).

Aujourd’hui, il passe du temps à consulter plusieurs applications et sites web pour rassembler les informations qui lui permettent d’assurer sa sécurité. Il aimerait automatiser ce processus pour obtenir un résumé intelligent et optimisé en une seule requête.

Quelques jours auparavant, Pierre a entendu parler de Model Context Protocol (MCP). Il se demande si sa problématique ne pourrait pas servir de cas d’usage pour se familiariser avec ce protocole. En combinant des ressources variées, il pourrait créer un assistant sur mesure qui lui permettrait de :

• Gagner du temps en évitant les recherches manuelles.
• Optimiser ses décisions de vol avec des informations précises.
• Éviter les mauvaises surprises grâce à une analyse en temps réel des conditions.

Découvrons avec lui ce qu’est MCP !

Les concepts clés

Dans cette partie, nous parlerons des trois principaux concepts qui composent MCP.

1. L’hôte qui héberge un LLM et amène une couche d’intelligence en étant capable de choisir quel outil utiliser.
2. Le client MCP fait le lien entre l’hôte et le serveur en exécutant les requêtes de l’un et récupérant les outils de l’autre.
3. Le serveur qui implémente des tools et des resources qui permettront de répondre à une problématique.

Fig 2 : Schèma métaphorique d'un projet MCP

Pour commencer son projet, Pierre se tourne vers un LLM avec lequel il espère trouver la réponse à son questionnement.

Pour discuter avec un modèle, il a besoin d’utiliser une interface telle que Claude Desktop, Cursor ou Cline. Ce sont des outils qui intègrent un ou plusieurs LLMs et les mettent à disposition de leurs utilisateurs. Pierre adore l’interface de Claude Desktop, d’autant plus que son oncle porte le même prénom.

Après quelques prompts bien placés, Pierre arrive vite à la conclusion que les réponses de son interface préférée ne lui conviennent pas ; elles ne sont pas à jour et manquent de précision. En effet, et comme on l’a vu précédemment, les LLMs seuls sont déconnectés de notre et ne peuvent interagir avec ce dernier. C’est là que MCP rentre en action.

Pour utiliser MCP, Pierre va devoir mettre les mains dans le cambouis ; il doit explorer les outils qu’il veut mettre à la disposition de Claude. Par exemple, pour analyser son terrain de jeu, il peut se baser sur Strava, sur Météo France et sur SkiTour. Il doit explorer les différentes APIs de ces outils pour se projeter sur leurs utilisations.

Après avoir compris le fonctionnement de ces APIs, il pourra les rassembler dans un serveur, qu’il n’aura qu'à structurer en suivant le protocole MCP. Ensuite, il devra connecter un client pour faire interagir son LLM avec son serveur (le LLM aura ainsi accès aux tools). Enfin, il n’aura qu'à s'interfacer dans Claude Desktop pour que celui-ci joue le rôle d’hôte.

Nous allons étapes par étapes décortiquer ces trois parties afin de mieux comprendre l’interaction qu’elles ont les unes avec les autres.

Hôte

Nous en parlions quelques paragraphes au-dessus, plusieurs interfaces peuvent jouer le rôle d'hôte.

Pierre aurait pu utiliser et coder son hôte en python, mais il aurait dû s'occuper de l’orchestration des échanges. Certains outils open source font leur apparition pour nous aider sur cette partie comme jiki ou mcp-use. Si le besoin de transparence n’est pas une priorité, des outils comme Claude Desktop ou bien Cursor existent et font l’abstraction nécessaire.

Fig 3 : Quelques hôtes à notre disposition

Pour connecter son host au serveur que l’on souhaite utiliser, il suffit de lui fournir un fichier de configuration. Voici un exemple que Pierre a utilisé pour ce projet. Grâce à ces quelques lignes, Claude se retrouve augmenté de nouvelles capacités.

Fig 4 : Exemple de configuration pour Claude Desktop

Le fichier JSON ci-dessus définit un serveur MCP nommé "hike_and_fly". La commande est exécutée grâce à uv. Les arguments permettent de spécifier le chemin vers le serveur puis le nom du fichier en question.

Pierre pourra continuer à lui demander des informations « classiques » que le modèle lui restituera en se basant sur des recherches internet ou sur les connaissances contenues dans son jeu d'entraînement. Mais cette configuration va aussi permettre à Claude de jouer avec d’autres outils que Pierre aura lui-même définis. Ces outils se définissent dans le serveur MCP dont nous parlerons plus tard.

Client

Dans la documentation de MCP, Pierre découvre qu’il peut créer son propre client. L’interface de ce client lui permet de visualiser les outils qu’il a créés et de les appeler pour vérifier qu’ils fonctionnent bien. Par contre, il se rend vite compte que ce client n’est pas fait pour orchestrer ces outils. Il manque une couche qu’amènent les hôtes, une couche d'orchestration qui permet aux LLMs de savoir quel outil choisir et dans quel ordre.

Ainsi, le client devient l’intermédiaire entre l’hôte et le serveur. Il s’occupe de maintenir une connexion 1:1 avec chaque serveur à sa disposition.

Pour standardiser ces échanges, deux couches ont été implémentées :

• Une couche de protocole qui permet de gérer la vie globale d’une session. Cette couche implémente quelques fonctions permettant de lister les outils disponibles dans le serveur et de faire des appels sur chacun d’eux.
• Une couche de transport assurant la communication entre le client et le serveur. Deux mécanismes sont mis à disposition :
  • Stdio idéal pour le développement de serveurs locaux.
  • HTTP avec SSE fait pour un serveur déployé à distance.

De nombreux hôtes ont abstraits le client directement dans leur code afin de facilement interagir avec des serveurs MCP.

Fig 5 : Les différentes types de clients

Roots

Les roots jouent un rôle fondamental dans la gestion du contexte des requêtes et l'organisation des interactions entre le client, les serveurs et les outils. Ils permettent d’assurer une structuration claire des échanges et d’optimiser l’accès aux ressources et aux outils du serveur. Ce sont les clients qui déclarent les roots pour définir les frontières de jeu du serveur.

Voici quelques cas d’usage afin d’illustrer notre propos:

Cas 1 : Organisation d’un serveur multi-domaines

Un serveur MCP peut gérer plusieurs applications ou thématiques différentes. Les roots permettent de segmenter les domaines et d’éviter toute confusion entre les contextes.

Exemple :

• mcp://serveur-meteo/roots/previsions → Gestion des prévisions météorologiques.
  
• mcp://serveur-meteo/roots/routing → Vérification des zones aériennes restreintes.
  

Un client MCP peut alors choisir le root pertinent en fonction du type d’informations ou d’actions recherchées.

Fig 6 : Illustration des roots

Cas 2 : Sécurisation et gestion des accès

Les roots facilitent la mise en place de restrictions et de permissions spécifiques. Un serveur MCP peut définir des règles d’accès par root, restreignant ainsi l’utilisation de certains outils ou ressources.

Exemple :

• mcp://serveur/roots/admin → Accessible uniquement aux administrateurs.
  
• mcp://serveur/roots/public → Contient des ressources ouvertes à tous.

Serveur

Un serveur MCP joue un rôle essentiel dans l’architecture du protocole. Il est le point d’accès aux ressources, outils et services nécessaires à l’exécution des requêtes du client. Il peut être exécuté localement pour un développement rapide ou être déployé sur une infrastructure distante afin de le rendre disponible à tous.

Création et exécution d’un serveur MCP

En une dizaine de lignes de code, la partie exposition des outils du serveur MCP est prête. Les serveurs peuvent être créés dans différents langages de programmation, tant qu'ils respectent le protocole standard. Les langages disponibles sont exhaustifs, ils évoluent en permanence au grès des PRs de la communauté. Les plus en mode en ce moment sont TypeScript, Python, Kotlin, Java, Rust, C# ou encore Go.

Un serveur MCP est conçu pour :

• Exposer des resources : fichiers, bases de données, API, logs, etc.
• Fournir des tools permettant d’exécuter des actions spécifiques.
• Déclarer des prompts qui servent de template pour les LLMs.

Le serveur MCP est le cœur du système : il agrège, organise et renvoie les données nécessaires au client.

Les outils à notre disposition

Pour revenir à Pierre, afin de construire son serveur MCP pour le conseiller dans ces sorties en montagne, il doit récupérer les informations suivantes :

• Les conditions météo (vent, température, précipitations)
• Les restrictions aériennes (NOTAMs)
• Les traces GPS des vols précédents
• L’accessibilité des sites de décollage et d’atterrissage (taux d’enneigement)

Fig 7 : Illustration d’un projet MCP global

Resources

Une resource est le composant primitif d’un serveur MCP. Il permet de mettre à disposition une source de données aux clients. Pour faire écho au projet de Pierre, voici une liste des formats de données que le serveur peut exposer :

• Des fichiers binaires, cela pourrait être des données GPS stockées sur l’ordinateur de Pierre qu’il a extrait de sa montre.
• Des images stockées sur ton téléphone.
• Le contenu d’une base de données permettant d’extraire les dates et parcours des courses passées.
• Les réponses d’APIs externes comme MétéoFrance ou SkiTour qui permet de connaître l’enneigement d’un massif.
• Des applications SaaS qui fournissent des accès et qui peuvent permettre d’exposer la gestion de la performance ou le suivi de l’effort.
  

Chaque resource est identifiée par une URI standardisée sous la forme : [protocol]://[host]/[path]

Tools

Les tools permettent au serveur et par extension aux LLMs derrière le client d’interagir avec des systèmes externes, faire des calculs et prendre des actions. En pensant en termes API les resources seraient des GETs et les tools des POSTs.

Pierre pourrait ainsi créer un tool qui, de son propre chef, lui crée un itinéraire dans son outil de routage préféré. Cet itinéraire serait créé en fonction des informations récupérées grâce aux resources.

Fig 8 : Pierre joue avec son serveur

Grâce à ces tools, son serveur MCP ne se contente pas de fournir des données brutes : il l’aide activement à prendre des décisions.

Prompts

Les prompts permettent au serveur de définir des modèles réutilisables que le client peut facilement rendre accessible à l’utilisateur ou aux LLMs qu’il utilise.

La structure de ces prompts permettent de définir :

• dynamiquement les arguments attendus par les outils sous-jacents.
• des contextes plus détaillés aux ressources disponibles.
• l'enchaînement d’interactions entre des ressources.

Pour le projet de Pierre, un prompt pourrait ressembler à ce genre de choses et guider l’host dans le meilleur enchaînement possible des outils mis à sa disposition.

Fig 9 : Exemple de prompt pour le projet de Pierre

Sampling

Le sampling permet au client MCP de compléter dynamiquement une requête. Il aide à affiner les résultats en fonction du contexte et améliore la flexibilité du système en intégrant des ajustements en temps réel.

Dans le cadre du projet de Pierre, cela reviendrait à laisser vacant la ville de départ de son aventure dans le prompt pour que le LLM complète lui-même le plan de vol au fur et à mesure de la consultation des outils. En s’aidant des outils lui fournissant des informations sur les conditions météorologiques ou le terrain rencontré, il arrivera mieux à qualifier qu’il faut partir d'Annecy plutôt que du Vercors.

Exemple :

• User : Demain, j'irai faire du Hike and Fly à ...
• System : Demain, j'irai faire du Hike and Fly à Annecy me semble être la meilleure option vu les conditions météorologiques !

De la même manière que les prompts le sampling amène des limitations du point de vue de la sécurité dont il faut en être conscient si l’on expose son serveur au grand public.

Limites et sécurité autour des serveurs

Du point de vue sécurité, il est essentiel de parer à toutes éventualités.

Ce sont des règles simples de sécurité, mais qui ont le mérite d’être rappelées au vu des changements rapides du Model Context Protocol. Il faut penser à bien valider les arguments attendus par le serveur (grâce à Pydantic par exemple), à limiter le nombre de requêtes, à contrer les SQL injections et les prompts injections ainsi qu'à mettre en place un système d’authentification.

Enfin, le modèle peut produire des réponses erronées, inappropriées ou potentiellement nuisibles. Un filtrage des réponses et une validation des contenus générés permettent d’assurer leur conformité et d’éviter des erreurs critiques.

De nombreux serveurs sont listés dans un répertoire hébergé par Anthropic mais aucune garantie de sécurité n’est fournie. Rien ne dit qu’un de ces liens ne contient pas du code malveillant qui, sous prétexte d’une nouvelle capacité offerte à son LLM préféré, parcourt tous les répertoires de votre ordinateur pour en récupérer chaque clé API utilisable.

Pour appuyer ce constat, n’importe qui peut faire une MR sur ce répertoire pour ajouter son propre lien.

Fig 10 : Screenshot des PRs sur le repository MCP-Server (Anthropic, 2025)

L’agnosticité

L’un des atouts majeurs de MCP est son indépendance vis-à-vis des plateformes et des modèles utilisés. MCP ne favorise aucune entreprise ni aucun modèle spécifique, offrant ainsi une flexibilité totale aux développeurs et utilisateurs.

Que l’on utilise Claude, GPT, Mistral ou tout autre modèle, MCP ne fait pas de distinction. Il fournit les outils nécessaires pour que n’importe quel LLM puisse s’interfacer avec des ressources externes. La force de l’open source permet d’imaginer une meilleure adoption, MCP n’est pas restreinte à un écosystème fermé.

Un copilote MCP pour le Hike & Fly

Grâce à son serveur MCP, Pierre a un copilote virtuel, lui permettant de se concentrer sur son vol plutôt que sur la collecte d’informations. Désormais, avant chaque sortie, il n’a qu’à poser une simple question à Claude Desktop :

"Quel est le meilleur jour pour voler cette semaine dans la région de Grenoble ?"

Et en quelques secondes, il aura une réponse claire et fiable. Prêt à décoller !

Nous avons mis à disposition, en open source, le code qui a permis de créer ce serveur. Celui-ci peut être lancé sur Claude Desktop ou via Jiki, qui a été intégré au repository directement.

Fig 11 : Récapitulatif du projet MCP de Pierre

MCP : Le futur standard d’interaction pour les LLMs ?

MCP constitue une avancée dans l'écosystème des modèles de langage (LLMs), en proposant une standardisation de la manière dont ces modèles interagissent avec des sources de données et services externes. Les serveurs MCP offrent ainsi des fonctionnalités étendues dans de nombreux domaines, allant de l'accès aux fichiers locaux à la recherche web, en passant par les opérations sur bases de données.

MCP s’inspire du Language Server Protocol (LSP)

Le MCP est directement inspiré du Language Server Protocol (LSP), un protocole créé par Microsoft pour standardiser la communication entre éditeurs de code et outils de langage tels que les serveurs d'analyse de code. LSP repose sur l'échange de messages via JSON RPC, permettant ainsi une intégration simple, flexible et interopérable entre différents outils et serveurs. En reprenant ces fondations, le MCP bénéficie de cette architecture, facilitant notamment son intégration rapide avec des éditeurs de code modernes comme Cursor / Windsurf / Cline. Cette similarité structurelle simplifie considérablement son adoption par les développeurs, accélérant ainsi son déploiement et son intégration dans divers environnements de développement.

Fig 12 - Why LSP ?

L'importance du MCP réside dans son potentiel à apporter une abstraction analogue à celle créée par LSP pour les outils d'intelligence artificielle. Alors que LSP a changé les outils de programmation en permettant aux équipes spécialisées dans les langages de programmation d'offrir de la cohérence dans divers environnements de développement, MCP vise à fournir une abstraction entre les agents et leurs environnements informatiques. Toutefois, cette abstraction est moins complexe que celle de LSP, car elle cible principalement des interactions API plutôt que l'intégration profonde d'expertise spécialisée.

Par exemple, pour faciliter l’adoption de cette abstraction, une bibliothèque nommée fastapi_mcp permet de transformer un endpoint FastAPI en serveur MCP.

Forces, limites et enjeux de sécurité lié au MCP

Des risques critiques existent avec les implémentations actuelles du MCP, héritant des faiblesses de LSP. Une des lacunes majeures de LSP concernait l'absence d'un système standardisé de packaging sécurisé. Visual Studio Code, produit phare ayant favorisé l'adoption de LSP, proposait sa propre méthode d'extension qui n'était pas facilement transférable à d'autres plateformes, ce qui présentait des vulnérabilités liées à la sécurité du processus de distribution et d’intégration des extensions.

Le risque est encore plus important avec MCP, du fait de son potentiel étendu d'accès et d'intégration aux systèmes critiques. Sans une solution robuste de packaging, comprenant des attestations sécurisées et des signatures numériques, les organisations adoptant MCP à partir de sources tierces sont exposées à des risques majeurs de sécurité.

De plus, LSP a été conçu pour fonctionner dans des environnements mono-utilisateur sans prise en charge native du multi-tenant, une simplification utile en desktop mais problématique dans les environnements cloud. Cette absence constitue un défi majeur pour MCP, dont les implémentations devront fréquemment gérer des environnements multi-tenants exigeant des mécanismes solides d'authentification et d'autorisation.

Sans résoudre ces enjeux critiques liés au packaging, à la sécurité des processus de distribution et d’intégration, au multi-tenancy, à l'authentification et à l'autorisation, la valeur et la viabilité globales du MCP continueront d'être remises en question.

Face à ces enjeux, la force de l'écosystème va faire émerger une solution cohérente et suffisamment rassurante en termes de sécurité et d’observabilité. À mesure que l'écosystème des LLMs continue d'évoluer, on peut anticiper une certaine convergence vers des implémentations homogènes et sécurisées.

Est-ce que MCP est un standard de plus ?

Fig 13 - Standards

Comme l’illustre xkcd ci-dessus, chaque tentative de créer un standard universel présente le risque de simplement aboutir à un standard supplémentaire. MCP pourrait ainsi devenir ce énième standard transitoire, non pas en raison d'un manque de pertinence technique, mais plutôt à cause de la fragmentation d'un écosystème aussi jeune et concurrentiel que celui des LLMs. L’histoire nous a démontré que chaque acteur majeur aspire à imposer ses propres pratiques et standards afin de consolider sa position dominante.

Le véritable enjeu derrière MCP dépasse largement la simple adoption d'un nouveau protocole technique : il marque l'entrée d'Anthropic dans une position de pouvoir typique des grandes entreprises technologiques telles qu'Apple ou Google. Anthropic contrôle directement la technologie fondamentale ; les modèles de langage (LLMs) eux-mêmes, sur lesquels repose toute application utilisant l'IA. À l'image d'Apple qui, en maîtrisant son écosystème, dicte les règles d'utilisation de ses produits, Anthropic est aujourd'hui en mesure d'imposer ou d'influencer fortement les standards d'interaction et d'intégration pour les développeurs d'IA.

En définissant MCP, Anthropic ne se contente pas d'introduire une proposition technique : l’entreprise affirme son rôle de leader capable de structurer l'écosystème selon sa vision stratégique. Cette démarche reflète précisément celle des grandes entreprises technologiques lorsqu'elles atteignent un seuil critique où leur influence peut orienter tout un secteur industriel. Anthropic permet également à la communauté de pleinement s'en emparer, facilitant ainsi une adoption large et rapide tout en offrant une base solide que chacun peut enrichir et surtout sur laquelle tout le monde peut construire.

Google semble d'ailleurs suivre les pas d'Anthropic avec son initiative complémentaire, A2A (« Agent-to-Agent »), visant l'interopérabilité et la structuration de l'écosystème des agents. Cette initiative renforce la dynamique impulsée par MCP, démontrant un consensus croissant parmi les acteurs majeurs sur la nécessité d'une standardisation.

MCP est ainsi à un moment pivot dans l'évolution de l'intelligence artificielle : l'avènement de géants technologiques capables de modeler activement les règles du jeu, tout en sécurisant leur position au cœur même des systèmes utilisés par l'ensemble du marché.

Anthropic tire également avantage de sa stratégie open source. En rendant ouvert son outil d'orchestration MCP, l’entreprise bloque la possibilité à ses concurrents de proposer des alternatives "premium" exclusives. Le modèle open source accélère l'adoption du protocole, tandis que le choix de JavaScript pour le développement du serveur réduit les barrières d'entrée, favorisant ainsi une participation large et dynamique à l'évolution du protocole.

Enfin, l'approbation et le soutien apportés par les autres leaders du secteur des LLMs, tels qu'OpenAI et Google, renforcent la crédibilité de MCP, positionnant ce protocole comme un choix incontournable pour l'avenir de l'écosystème technologique. MCP semble être fait pour durer. À l'image d'autres protocoles qui ont connu plusieurs versions successives, tels que HTTP avant HTTPS ou les modèles de déploiement avant Kubernetes, il est certain que l'évolution du MCP n'est pas encore résolue. Toutefois, il représente dès aujourd'hui un point de départ valide et prometteur.

Fig. 14 - star-history.com

Triple convergence : Protocole, Client et Entraînement

Si le protocole MCP définit un standard pour la communication entre les modèles et leur environnement, il ne fournit pas pour autant une interface client universelle. Chaque utilisateur est libre (et souvent contraint) de concevoir son propre client MCP, c’est-à-dire l’interface qui exposera les capacités des serveurs MCP à l’usage du modèle. Ce client constitue une pièce maîtresse du dispositif, car il orchestre les interactions entre le modèle, l’utilisateur et les services disponibles.

L'exemple des éditeurs comme Cursor, Windsurf ou Cline illustre bien cette logique : ces interfaces enrichissent l’expérience utilisateur en exploitant pleinement les possibilités offertes par les protocoles sous-jacents. De la même manière, on peut s’attendre à une prolifération d’interfaces MCP spécialisées, adaptées à des usages métier spécifiques, à l’image de ce que LSP a permis dans l’univers du développement logiciel.

On peut imaginer une interface pour la création de diapositives ou d'interaction avec les bases de données. Ces interfaces viendraient réduire la friction avec les modèles, qui est aujourd’hui fastidieuse ou linéaire. On se trouve fréquemment à faire des copier-coller ou à implémenter les suggestions faites par un modèle, quand celui-ci pourrait agir par lui-même. Et c’est ce que permet MCP.

Mais cette liberté vient avec une exigence forte : celle d'entraîner les modèles à utiliser correctement MCP. Le simple accès à une API standardisée ne garantit pas une utilisation optimale. Les performances varient d’un modèle à l’autre, non seulement en raison de leur architecture ou de leur taille, mais aussi selon leur exposition et leur entraînement à des schémas d’usage conformes au protocole MCP. Un modèle bien entraîné saura identifier le bon outil au bon moment, gérer correctement les appels MCP, et interpréter les réponses de façon robuste.

Aujourd’hui déjà, on observe des différences nettes entre les modèles dans leur capacité à orchestrer efficacement des appels à outils externes. Cette variabilité souligne un enjeu fondamental : il ne suffit pas de standardiser l’accès aux outils, encore faut-il que les modèles eux-mêmes soient préparés à les utiliser intelligemment. L’un des chantiers clés pour les développeurs de modèles dans les mois à venir sera donc de former explicitement leurs LLMs à interagir avec MCP, voire de les réaligner via des boucles de renforcement (RL) autour de scénarios intégrant le protocole.

Le succès du MCP ne dépend pas uniquement de la robustesse du protocole ou de l’adhésion : il repose tout autant sur l’émergence d’interfaces client bien pensées et sur la capacité des futurs modèles à devenir des utilisateurs compétents du protocole. C’est cette triple convergence, protocole, client et entraînement, qui permet au MCP de devenir un vrai décupleur dans l’écosystème LLM.

Conclusion

Le MCP s’inscrit dans un ensemble d'initiatives ayant pour but de connecter les LLMs à notre monde. Il se positionne en complément de diverses techniques et approches telles que le fine-tuning, la technique RAG ou encore les systèmes agentiques pour répondre à la problématique principale qui touche les modèles de langage tout en poussant la démarche encore plus loin. Il concentre les espoirs de la communauté de l’IA d’enfin réussir à franchir les derniers obstacles qui permettraient d’inscrire définitivement les LLMs dans notre monde hyperconnecté en proposant un standard bien défini.

Ce standard open source se veut simple d’utilisation et accessible à tous. Quelques lignes sont nécessaires pour mettre en place son serveur et être opérationnel. Les outils que l’utilisateur doit définir sont simples et répondent aux besoins de la communauté. Il faut cependant garder en tête qu'ils sont probablement voués à évoluer pour le mieux comme pour le pire dans les prochains mois.

La capacité des grands acteurs à intégrer les clients dans leur écosystème facilite l’accès à cette nouvelle technologie. Cependant, il est important d’être capable de lever le capot pour comprendre le fonctionnement de celui-ci.

L’ouverture du protocole et sa relative jeunesse exposent les utilisateurs à plusieurs failles potentielles : packaging non sécurisé, contrôles d’accès limités, multi-tenancy complexe à mettre en place… Sans un cadre de validation et de surveillance des serveurs MCP, l’écosystème peut être vulnérable à des attaques ou à des usages malveillants.

Les défis s’apparentent à ceux rencontrés par LSP, mais se révèlent plus critiques encore, car l’interconnexion avec des systèmes sensibles (base de données, services métiers) est au cœur de la proposition de valeur du MCP. La vigilance et la mise en place de mesures de protection (authentification, filtrage, revue de code, etc.) restent donc incontournables. Des outils comme MCP-scan émergent pour essayer de sécuriser ces connexions.

L’avenir du MCP repose sur l’adoption industrielle, une standardisation robuste et une gouvernance régulée qui, associées à des mécanismes de sécurité renforcés et à l’entraînement explicite des LLMs, permettront d’exploiter pleinement son potentiel.

Soutenu par une stratégie open source, MCP se positionne comme un outil technique d’intégration, ainsi qu’un levier stratégique capable de redéfinir durablement l’interopérabilité et l’innovation dans l’écosystème de l’intelligence artificielle.

Bibliographie

(n.d.). Langserver.org. Retrieved April 18, 2025, from https://langserver.org/

Anthropic. (2025, April 14). Pull requests · modelcontextprotocol/servers · GitHub. GitHub. Retrieved April 18, 2025, from https://github.com/modelcontextprotocol/servers/pulls

Arthemide. (2025). mcp-hike-and-fly. https://github.com/Arthemide/mcp-hike-and-fly/tree/master

Beurer, L., & Fischer, M. (2025, April 1). MCP Security Notification: Tool Poisoning Attacks. Invariant Labs. Retrieved April 18, 2025, from https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks

Bhavsar, P., & Bronsdon, C. (2025, Février 12). Introducing Our Agent Leaderboard on Hugging Face. https://www.galileo.ai/blog/agent-leaderboard

Example Clients. (n.d.). Model Context Protocol. Retrieved April 18, 2025, from https://modelcontextprotocol.io/clients

Fischer, M., & Beurer-Kellner, L. (2025, April 11). invariantlabs-ai/mcp-scan: A security scanning tool for MCP servers. GitHub. Retrieved April 18, 2025, from https://github.com/invariantlabs-ai/mcp-scan

Google. (n.d.). Attention is All You Need. Google Research. Retrieved April 18, 2025, from https://research.google/pubs/attention-is-all-you-need/

Google. (2025, April 9). Announcing the Agent2Agent Protocol (A2A) - Google Developers Blog. Google for Developers Blog. Retrieved April 18, 2025, from https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

Koebler, R. (2008, September 2). JSON-RPC. simple is better. Retrieved April 18, 2025, from https://www.simple-is-better.org/rpc/

Millet, T. (2025). jiki. jiki. https://github.com/teilomillet/jiki

Model Context Protocol · GitHub. (n.d.). GitHub. Retrieved April 18, 2025, from https://github.com/modelcontextprotocol

modelcontextprotocol/servers: Model Context Protocol Servers. (n.d.). GitHub. Retrieved April 18, 2025, from https://github.com/modelcontextprotocol/servers

OpenAI. (2025, March 26). OpenAI Developers on X: "MCP 🤝 OpenAI Agents SDK". X. Retrieved April 18, 2025, from https://x.com/OpenAIDevs/status/1904957755829481737

Pull requests · modelcontextprotocol/servers · GitHub. (2025, April 14). GitHub. Retrieved April 18, 2025, from https://github.com/modelcontextprotocol/servers/pulls

Roadmap. (2025, March 27). Model Context Protocol. Retrieved April 18, 2025, from https://modelcontextprotocol.io/development/roadmap

Sakal, N. (2025, March 7). What is Model Context Protocol (MCP)? How it simplifies AI integrations compared to APIs | AI Agents That Work. Norah Sakal. Retrieved April 18, 2025, from https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/

Sakal, N. (2025, March 7). What is Model Context Protocol (MCP)? How it simplifies AI integrations compared to APIs | AI Agents That Work. Norah Sakal. Retrieved April 18, 2025, from https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/

Sundar Pichai on X: "To MCP or not to MCP, that's the question. Lmk in comments". (2025, March 30). X. Retrieved April 18, 2025, from https://x.com/sundarpichai/status/1906484930957193255

tadata-org/fastapi_mcp: A zero-configuration tool for automatically exposing FastAPI endpoints as Model Context Protocol (MCP) tools. (n.d.). GitHub. Retrieved April 18, 2025, from https://github.com/tadata-org/fastapi_mcp

Technology | 2024 Stack Overflow Developer Survey. (n.d.). Stack Overflow Annual Developer Survey. Retrieved April 18, 2025, from https://survey.stackoverflow.co/2024/technology

Yan, F., Mao, H., JI, C. C.-J., Stoica, I., Gonzalez, J. E., Zhang, T., & Patil, S. G. (2024, August 19). Berkeley Function Calling Leaderboard. Gorilla, Berkeley. Retrieved April 18, 2025, from https://gorilla.cs.berkeley.edu/blogs/8_berkeley_function_calling_leaderboard.html

Zullo, P. (n.d.). mcp-use/mcp-use: mcp-use is the easiest way to interact with mcp servers with custom agents. GitHub. Retrieved April 18, 2025, from https://github.com/pietrozullo/mcp-use