À retenir
- MCP est utile parce que les outils de LLMs ont besoin d’une façon standard de se connecter aux fichiers, aux applications, aux API et aux services.
- Sa valeur ne se limite pas à la commodité. Un protocole partagé facilite la réutilisation des intégrations et leur compréhension.
- Le risque demeure l’accès aux outils. Toute couche de connexion a besoin de permissions, de logs et de limites sur ce que le modèle peut faire.
Combien de fois avez-vous commencé un nouveau projet d’IA pour vous retrouver à reconnecter encore une fois la même intégration GitHub, Slack ou SQL? Cette pénible répétition du copier-coller de code et ce manque de normes entre les organisations et les individus expliquent précisément pourquoi le Model Context Protocol, ou MCP, existe.
MCP est un standard ouvert publié il y a quelques mois, en novembre 2024, par Anthropic afin d’officialiser la façon dont nous fournissons aux grands modèles de langage les trois choses dont ils ont le plus besoin : des données supplémentaires, de bons prompts et des outils externes. L’objectif est que tout le monde l’utilise afin que tous les outils et toutes les bases de données deviennent facilement accessibles par le même protocole, ce qui réduit la complexité d’implémentation de presque tout ce qui touche aux LLMs.
Sous le capot, il fonctionne comme n’importe quel échange Web de base entre deux parties : un client (votre fenêtre de chat, votre IDE ou l’agent qui formule la demande) envoie une requête, et un serveur (la machine qui contient réellement les outils et les données) répond avec ce dont le client a besoin.
Voyons rapidement l’ensemble du stack avant d’entrer dans chaque détail… Votre application lance une session LLM et intègre un petit client MCP à côté. Dès que l’utilisateur écrit une question, le LLM décide s’il peut répondre directement à partir de ses propres poids ou s’il a besoin d’aide externe. S’il en a besoin, le client MCP envoie un appel HTTP à tools/list sur chaque URL de serveur dans sa configuration. Ces serveurs peuvent être des conteneurs Docker locaux, une VM hébergée par l’équipe sur l’intranet ou une fonction cloud à l’autre bout du monde. Chaque serveur répond avec un catalogue JSON : noms des outils, descriptions et schéma JSON des arguments acceptés. Le LLM en choisit un (ou en enchaîne plusieurs), transmet le nom de l’outil choisi et ses arguments au client MCP, puis le client invoque tools/execute. Les résultats reviennent en streaming, sont intégrés au contexte du modèle, puis la réponse finale est générée pour l’utilisateur. En bref, MCP s’insère proprement dans l’infrastructure HTTP existante : un client léger à côté du modèle, et de nombreux serveurs spécialisés derrière des ports Web standards. Si tout cela était un peu trop dense, laissez-moi vous l’expliquer plus en détail.
D’abord, et c’est très pratique, notre application quotidienne, Claude Desktop, VS Code, Cursor ou même une CLI minimale, démarre avec un client MCP intégré ou activé par une extension en un clic. Elle sait donc immédiatement comment découvrir et appeler des serveurs MCP, sans rien d’autre à connecter. Au démarrage, le client contacte un ou plusieurs serveurs MCP, chacun pouvant se trouver sur votre portable, sur l’intranet de votre équipe ou à l’autre bout de la planète. Un serveur peut exposer un accès direct à une base de données de production, un autre publie une collection de prompts éprouvés par l’équipe, et un troisième enveloppe un scraper Brave Search pour trouver des sources. Comme un serveur MCP est essentiellement un petit service Web autonome (un « microservice ») dont le comportement est défini par la spécification MCP, sa liste de fonctionnalités n’est limitée que par ce que vous codez. Une fois publié, tout client compatible avec MCP qui possède les bons identifiants peut l’utiliser.
Avant MCP, chaque nouvelle application que vous construisiez devait inclure sa propre intégration GitHub. Si vous écriviez trois assistants différents, disons une extension VS Code, un bot Slack et un outil en ligne de commande, vous copiiez-colliez le même code de l’API GitHub dans les trois. Avec MCP, vous placez cette logique GitHub une seule fois dans un serveur MCP, et toutes vos applications l’appellent simplement, sans devoir tout reconnecter.
La meilleure analogie que j’ai vue pour l’expliquer est celle de l’USB. Personne n’invente un nouveau câble et un nouveau port pour chaque appareil (sauf Apple). Vous branchez la clé dans le port et le système d’exploitation comprend le reste. MCP vise à devenir l’USB du contexte des modèles.
Voici pourquoi cela compte au quotidien. Vos serveurs MCP vivent à l’extérieur de l’éditeur. Donc, si vous passez de VS Code à Cursor, le nouvel éditeur contacte la même URL de serveur au démarrage et, boum, toute votre boîte à outils est déjà là. Aucune réinstallation ni réimportation. Comme un serveur n’est rien de plus qu’un lien partageable, vous pouvez donner ce lien à un collègue et, dès qu’il l’ajoute à sa configuration, il obtient exactement les mêmes capacités.
À l’avenir, on peut imaginer des marketplaces MCP qui commenceront à vendre l’accès à des serveurs premium. Si votre serveur MCP apporte de la valeur, mais que son exploitation coûte de l’argent, vous pourrez facturer les personnes qui l’utilisent.
Encore mieux, OpenAI et Google ont tous deux déclaré que leurs stacks de bureau ChatGPT et Gemini intégreraient MCP, ce qui signifie que leurs modèles pourront bientôt se brancher directement à des serveurs tiers.
Vous vous demandez peut-être pourquoi nous avons besoin de MCP alors qu’OpenAPI existe déjà. Imaginez OpenAPI comme une feuille d’instructions imprimée et collée sur le service que vous exposez. Si vous appelez le propre endpoint Chat Completion d’OpenAI, OpenAI publie la feuille qui décrit POST /v1/chat/completions, les champs que vous pouvez transmettre et le JSON que vous recevrez. Imaginez maintenant que vous lanciez votre propre petit service, POST /translate-text, qui détecte d’abord la langue, appelle ensuite cette même route OpenAI, nettoie la réponse et renvoie un bloc de texte propre. Comme c’est vous, et non OpenAI, qui possédez /translate-text, vous devez rédiger une nouvelle feuille d’instructions, l’intégrer à chaque client, votre extension VS Code, le bot Slack et la petite CLI dont dépend votre équipe des opérations, puis livrer une nouvelle version chaque fois que vous modifiez la fonctionnalité.
MCP renverse le modèle. Au lieu de documents figés, il fournit un menu numérique vivant. Au démarrage, le client MCP intégré de l’application appelle tools/list et récupère la liste actuelle, peut-être translate_text, summarize_article et get_weather, puis appelle tools/execute pour exécuter celui dont il a besoin. Si un collègue ajoute un tout nouvel outil translate_text au serveur à trois heures du matin, ce menu s’actualise automatiquement au prochain démarrage : aucune spécification à réécrire, aucun redéploiement, aucune instruction désuète et, surtout, rien ne tombe en panne.
Autre point intéressant : sans MCP, vous devriez relier chaque étape à la main. Il faudrait d’abord écrire du code qui appelle l’API de la base de données de ventes, attendre le retour des lignes, transmettre ces données à un service Python distinct que vous auriez aussi connecté, attendre encore, puis renvoyer l’output à l’utilisateur. Le modèle de langage ne peut ni voir ni coordonner ces services par lui-même. Vous agissez chaque fois comme middleware.
Malheureusement, MCP n’en est encore qu’à ses débuts, avec les maux de tête qui les accompagnent. Simon Willison a montré comment un message WhatsApp malveillant pouvait détourner un client MCP imprudent en dissimulant des instructions d’injection dans les descriptions des outils. Le problème est qu’il n’existe pas encore d’authentification ni d’autorisation granulaire : chaque utilisateur qui atteint un serveur voit tous les outils, y compris le bouton nucléaire delete_record. La gestion du contexte demeure aussi assez rudimentaire. Une fois la limite de 128 k tokens atteinte, le client tronque l’historique sans que vous le remarquiez. Chargez le menu avec une centaine d’outils et les chances que le modèle choisisse le bon chutent. Comme MCP n’offre ni logs ni métriques de façon native, vous ne remarquerez pas les erreurs à moins d’ajouter vous-même du monitoring. Heureusement, plusieurs entreprises, dont Descope, travaillent sur ce problème, mais nous devons être prudents puisque ce n’est pas offert par défaut.
Malgré tout, l’écosystème autour de MCP se développe rapidement : tous les fournisseurs de modèles s’y joignent, les systèmes d’authentification s’améliorent et beaucoup d’autres choses intéressantes arrivent. Pour trouver des serveurs prêts à utiliser, vous pouvez explorer les exemples officiels d’Anthropic, parcourir la liste communautaire « MCP-Servers » ou visiter Smithery.ai, un site où les développeurs publient des endpoints que tout le monde peut cloner. Ce sont les premiers signes des marketplaces qui suivront probablement.
Maintenant, comment lancer concrètement un serveur MCP? Les SDK officiels rendent la tâche très facile. Choisissez votre langage, Python, TypeScript ou un autre, puis suivez la documentation. La spécification propose même une bonne astuce comme référence rapide : récupérez le fichier texte brut llmspec.txt, qui contient tout le protocole, collez-le dans un modèle à grand contexte comme Gemini et discutez simplement avec lui pendant que vous codez. Si vous avez un doute sur un champ ou un header, Gemini a la réponse.
Voyons cela dans un exemple concret. Disons que vous voulez un serveur qui récupère la météo de n’importe quelle ville. En Python, vous importez la bibliothèque MCP, créez un petit script et marquez votre fonction avec le décorateur @mcp.tool. Le nom de la fonction devient le nom de l’outil, la docstring devient sa description et les annotations de type remplissent automatiquement le schéma JSON. Une fonction, un outil, travail terminé. Lancez le script et vous hébergez déjà un serveur MCP conforme.
Pour connecter ce serveur à Claude Desktop, par exemple, vous ouvrez claude_desktop_config.json, ajoutez une nouvelle entrée sous mcp_servers, pointez-la vers votre commande locale, peut-être weather.py, puis redémarrez l’application. À partir de ce moment, chaque fois que vous demandez « Quelle est la météo à Sacramento? », le client MCP voit votre outil get_weather, l’appelle et répond avec les prévisions.
Utiliser des serveurs dans du code personnalisé est tout aussi simple. Le SDK OpenAI Agents traite tout endpoint MCP comme un outil natif. LangChain fait la même chose avec langchain-mcp-adapters, et LlamaIndex reproduit ce modèle avec llama-index-tools-mcp. Crew AI possède aussi des hooks intégrés. La majeure partie de l’écosystème des agents parle donc maintenant MCP dès le départ.
Si vous préférez voir le code brut, le repo « quickstarts-agents » d’Anthropic est un bon point de départ. Un notebook définit trois outils, un assistant de réflexion, une calculatrice et un wrapper Brave Search, puis les branche à un agent. Vous pouvez ensuite poser n’importe quelle question, comme « Quel est le meilleur restaurant à Québec? » L’agent décide lui-même d’appeler l’outil de recherche Web et répond avec une courte liste : Tanière, ARVI et Le Saint-Amour.
En bref, écrivez une fonction, ajoutez-lui un décorateur, inscrivez-la dans la configuration de votre client, et tout agent compatible avec MCP pourra l’appeler. Le reste de l’écosystème, Agents SDK, LangChain, LlamaIndex, Crew AI et LangGraph, s’occupe de la plomberie afin que vous puissiez vous concentrer sur ce que l’outil fait réellement.
Google a aussi ajouté récemment le protocole A2A pour les conversations entre agents. Le nouveau protocole A2A de Google comble le vide que MCP laisse délibérément ouvert. MCP permet à un agent d’appeler des outils, comme une API météo, un exécuteur de requêtes SQL ou un parseur de PDF. Mais parfois, la « chose dont vous avez besoin » est un autre agent autonome capable de planifier des voyages, d’optimiser des itinéraires de livraison ou de gérer des règles comptables dans son propre stack. A2A donne un langage commun à ces agents : un agent prépare une tâche, l’envoie sur le réseau, puis l’agent distant répond avec le résultat, sans base de données ni codebase partagée.
Le workflow recommandé consiste à utiliser l’endpoint resources de MCP pour découvrir quels agents distants existent, puis à passer à A2A pour tenir la conversation proprement dite.
Si vous voulez commencer dès maintenant, Google a publié trois petits projets de référence pour illustrer l’idée en pratique : un écrit avec son propre SDK léger, un reconstruit dans LangGraph et un dans Crew AI. Vous pouvez donc ouvrir un terminal, exécuter les deux côtés localement et regarder un agent déléguer un travail à l’autre en quelques lignes de code. Une fois la découverte et le format des messages pris en charge, il s’avère que les transferts entre agents ne sont pas plus difficiles que l’appel de n’importe quel autre service HTTP.
Donc, si vous vous posiez encore la question, voici pourquoi MCP, et maintenant A2A, ont été créés : plutôt que de consacrer des heures à des intégrations sur mesure, vous lancez un serveur MCP une fois et tous les clients conformes, de votre IDE à l’application ChatGPT pour ordinateur de demain, se branchent et fonctionnent. Nous avons encore besoin de façons plus intelligentes de raccourcir ou de résumer les longues conversations et, tout aussi important, d’un monitoring intégré digne de ce nom, soit un simple log qui montre quels outils ont été appelés, combien de temps ils ont fonctionné et où ils ont échoué. Mais la plomberie fondamentale est solide et peut être livrée assez rapidement.
La prochaine fois que vous serez sur le point de copier-coller la même intégration GitHub pour un quatrième projet en production, arrêtez-vous. Enveloppez ce code dans un petit serveur MCP, ajoutez le wrapper OAuth en trois lignes de Descope et revenez à la fonctionnalité qui importe réellement à vos utilisateurs.
Si ce guide vous a épargné quelques heures de boilerplate, donnez-lui un pouce en l’air, partagez-le avec le collègue qui n’utilise toujours pas MCP et abonnez-vous. Si vous voulez en apprendre davantage, l’un des auteurs originaux de MCP a présenté une explication approfondie de 1 heure et 44 minutes sur YouTube. Je vous invite aussi à découvrir le cours sur les agents que nous lançons avec Towards AI et DecodingML. Nous y montrons comment tirer le maximum de MCP, déployer un agent sur A2A et l’utiliser dans le cours! Écrivez-moi si vous voulez en savoir plus.
Sur ce, j’espère que vous avez aimé cet aperçu de MCP et que vous comprenez mieux sa raison d’être et son potentiel. Merci d’avoir lu, et on se retrouve dans le prochain article!
FAQ
Qu’est-ce que MCP pour les intégrations de LLMs?
MCP est un protocole qui permet de connecter des modèles et des agents à des outils, à des sources de données et à des services externes d’une façon plus standard.
Pourquoi les builders s’intéressent-ils à MCP?
Il peut réduire les intégrations ponctuelles et rendre l’accès aux outils plus réutilisable entre les agents, les éditeurs, les applications et les workflows.
À quoi faut-il faire attention avec MCP?
Tout protocole d’outils élargit ce que le modèle peut toucher. Les permissions, les secrets, les logs et les actions destructrices doivent donc être bien encadrés.
Comment les clients et les serveurs MCP communiquent-ils?
Un client demande des outils ou des données par le protocole, tandis qu’un serveur expose des capacités et renvoie des résultats structurés.
Un serveur MCP peut-il envelopper un autre agent autonome?
Oui. Un serveur peut encapsuler un service ou un agent autonome derrière la même interface standard.
Comment un LLM découvre-t-il les outils offerts par un serveur MCP?
Le client appelle tools/list et reçoit un catalogue de noms d’outils, de descriptions et de schémas d’arguments parmi lesquels le modèle peut choisir.