MCP expliqué : fonctionnement du Model Context Protocol

Les LLM peuvent appeler des outils depuis quelque temps, mais Model Context Protocol (MCP) apporte une méthode structurée et standardisée pour le faire.

Il existe pourtant encore une confusion sur ce qu’est réellement MCP.

Beaucoup supposent que MCP est une application, une API ou un outil, mais ce n’est rien de tout cela. C’est un protocole, et cela a un sens très précis.

Décomposons-le.

Si vous voulez simplement voir ce que MCP permet en pratique, regardez cette courte vidéo :

Qu’est-ce qu’un protocole ?

Un protocole est simplement un ensemble de règles qui définissent comment deux systèmes ou plus communiquent entre eux.

Il ne fait rien par lui-même. Il définit seulement la structure et les attentes d’une conversation entre deux entités. Considérez-le comme un langage partagé avec des règles de grammaire strictes que les ordinateurs suivent pour échanger des informations.

Les systèmes postaux font quelque chose de similaire. Tous les bureaux de poste d’un pays donné suivent un format d’adresse standardisé pour envoyer des lettres.

Ou pensez-y comme à l’USB-C pour les outils d’IA. Il y a vingt ans, le marché était saturé de différents types de câbles de charge et de données. De la même manière, les écosystèmes d’IA ont eu plusieurs façons de transmettre des outils aux modèles de langage. Des frameworks comme LangChain, Haystack et Pydantic AI ont tous défini leurs propres formats pour intégrer des outils, ce qui signifie que si un développeur voulait écrire un ensemble d’outils pour Google Maps, il devait le faire pour chaque technologie spécifique.

Pour rendre cela plus concret, examinons le protocole le plus populaire, HTTP (Hypertext Transfer Protocol), qui alimente les sites web. HTTP définit, entre autres, comment un navigateur (client) demande une page web à un serveur web et comment le serveur doit répondre.

Voici un exemple de cycle requête-réponse HTTP :

1. Le navigateur effectue une requête HTTP

Lorsque vous saisissez https://example.com dans votre navigateur, celui-ci envoie une requête HTTP structurée au serveur web :

Voici les paramètres et valeurs HTTP utilisés dans notre exemple :

"GET" – Il s’agit de l’action (demander une page web).
"/index.html" – La page web spécifique demandée.
"HTTP/1.1" – La version du protocole utilisée.
"Host: example.com" – Le nom de domaine du site web.
"User-Agent: Mozilla/5.0" – Des informations sur le navigateur qui effectue la requête.

Le serveur web sait comment interpréter cette requête parce que HTTP standardise ce format. Il comprend ce « langage ».

2. Le serveur répond en utilisant le protocole HTTP

Le serveur traite la requête et renvoie une réponse HTTP structurée :

"HTTP/1.1 200 OK" – Le code de réponse (200 signifie succès).
"Content-Type: text/html" – Le type de contenu renvoyé.
"Content-Length: 512" – La taille de la réponse.
HTML Content – Le contenu réel de la page web (il y a seulement un titre « Welcome to Example.com »)

Important : HTTP lui-même ne stocke pas les pages web et ne les affiche pas. Il définit seulement les règles selon lesquelles les navigateurs web et les serveurs web sont autorisés à communiquer. Tout système qui suit ces règles peut communiquer sur l’Internet défini par HTTP.

Comment MCP fonctionne comme protocole

Appliquons maintenant le même raisonnement à MCP (Model Context Protocol).

MCP est un protocole qui permet aux agents d’IA de communiquer avec des outils et des sources de données externes. Comme HTTP, il ne stocke pas de données et n’exécute pas de tâches lui-même. Il définit simplement une méthode standardisée permettant à l’IA de demander et de récupérer des informations auprès d’outils.

Quels sont ces « outils », pourriez-vous demander ?

Dans le contexte des LLM, les outils sont des systèmes, API ou services externes avec lesquels l’IA peut interagir pour étendre ses capacités au-delà de la simple génération de texte. Ils permettent aux agents d’IA de récupérer des données en temps réel, de réserver des rendez-vous ou d’envoyer des messages à vos amis, ce qui les rend beaucoup plus utiles pour les besoins réels.

Supposons que vous demandiez à un agent d’IA :

« Quelle heure est-il à Londres en ce moment ? »

Comme l’IA elle-même ne connaît pas la bonne réponse, puisque les modèles d’IA ont une date limite de connaissances (octobre 2023 pour les modèles d’OpenAI), elle doit récupérer des données en direct auprès d’un service horaire. Mais au lieu d’utiliser HTTP pour demander une page web, l’IA utilise MCP pour demander des données horaires.

Voici ce qui se passe :

1. L’agent d’IA effectue une requête MCP au service horaire (exemple)

"method": "tools.call" → L’IA appelle un outil externe.
"tool": "get_time" → Le nom de l’outil qu’elle veut utiliser.
"args": { "location": "London" } → Les paramètres d’entrée spécifiques.

Comme avec HTTP, cette requête suit un format strict afin que tout outil compatible MCP sache exactement comment l’interpréter.

2. Le serveur horaire MCP répond

L’outil externe (serveur horaire) suit les règles de réponse de MCP et renvoie :

"status": "success" → Confirme que la requête a été traitée correctement.
"result" → Contient les données horaires réelles.

L’agent d’IA peut maintenant prendre ces données et composer une réponse réelle à l’utilisateur avec :

« L’heure actuelle à Londres est 12:20 PM (GMT). »

Pour résumer et dissiper la confusion :

« MCP est une application. » → Non, MCP est un ensemble de règles. Vous avez besoin de logiciels d’IA et d’outils qui implémentent MCP pour l’utiliser réellement, de la même manière que l’application Instagram a besoin de serveurs Instagram actifs pour répondre aux requêtes HTTP et fournir des données.

« MCP est une base de données. » → Non, MCP ne stocke pas de données. Il aide les agents d’IA à communiquer avec des bases de données ou des API.

« MCP est comme une API. » → Pas exactement. Une API est une méthode spécifique pour interagir avec un système, tandis qu’un protocole (comme MCP ou HTTP) définit une méthode universelle permettant à de nombreux systèmes différents de communiquer. MCP est un langage qu’un système d’IA peut utiliser pour interagir avec de nombreuses API réelles (heure, bases de données, Stripe, Slack, etc.).

Pourquoi MCP est intéressant

Maintenant que nous savons que MCP est une méthode standardisée permettant aux logiciels d’IA d’interagir avec des outils et applications externes, et que MCP n’est pas une API, voyons pourquoi la communauté des développeurs d’IA (nous y compris) s’y est intéressée.

Comme MCP n’est pas une API, mais permet plutôt aux applications d’IA d’interagir avec de véritables API à grande échelle, il aide les projets qui nécessitent une connexion à de nombreux systèmes externes à démarrer plus rapidement. Les outils donnent aussi de la portée à un modèle, et ce qui s’est passé lors de l’incident OpenAI Hugging Face montre à quoi ressemble cette portée lorsqu’elle dépasse la tâche. Pour cela, les développeurs devaient parfois passer par un cycle complet de développement d’intégration API, mais aujourd’hui, ils utilisent généralement des bibliothèques existantes ou des projets open source (par exemple disponibles sur GitHub) qui fournissent la fonctionnalité nécessaire.

L’utilisation de ces bibliothèques accélère le développement, mais les intégrer correctement à votre système (s’il n’est pas compatible avec l’implémentation que vous avez trouvée sur GitHub) demande toujours des efforts pour que l’outil fonctionne avec l’IA.

Avec MCP, une fois le framework en place, ajouter une nouvelle intégration (par exemple, intégrer Google Drive) peut consister à se connecter au serveur MCP Google Drive avec quelques lignes de code. Vous ne rencontrerez pas de problèmes de compatibilité, car vous utilisez tous deux le même protocole : MCP.

Comparons les deux approches pour voir plus clairement les différences.

Intégration standard vs utilisation de Model Context Protocol (MCP)

Pour rendre cette comparaison concrète, parcourons l’ajout d’un accès aux fichiers Google Drive à un agent d’IA, d’abord manuellement, puis avec un outil compatible MCP.

Intégration standard

1. Trouver et adapter une bibliothèque : vous recherchez un client API Google Drive ou un projet open source. Google fournit des bibliothèques clientes (par exemple Google Drive API pour Python) ; vous l’incluez dans votre projet. Vous devez encore vous assurer qu’elle fonctionne avec l’environnement de votre IA.

2. Implémenter la logique : vous écrivez des fonctions pour, par exemple, rechercher des fichiers ou récupérer un document depuis Drive. L’IA, lorsqu’elle a besoin de quelque chose, doit appeler ces fonctions. Vous formatez la requête de l’IA en appels API spécifiques à Google Drive. Après avoir obtenu une réponse de Google, vous extrayez le contenu pour le transmettre au contexte de l’IA.

3. Gérer les erreurs et les cas limites : ajoutez du code pour gérer des cas comme « fichier introuvable », les erreurs d’autorisations ou les limites de débit de l’API. Si l’API de Google renvoie une erreur, vous l’interceptez et répondez peut-être avec un message d’excuse, ou demandez à l’IA de reformuler. Vous devez également empêcher votre IA d’envoyer trop de requêtes trop rapidement.

4. Maintenir : avec le temps, si Google met à jour son API ou la bibliothèque, vous devez mettre à jour votre code. Si vous trouvez un bogue dans la bibliothèque, vous devrez peut-être le corriger ou trouver une autre source. Vous devenez essentiellement le mainteneur de cette intégration Google Drive au sein de votre application d’IA.

Ce processus s’étend aux autres outils : vous voulez ajouter Slack ou une base de données à votre IA ? Vous devez répéter tout le processus pour chacun.

Intégration MCP

Voyons maintenant à quoi ressemblerait ce processus avec MCP.

Tout d’abord, définissons les concepts clés :

Client – une application d’IA (ChatGPT, application Claude, Quickchat AI) qui établit une connexion à un ou plusieurs serveurs et demande des informations ou des actions pour effectuer des tâches déclenchées par un utilisateur.

Server – Chaque serveur peut se connecter à quelque chose comme une base de données ou une API (Google Drive), et définir un ensemble d’« outils » ou de données qu’il peut fournir. Dans ce cas, le serveur est un programme qui expose ces outils et capacités au Client (application d’IA).

Les développeurs, selon ce qu’ils veulent faire, peuvent choisir l’un ou l’autre côté : créer un serveur pour exposer des données, ou créer un client d’IA capable de communiquer avec n’importe quels serveurs. La plupart veulent la deuxième option, mais commençons tout de même par le côté serveur pour comprendre étape par étape comment MCP fonctionne :

• Initialisation d’un serveur MCP. Un développeur ou un administrateur système configure un serveur MCP pour un outil ou une source de données donnée. Un serveur MCP est généralement un petit programme qui implémente la spécification MCP. Par exemple, il existe un serveur Google Drive MCP préconstruit qui sait rechercher et récupérer des documents.

  Lors de l’initialisation du serveur, vous lui donnez accès au système cible (Google Drive). Le serveur expose ensuite un ensemble d’outils correspondant aux actions ou requêtes qu’il peut traiter. Il s’agit essentiellement d’un adaptateur d’API qui parle MCP d’un côté et le service natif de l’autre.

  Une fois le serveur en cours d’exécution, il attend les requêtes.

• Connexion d’un LLM (client) à un serveur MCP. Ensuite, l’application d’IA (le côté « client ») doit se connecter à ce serveur. En pratique, si vous utilisez une plateforme d’IA qui prend en charge MCP (comme Claude Desktop), vous la configurez avec l’adresse ou la commande permettant de démarrer le serveur. Une fois connecté, le client établit une session avec le serveur en suivant la poignée de main MCP. Si vous utilisez l’interface de Claude, vous verriez que Claude est « connecté » à certains serveurs MCP (l’interface utilisateur peut indiquer les connecteurs disponibles).

Voici à quoi cela ressemble dans l’interface utilisateur de Claude

• Découverte des outils disponibles. Une fois la connexion établie, la première chose à faire est de savoir ce que le serveur propose (parfois, cela se produit automatiquement après la connexion au serveur). Le client MCP envoie une requête tools/list au serveur (cela est défini dans le protocole). Le serveur répond avec une liste de ses outils disponibles, chacun avec des détails comme le nom, la description et le schéma d’entrée.

  Par exemple, un serveur peut répondre qu’il dispose des outils create_file(path, content), read_file(path) et search_files(query). Le client rend ensuite ces informations disponibles au LLM. Dans de nombreuses implémentations, le client formate ces descriptions d’outils et les inclut dans le contexte du modèle (par exemple, en ajoutant au prompt système : « Vous avez accès aux outils suivants… [liste d’outils] »).

Voici un prompt système d’IA avec le message de l’utilisateur demandant l’heure actuelle

Avec les outils MCP implémentés, un outil appelé “get_current_time” est intégré, ce qui permet à l’IA d’accéder à une ressource externe et de récupérer l’heure exacte à Londres

Cela signifie que vous n’avez pas besoin de prévoir et de programmer à l’avance toutes les actions potentielles dont votre application d’IA pourrait avoir besoin pour accomplir une tâche. Avec MCP, l’IA peut découvrir toutes les actions possibles à la volée en interrogeant un serveur MCP et choisir ce qui est nécessaire.

• Utilisation d’un outil via MCP. Lorsque l’IA doit effectuer une action ou récupérer des données, elle invoque un outil via MCP. Du point de vue de l’IA (surtout pour les modèles comme Claude qui prennent nativement en charge l’utilisation d’outils), elle décidera dans son raisonnement : « Je dois appeler l’outil X avec ces paramètres. » Le client MCP capture cette intention et envoie une requête tools/call au format MCP au serveur approprié (serveur MCP Google Drive).

• Le serveur MCP agit comme un pont. Il reçoit une requête structurée conforme à MCP de la part de l’agent d’IA, la mappe au bon endpoint de l’API Google Drive, réécrit la requête en un véritable appel API Google Drive, exécute la requête, traite la réponse, puis la reformate à nouveau en réponse conforme à MCP avant de la renvoyer à l’agent d’IA.

  Il convient de noter que les serveurs MCP suivent une approche structurée pour traiter les erreurs, ce qui permet aux agents d’IA de les interpréter et d’agir efficacement.

  Supposons qu’un agent d’IA utilise un outil MCP pour trouver un fichier dans Google Drive. Si la requête inclut un ID de fichier invalide (par exemple, une chaîne de cinq caractères au lieu du format attendu), le serveur MCP renverra un message d’erreur :

  Plutôt que d’échouer simplement, l’agent d’IA peut prendre cette réponse structurée et la reformuler en retour compréhensible pour l’utilisateur :

  « Il semble que l’ID de fichier que vous avez fourni soit trop court. Les ID de fichiers Google Drive comptent généralement 28 caractères. Pouvez-vous vérifier et réessayer ? »

  Cette approche garantit que les erreurs ne mènent pas à des impasses, mais deviennent des occasions pour l’agent d’IA de guider l’utilisateur vers une résolution réussie.

• Répondre à la question ou à la demande de l’utilisateur. Une fois que le serveur MCP renvoie un résultat, le client MCP transmet ces données à l’application d’IA. Le modèle intègre ensuite le résultat dans son raisonnement ou directement dans la sortie qu’il génère pour l’utilisateur.

  Si l’utilisateur demande la création d’un nouveau fichier Google Sheets, la réponse du serveur (contenant l’ID du fichier et un lien généré) sera fournie au modèle. Le modèle répondra ensuite à l’utilisateur avec : « Bonne nouvelle ! Votre nouveau fichier Google Sheets est prêt. Vous pouvez y accéder ici : [link]. »

Tout au long de ce processus, l’IA garde le contrôle du flux : elle décide quand appeler un outil et comment utiliser le résultat pour formuler sa réponse. En parallèle, le développeur n’a pas à orchestrer manuellement ces étapes, le framework MCP et le modèle d’IA s’en chargent. Le résultat final est que l’utilisateur peut poser à l’IA des questions ou des tâches complexes qui nécessitent des informations ou des actions externes, et l’IA peut les exécuter de manière autonome via MCP et renvoyer un résultat.

Avantages de l’utilisation de MCP

Remarquez comment cette approche abstrait de nombreux détails : le client n’a pas géré les clés API ni les codes de statut HTTP, ceux-ci sont gérés par le serveur MCP.

Le point principal est la simplicité au niveau du point d’intégration : nous « demandons » des clients, et nous les obtenons. La logique permettant de les récupérer est encapsulée ailleurs. Cela signifie qu’un développeur qui travaille côté IA n’a pas besoin d’écrire de nouveaux appels HTTP pour chaque nouvelle action, il invoque simplement les outils par leur nom. Le gros du travail (authentification, appel des endpoints Google Drive, formatage de la réponse) est effectué dans le code du serveur MCP, qui est réutilisable et standardisé.

Voici un résumé des principaux avantages :

• Réduit le code de liaison spécifique aux API. Avant MCP, faire utiliser un service externe par une IA nécessitait généralement d’écrire beaucoup de code de « liaison » : appeler l’API, transformer la réponse en texte que le modèle peut assimiler, puis analyser la sortie du modèle pour éventuellement appeler une autre API, etc. Avec MCP, une grande partie de cette liaison est supprimée. Le client du modèle et le serveur gèrent l’échange de données de manière structurée, vous n’avez donc pas besoin de transformer manuellement d’autres formats (comme JSON) en texte ou inversement, le protocole le fait. Vous n’avez pas non plus à écrire la logique permettant de décider quand appeler quoi. L’IA (guidée par les descriptions des outils et par son propre raisonnement ou prompt) s’en charge.

• Des connecteurs réutilisables et partagés au lieu de wrappers API ponctuels. Avec MCP, vous écrivez une intégration une seule fois et pouvez la réutiliser dans de nombreux projets et systèmes d’IA. Par exemple, vous pourriez créer un serveur MCP pour le wiki interne de votre entreprise. Toute application d’IA qui prend en charge MCP peut se connecter à ce serveur unique pour interroger le wiki. Vous n’avez pas besoin de réimplémenter la « recherche wiki » pour chaque nouveau chatbot d’IA ou chaque fournisseur de LLM différent. Cette réutilisabilité marque un changement par rapport au passé, où chaque équipe pouvait écrire sa propre intégration légèrement différente pour la même API. MCP encourage une bibliothèque de connecteurs pouvant être partagés et améliorés collectivement.

• Intégration plug-and-play avec différents LLM. MCP est indépendant du modèle. Le protocole ne se soucie pas de savoir si le client est Claude, GPT-4, DeepSeek ou tout futur modèle, tant que le client peut gérer l’interface MCP. À l’avenir, si vous voulez passer à un autre modèle, vous pourrez le faire sans réécrire toutes vos intégrations.

• Maintenance plus simple. Comme il s’agit d’un standard ouvert, une communauté croissante contribue à des serveurs préconstruits (pour des bases de données, des API populaires, etc.) que vous pouvez exploiter au lieu de tout créer à partir de zéro. À mesure que vous intégrez davantage de systèmes, MCP aide à éviter les intégrations point à point enchevêtrées. Et vous n’avez pas besoin de surveiller toutes les mises à jour d’API des autres fournisseurs.

Les intégrations API vont-elles devenir obsolètes ?

Les intégrations API traditionnelles et MCP ont toutes deux leur place. La meilleure approche peut dépendre de la nature du projet, de l’expertise de l’équipe et des objectifs à long terme.

Si vous devez seulement intégrer un ou deux services externes et que les interactions sont relativement simples, une intégration API directe est souvent la solution la plus rapide. Si votre application web doit simplement vérifier un jeton de paiement Stripe au moment du paiement, appeler directement l’API de Stripe est simple et efficace. Introduire MCP dans ce scénario pourrait être excessif. Vous pouvez connecter un agent d’IA à n’importe quelle API REST documentée avec une HTTP Action vérifiée, ou utiliser une intégration en un clic comme Google Sheets pour enregistrer les leads et les demandes de démonstration, sans exécuter de serveur MCP.

Dans les cas où vous avez besoin d’un contrôle très précis sur la requête et la réponse (pour l’optimisation des performances, un traitement de données particulier ou des protocoles propriétaires), écrire directement vers l’API peut être préférable. Les intégrations traditionnelles vous permettent d’utiliser toutes les fonctionnalités avancées d’une API et d’adapter les appels exactement. Si une API a des exigences inhabituelles ou si vous voulez éviter toute couche d’abstraction pour une clarté et un contrôle maximaux, l’approche traditionnelle est appropriée.

Pour un exemple concret de la manière dont les outils MCP sont exposés à un agent d’IA en production aux côtés d’actions API personnalisées, voyez comment Quickchat AI Agents combine les deux approches. La discussion plus détaillée sur le moment où utiliser MCP, des AI Actions individuelles ou “Generate from Text” se trouve dans API pour agents d’IA : de MCP aux endpoints personnalisés. Pour essayer vous-même, suivez le guide étape par étape pour connecter votre agent d’IA à un serveur MCP distant afin qu’il appelle un outil en direct pendant la conversation.

Liste des serveurs MCP disponibles

Si vous voulez commencer avec MCP, consultez les répertoires de serveurs MCP ci-dessous :

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Vous pouvez également en exécuter un sans écrire de code : chaque Quickchat AI Agent peut être transformé en serveur MCP avec une URL hébergée que Claude, ChatGPT et Cursor appellent comme outil. La connexion fonctionne aussi dans l’autre sens : un Quickchat AI Agent peut appeler le serveur MCP hébergé d’un fournisseur comme ses outils, c’est ainsi que l’assistant de planification IA construit sur le serveur MCP de Calendly vérifie les disponibilités réelles et réserve des réunions depuis un chat, et qu’un chatbot IA Notion répond depuis un centre d’aide en direct et enregistre les demandes de support dans une base de données Notion.

Quickchat AI exploite également un serveur MCP distant pour votre propre compte. Connectez-le à ChatGPT, Claude, Cursor ou Codex, et vous pouvez gérer vos agents d’IA depuis cet environnement : analytics, transcriptions de conversations, mises à jour de la base de connaissances et création de nouveaux agents, derrière une seule connexion OAuth. Le guide de configuration pour chaque client se trouve dans Gérez votre agent d’IA depuis ChatGPT, Claude et Codex avec MCP.

FAQ

Cela fonctionne-t-il uniquement avec Claude ?

MCP est indépendant du modèle. Le protocole ne se soucie pas de savoir si le client est Claude, GPT-4, un dérivé local de LLaMA ou tout futur modèle, tant que le client peut gérer l’interface MCP. Cela signifie que vous n’êtes pas verrouillé dans un seul fournisseur d’IA lorsque vous créez vos intégrations d’outils.

En quoi MCP diffère-t-il du fait de donner au modèle toutes les informations dont il a besoin dès le départ ? Pourquoi ne pas simplement remplir le prompt avec des données ?

MCP est fondamentalement différent du fait de remplir le prompt du modèle avec des données, car il permet au modèle de récupérer dynamiquement des informations quand c’est nécessaire, plutôt que de travailler avec un prompt statique préchargé. Remplir le prompt avec du texte se heurte à des limites, car les modèles d’IA ont une fenêtre de contexte fixe, ce qui signifie qu’un excès de données peut faire perdre des détails importants, ralentir les réponses et augmenter les coûts d’API (en raison des modèles de tarification au token utilisés par les fournisseurs de LLM). Cela ne fournit aussi des connaissances qu’à un seul instant, alors que MCP permet un accès en temps réel à des données externes en direct et permet à l’IA d’agir, pas seulement de lire des informations. Une IA avec un prompt surchargé peut connaître les détails d’un client, mais ne pourra pas mettre à jour des enregistrements ni traiter des transactions.

Que se passe-t-il si nous connectons des dizaines d’outils à l’IA ? Cela ne va-t-il pas submerger le modèle ou l’amener à mal les utiliser ?

Cela dépend de l’implémentation, mais il est vrai que les LLM actuels ont des limites dans leur capacité à distinguer et choisir entre de nombreuses options. Si vous présentez à un modèle, par exemple, 50 outils possibles, il existe un risque qu’il choisisse le mauvais. L’approche MCP elle-même ne vous oblige pas à tout charger en même temps. Vous devez connecter les outils pertinents selon le contexte. Une bonne pratique consiste à connecter uniquement les outils nécessaires à la tâche ou au domaine concerné et à exploiter la collaboration multi-agent, une forme de routage d’outils ou un agent qui décide d’abord quel sous-ensemble d’outils prendre en considération.

MCP vs Function Calling

Le function calling traditionnel (tel qu’on le voit dans l’API d’OpenAI ou d’autres LLM) permet à un développeur de définir un ensemble de fonctions, de fournir leurs définitions au modèle, puis de laisser le modèle les « appeler » par leur nom avec des arguments. Cela a été une grande étape pour l’intégration de l’IA, mais cette approche a des limites. Une différence majeure concerne le moment et la manière dont les outils sont définis. Dans le function calling classique, toutes les fonctions possibles doivent être déclarées à l’avance (au moment de la conception) dans le prompt ou via l’API. Le modèle peut uniquement appeler ces fonctions fixes. Dans MCP, les outils sont découvrables à l’exécution, l’IA peut interroger ce qui est disponible et même obtenir de nouveaux outils en cours de session.

MCP vs GPT Actions & Plugins

GPT Actions/Plugins désigne l’écosystème d’OpenAI dans lequel vous pouviez activer des plugins (comme un navigateur web ou un lecteur PDF) pour ChatGPT, ou les « GPTs » (agents ChatGPT personnalisés) qui peuvent utiliser des outils. Ils étaient intéressants, mais nécessitaient un développement personnalisé pour chaque plugin et étaient limités aux plateformes d’OpenAI. Si vous vouliez un plugin ChatGPT pour une tâche, vous deviez créer une API et un manifeste, puis passer par l’approbation d’OpenAI ou au moins l’activer manuellement. Chaque plugin était essentiellement un silo, un plugin météo, un plugin voyage, etc., chacun avec ses propres endpoints et sa propre logique. MCP améliore ce concept en l’unifiant et en l’ouvrant.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) est une technique dans laquelle un LLM est complété par une base de connaissances externe. Généralement, RAG implique une base de données vectorielle ou un index de recherche : la requête de l’utilisateur est utilisée pour récupérer des documents ou données pertinents (par recherche sémantique ou par d’autres méthodes), et ces documents sont fournis au modèle comme contexte supplémentaire à « lire » lors de la formulation d’une réponse. RAG consiste à fournir au modèle des connaissances qu’il n’avait pas à l’origine, ce qui est particulièrement utile pour la QA factuelle ou les informations propres à un domaine. Cependant, RAG est en lecture seule, le modèle récupère des passages de texte, mais n’effectue pas d’actions au-delà de la récupération.

MCP, à l’inverse, consiste à effectuer des actions ou des opérations arbitraires, pas seulement à récupérer un contexte informationnel. Avec MCP, une IA peut faire des choses : écrire dans une base de données, envoyer un e-mail, exécuter du code, etc. Elle n’est pas limitée à la récupération de connaissances, elle peut déclencher des changements dans des systèmes externes. Ainsi, à bien des égards, RAG et MCP répondent à des objectifs différents.