Surcharge des responsabilités du MCP
Une critique fréquente est que le MCP est surchargé de responsabilités. L’auteur soutient que le MCP devrait principalement servir de passerelle permettant aux LLM d’accéder aux ressources externes et d’interagir avec elles. Le considérer simplement comme une ‘porte’ ou un ‘pont’ permet de clarifier son objectif et ses limites.
Attribuer directement au MCP des problèmes tels que l’exposition accidentelle de données, les vulnérabilités d’injection d’invite et les lacunes en matière de contrôle des coûts est un mauvais placement du blâme. Ce sont des problèmes que les développeurs devraient résoudre dans les limites qu’ils contrôlent. Les développeurs doivent mettre en œuvre des limites de débit et surveiller l’utilisation, quel que soit le protocole utilisé. Équivaloir cela à blâmer la route pour excès de vitesse est approprié : l’infrastructure n’est pas responsable du comportement individuel.
En fin de compte, bon nombre des préoccupations soulevées sont des problèmes plus larges liés à la délégation de tâches à des agents IA. Les développeurs doivent assumer la responsabilité de la gestion de ces défis dans leurs applications spécifiques, plutôt que d’attendre que l’API elle-même gère tout.
L’épée à double tranchant des LLM et de l’injection d’invite
Les discussions récentes autour du MCP ressemblent souvent à des mises en garde contre les dangers inhérents aux couteaux aiguisés : ils peuvent couper s’ils sont mal manipulés. L’injection d’invite, une préoccupation importante, est une conséquence de la nature même des LLM. Les tentatives d’éliminer le risque d’injection d’invite risquent de dégrader les capacités mêmes qui rendent les LLM précieux.
La notion de séparation ‘contrôle vs données’, courante dans les systèmes traditionnels, n’existe pas naturellement dans les LLM. Les LLM tirent leur puissance et leur généralité précisément parce qu’ils manquent de cette séparation rigide. Cette caractéristique inhérente les rend vulnérables aux attaques par injection d’invite.
Bien que les MCP distants en tant que service puissent présenter des risques, la faute n’incombe pas au protocole lui-même, mais au fait de confier des tâches sensibles à des tiers non fiables. Cette analogie s’étend à l’idée de fixer un couteau avec du ruban adhésif à un Roomba erratique : le problème n’est pas le couteau lui-même, mais la décision de l’attacher à un appareil imprévisible.
Les admonestations à ‘être prudent’ ou les suggestions d’équipement de protection, bien que techniquement exactes, passent à côté du problème central : la décision malavisée de combiner un outil tranchant avec un système non contrôlé.
Défis d’évolutivité
Au-delà des problèmes de sécurité, le MCP est confronté à des limitations fondamentales en matière d’évolutivité. L’auteur souligne la corrélation négative entre la fiabilité des LLM et la quantité de contexte pédagogique fournie. Cela remet en question la croyance commune selon laquelle l’ajout de plus de données et d’intégrations résoudra automatiquement les problèmes. À mesure que le nombre d’outils et d’intégrations augmente, les performances d’un agent peuvent se dégrader tout en augmentant simultanément le coût de chaque requête.
L’auteur souligne que le MCP ne s’étend pas au-delà d’un certain seuil. Tenter d’ajouter un nombre illimité d’outils au contexte d’un agent aura inévitablement un impact négatif sur ses capacités. Cette limitation est inhérente au concept de MCP et nécessite plus d’attention que les problèmes d’authentification.
Les utilisateurs peuvent éventuellement constater une baisse de performances à mesure qu’ils activent davantage de serveurs MCP, ce qui entraîne des interférences entre eux. Ceci contraste fortement avec les systèmes typiques de gestion de packages, où la non-interférence est une propriété fondamentale.
Le problème central avec le MCP est que son comportement réel s’écarte des attentes des utilisateurs. Il est essentiel de reconnaître que le MCP n’est pas une solution prête à l’emploi qui intègre de manière transparente un nombre illimité d’outils sans conséquences.
Résoudre les limitations avec l’interface utilisateur et la gestion des outils
Une solution proposée aux limitations du MCP est d’améliorer l’interface utilisateur. Si un outil est exécuté involontairement, l’interface utilisateur doit fournir un moyen simple de le désactiver ou de modifier sa description pour clarifier son utilisation prévue.
L’auteur note également que la croissance du contexte conduit souvent à une amélioration des performances et des capacités d’utilisation dans le monde réel, ce qui contredit la notion d’une corrélation strictement négative. Cependant, ils reconnaissent que dans certains cas d’utilisation ou avec des contextes mal conçus, une dégradation des performances peut se produire.
Pour faire face au choix écrasant d’outils, une approche ‘diviser pour régner’ est suggérée. Cela implique l’ajout d’un outil spécialement conçu pour sélectionner les outils les plus pertinents pour une tâche donnée. Cet ‘outil de choix d’outils’ pourrait être un autre appel LLM, chargé de renvoyer un sous-ensemble d’outils disponibles à l’agent ‘parent’. Cette approche en couches ajoute des niveaux d’indirection supplémentaires pour gérer la complexité.
Cependant, le simple fait d’avoir des outils dans le contexte peut modifier considérablement la sortie d’un modèle. Bien que les outils contextuellement pertinents (obtenus grâce à des techniques telles que la génération augmentée par récupération ou RAG) soient bénéfiques, le fait de masquer tous les outils derrière une requête ‘get_tools’ peut être préjudiciable.
MCP en tant que couche de transport et d’autorisation
Le MCP fonctionne principalement comme un transport et un format de fil avec un cycle de vie requête/réponse, en se concentrant sur l’autorisation au niveau de l’outil. L’essai soutient que le plus gros problème avec le MCP est son incapacité à permettre aux agents IA de composer fonctionnellement des outils.
L’auteur postule que le MCP peut être inutile en premier lieu, car les LLM possèdent déjà la capacité d’interagir avec les API documentées à l’aide de spécifications OpenAPI. L’élément manquant est l’autorisation : la capacité de contrôler les API auxquelles une IA peut accéder. Au lieu du MCP, l’auteur suggère d’autoriser les IA à effectuer des requêtes HTTP tout en appliquant une autorisation à des points de terminaison spécifiques. Cette approche s’aligne sur la tendance actuelle à envelopper les API existantes avec des outils MCP minces.
Un aspect particulièrement ennuyeux du MCP est son manque de prise en charge des résultats d’appel d’outil en streaming. La paire requête/réponse unique oblige les clients à appeler à plusieurs reprises des outils pour la pagination, ce qui entrave les processus de longue durée. La mise en œuvre d’une capacité de diffusion en continu, peut-être à l’aide de gRPC, pourrait améliorer considérablement l’efficacité du MCP.
La facilité d’exposition des données sensibles
Une préoccupation importante concernant le MCP est le potentiel d’exposition facile des données sensibles. De plus, le MCP ne rend pas intrinsèquement les agents IA plus fiables ; il leur accorde simplement l’accès à plus d’outils, ce qui peut paradoxalement diminuer la fiabilité dans certaines situations.
L’auteur reconnaît qu’il ne s’attend pas à ce que le MCP résolve ou soit responsable de tous ces problèmes. Au contraire, le MCP crée une plus grande surface d’attaque pour ces problèmes, obligeant les développeurs d’applications et les utilisateurs à être vigilants.
Analogies et urbanisme
L’auteur utilise l’analogie de l’urbanisme pour illustrer le problème. Comparer le MCP à une route urbaine à six voies avec une limite de vitesse de 40 km/h met en évidence le décalage entre la conception et l’utilisation prévue. Le simple fait d’imposer des amendes ou d’ajouter des ‘corrections’ superficielles ne résout pas le problème sous-jacent d’une mauvaise conception.
Un urbanisme efficace consiste à concevoir des routes qui encouragent naturellement le respect des limitations de vitesse. De même, le MCP devrait être conçu pour atténuer intrinsèquement les risques potentiels, plutôt que de s’appuyer uniquement sur des contrôles externes.
Les LLM prennent des mesures non désirées
L’article passe à une critique plus large des protocoles qui permettent aux LLM d’exécuter des actions sur les services. L’auteur identifie un problème central : les LLM peuvent prendre des mesures que les utilisateurs ne souhaitent pas qu’ils prennent. Ils distinguent les actions que les LLM peuvent entreprendre indépendamment de celles qui nécessitent une invite de l’utilisateur.
Bien que l’objectif ultime puisse être de faire gérer des entreprises entières par les LLM, la technologie n’est pas encore prête pour une telle autonomie. Actuellement, les utilisateurs peuvent même ne pas vouloir que les IA envoient des e-mails sans examen préalable.
L’auteur rejette la solution consistant à demander à l’utilisateur une confirmation, invoquant le risque que les utilisateurs tombent dans un schéma de confirmation automatique (‘mode YOLO’) lorsque la plupart des outils semblent inoffensifs. Cela s’apparente au phénomène psychologique des personnes dépensant plus avec des cartes qu’avec de l’argent liquide : un problème enraciné dans le comportement humain, et non dans la technologie.
La question fondamentale : pourquoi ne pas simplement utiliser des API ?
Une question récurrente dans les discussions sur le MCP est de savoir pourquoi ne pas simplement utiliser des API directement.
Le MCP permet aux clients LLM que les utilisateurs ne contrôlent pas directement (par exemple, Claude, ChatGPT, Cursor, VSCode) d’interagir avec les API. Sans le MCP, les développeurs devraient créer des clients personnalisés à l’aide des API LLM, une entreprise beaucoup plus coûteuse que d’utiliser des clients existants avec un abonnement et de leur apprendre à utiliser des outils spécifiques.
Un développeur partage son expérience de la création d’un serveur MCP pour se connecter à son synthétiseur matériel FM via USB, permettant une conception sonore basée sur l’IA.
Intégration du client LLM et normalisation
Le problème central est que tous les clients LLM ne prennent pas en charge nativement l’interaction directe avec l’API, les actions GPT personnalisées de ChatGPT étant une exception notable. Anthropic, Google et OpenAI ont convenu d’adopter le MCP comme protocole partagé pour rationaliser le processus pour les clients alimentés par LLM tels que Claude, ChatGPT et Cursor.
Le MCP simplifie le processus pour ceux qui créent des clients LLM. Si vous voulez qu’un LLM interagisse avec une API, vous ne pouvez pas simplement fournir une clé API et vous attendre à ce que cela fonctionne : vous devez créer un agent.
Le MCP peut être considéré comme un moyen de documenter les API et de décrire comment les appeler, ainsi que des outils normalisés pour exposer cette documentation et faciliter les appels. Il fournit juste assez d’abstraction pour envelopper les API sans complication inutile, mais cette simplicité peut également amener les utilisateurs à ‘se tirer une balle dans le pied’.
L’efficacité et la réutilisabilité du MCP
Sans le MCP, les développeurs devraient expliquer à plusieurs reprises au LLM comment utiliser un outil chaque fois qu’il est invoqué. Cela comporte le risque que le LLM ne parvienne pas à utiliser correctement l’outil en raison d’informations oubliées ou d’un comportement API non standard.
Ces explications et duplications constantes gaspillent des jetons dans le contexte, augmentant les coûts et le temps. Le MCP rationalise ce processus en regroupant toutes les informations nécessaires, ce qui rend l’utilisation de l’outil plus efficace et facilite le partage d’outils.
En disant à un fournisseur LLM ‘voici un outil que vous pouvez utiliser’ avec la documentation de l’API, les utilisateurs peuvent réutiliser cet outil dans plusieurs chats sans rappels répétés. Cela permet également aux clients LLM de bureau de se connecter à des programmes exécutés localement, ce qui résout le problème des processus d’exécution spécifiques au système d’exploitation.
MCP et accès aux ressources locales
Le MCP facilite l’accès aux ressources locales telles que les fichiers, les variables d’environnement et l’accès au réseau pour les LLM. Il est conçu pour être exécuté localement, accordant au LLM un accès contrôlé à ces ressources.
La ‘forme’ standard d’appel d’outil LLM reflète fidèlement la ‘forme’ d’appel d’outil MCP, ce qui en fait une norme simple pour connecter des outils à des agents.
Le MCP agit comme un pont entre le schéma d’appel de fonction exposé au modèle d’IA et les API sous-jacentes. Il traduit les appels de fonction en outils, permettant une communication transparente.
Si vous êtes un fournisseur d’outils, le MCP offre un protocole normalisé pour que les interfaces d’agent IA se connectent à votre outil. Cela répond à la question de savoir pourquoi le protocole standard ne peut pas simplement être HTTP et OpenAPI.
Le MCP est une méta-API qui intègre des points de terminaison et leurs détails opérationnels dans la spécification, ce qui permet aux LLM d’interagir avec eux plus efficacement.
Le MCP dans des scénarios spécifiques
Le MCP peut résoudre des problèmes lorsque les utilisateurs posent des questions ou ne savent pas quelles API utiliser. Il peut également traiter les requêtes en fonction des messages précédents.
Un utilisateur partage son expérience du désir de récupérer le ‘X’ d’un utilisateur et de l’envoyer à un point de terminaison. Ils ont trouvé que le MCP était excessif pour une tâche aussi simple, indiquant qu’il n’est pas toujours nécessaire pour les interactions API de base.
Le MCP est assimilé à un framework d’application Web FastAPI pour la création de logiciels capables de communiquer sur le réseau, spécialement conçu pour les expériences agentiques. Il peut être considéré comme un ‘Rails-for-Skynet’, fournissant un framework normalisé pour le développement d’agents IA.
Préoccupations concernant le contrôle du fournisseur
Il existe des préoccupations selon lesquelles le MCP est poussé pour accroître le contrôle du côté du fournisseur sur le système. Les fournisseurs de LLM pourraient éventuellement restreindre l’accès à l’API, de la même manière que Google a rendu difficile l’utilisation d’IMAP/SMTP avec Gmail.
L’utilisation d’OpenAPI permet aux agents de récupérer les spécifications de l’API à partir de /openapi.json.
Le MCP permet des interactions rapides, permettant aux utilisateurs d’accomplir des tâches en quelques secondes au lieu de passer du temps à préparer les données d’entrée, à les envoyer à l’API, à analyser la sortie et à répéter le processus pour chaque message.
Sandbox et risques de sécurité
L’un des plus gros problèmes est la façon dont la sortie d’un outil de serveur MCP peut affecter d’autres outils dans le même fil de messages. Cela nécessite une sandbox entre les outils pour éviter les conséquences imprévues. Les laboratoires invariants ont résolu ce problème avec des descriptions d’outils, tandis que d’autres ont utilisé des pièces jointes de ressources MCP. Le manque de sandbox exacerbe les risques d’injection d’invite.
Ceci est assimilé à l’injection SQL : un système bricolé où les vulnérabilités peuvent être exploitées à tout moment avec une observabilité minimale.
L’interface d’invite est également susceptible d’une forme d’injection SQL, car le modèle ne peut pas distinguer les parties fiables de l’invite des entrées contaminées par l’utilisateur. La résolution de ce problème nécessite des modifications fondamentales de l’encodage, du décodage et de la formation du modèle.
Cela permet à la fois l’injection d’invite et l’injection d’outil, ce qui peut conduire à l’exécution de code non fiable.
Conteneurisation et accès contrôlé
Un développeur a créé un serveur MCP qui démarre un conteneur Docker avec le code du projet monté. Cette approche permet au LLM d’accéder à l’ensemble de l’ensemble d’outils Unix et aux outils spécifiques au projet dans un environnement sandbox.
Ce flux de travail agentique, piloté par une interface basée sur le chat, s’est avéré plus efficace que les méthodes traditionnelles.
La clé est d’accorder aux agents MCP l’accès à ce dont ils ont besoin, et rien de plus. La conteneurisation et l’UX d’outils transparents sont essentielles pour atténuer les risques de sécurité.
Machines virtuelles et accès Internet
Donner aux agents un ordinateur avec une installation Linux minimale (en tant que VM ou conteneur) peut donner de meilleurs résultats, leur permettant de récupérer des informations sur Internet. Cependant, cela soulève des problèmes de sécurité concernant les instructions malveillantes et l’exfiltration de données.
Limiter l’accès aux sites Web de confiance peut atténuer certains risques, mais même les sources de confiance peuvent héberger du contenu malveillant. Le compromis entre la probabilité de rencontrer des instructions malveillantes et les avantages en termes de productivité doit être soigneusement examiné.
Les différences entre les employés et les agents IA sont importantes. Les employés sont des personnes morales soumises aux lois et aux contrats, ce qui assure la responsabilisation. Les agents IA n’ont pas ce cadre juridique, ce qui rend la confiance plus difficile.
Les premières étapes du développement du MCP
Le MCP n’a été annoncé qu’en novembre 2024 et le RFC est en évolution active.
Certains considèrent l’ensemble du concept d’assistant personnel IA, y compris le MCP, comme fondamentalement erroné.
La première poussée pour les assistants IA à la fin des années 1990 et au début des années 2000 a échoué parce que les agrégateurs de contenu avec intégration verticale et pouvoir d’achat en gros se sont avérés plus efficaces. Cela a conduit à l’essor de plateformes comme Expedia et eBay.
Les systèmes multi-agents exigent que les programmeurs influencent l’état des agents, une tâche de programmation difficile.
Les limites de la valeur gratuite
Le désir de ‘classer les résultats par disponibilité de stationnement’ met en évidence le problème de l’accès aux données derrière les API payantes ou les interfaces adossées à la publicité. Les entreprises sont peu susceptibles de fournir gratuitement l’accès à l’ensemble de leurs données via une API.
Bien que toutes les entreprises n’intègrent pas leurs données dans des agents IA, le potentiel de combinaison de divers outils pour alimenter les flux de travail reste important.
Les entreprises qui privilégient le maintien d’un fossé de données résisteront probablement aux nouvelles technologies qui menacent ce fossé.
Si booking.com avait une API, ils renverraient probablement les mêmes résultats que leur site Web, éventuellement avec une mise en forme JSON ou XML.
Contourner l’intermédiaire
Il n’est pas logique qu’un intermédiaire comme booking.com permette aux utilisateurs de contourner complètement ses services.
Cependant, les hôtels individuels pourraient trouver avantageux de contourner booking.com, un intermédiaire qu’ils n’aiment souvent pas.
Une IA de recherche approfondie pourrait rechercher des hôtels en fonction de critères spécifiques et interagir avec les serveurs MCP Hotel Discovery gérés par des hôtels individuels, évitant ainsi d’avoir à naviguer dans l’interface et les publicités de booking.com.
Cas d’utilisation pratiques
Le MCP peut faciliter des tâches telles que la récupération de journaux à partir d’Elasticsearch ou l’interrogation de bases de données de manière plus structurée.
La nature statique de la configuration du serveur MCP, où les nouveaux serveurs nécessitent la modification d’un fichier .json et le redémarrage de l’application, peut être limitante.
Modèles affinés
Le MCP peut être considéré comme un petit modèle affiné qui comprend de nombreux outils MCP et choisit les bons pour chaque conversation.
L’ajustement dynamique des outils en fonction du contexte peut être nécessaire dans certains scénarios.
Conversations ouvertes et problèmes commerciaux
Le MCP est bien adapté aux systèmes de conversation généraux et ouverts sans flux prédéfini. Cependant, ce n’est pas une solution unique pour tous les problèmes commerciaux. Il n’est pas destiné à remplacer des frameworks comme LangChain.
L’alternative au MCP, une norme ouverte pilotée par la communauté, est fragmentée, exclusive et verrouillée par le fournisseur. Une norme imparfaite mais en évolution est préférable à l’absence de norme.
La meilleure façon de considérer le MCP est comme un passage des développeurs individuels créant des wrappers clients autour des API aux fournisseurs d’API ou aux wrappers gérés par la communauté les créant. Cela fournit une grande boîte à outils, similaire à NPM ou PyPi. Cependant, l’orchestration, la sécurité et la définition de l’utilisation sont toujours nécessaires.
La prochaine génération de Langchains bénéficiera de cette plus grande boîte à outils, mais l’innovation est toujours nécessaire.
Outils spécifiques à l’utilisateur
Dans certains cas, les outils peuvent être spécifiques aux données de l’utilisateur, tels que les outils de découpage et de manipulation des fichiers CSV téléchargés.
Un problème souvent négligé est que le MCP peut encombrer le contexte du modèle avec trop d’options. La priorisation et l’exposition des métadonnées sont essentielles pour éviter le gaspillage de jetons et le comportement erratique du modèle.
Normes et technologies en évolution
De nouvelles normes émergent au fil du temps, et il y a si longtemps que les normes ont vraiment compté que les gens ont oublié comment elles se développent.
Le téléchargement de minuscules programmes de serveur auprès de développeurs aléatoires pour ajouter des ‘outils’ aux clients LLM peut être risqué.
Les problèmes soulevés sont des problèmes légitimes que l’écosystème MCP doit résoudre. Certaines solutions se trouveront dans la spécification MCP, tandis que d’autres seront externes.
Code Claude et utilisation réelle
Il existe des opinions contrastées sur le succès du MCP. Certains ont entendu des histoires d’entreprises s’intégrant au MCP, tandis que d’autres ont entendu des utilisateurs qui l’ont trouvé décevant.
Cela met en évidence l’inconvénient du battage médiatique et de l’adoption précoce.
Certains développeurs trouvent que les API HTTP sont supérieures au MCP pour la plupart des cas d’utilisation. Ils soutiennent que l’utilisation des ‘outils’ se résume à des points de terminaison d’API pour les capacités et les fonctionnalités.
Les API ne sont pas auto-descriptives par défaut, ce qui représente une occasion manquée pour les partisans de REST et HATEOAS de présenter leurs approches.
Le MCP comme alternative à LangChain ?
Le MCP a été décrit comme ayant une ‘odeur de LangChain’ : ne résolvant pas un problème urgent, étant trop abstrait et ayant du mal à expliquer ses avantages.
Peut-être doit-il dire ‘FIN DE LIGNE’ et bannir les pirates informatiques en herbe dans la grille de jeu !
Une question clé est de savoir si le paradigme ‘général’ de Chatbot persistera. Les applications spécialisées avec leurs propres outils pourraient ne pas avoir besoin du MCP.
Inversement, à mesure que les LLM deviennent plus performants, les outils externes pourraient devenir moins nécessaires. Pourquoi voudriez-vous un MCP pour piloter Photoshop alors que le LLM pourrait simplement modifier l’image directement ?
Le rêve d’un assistant robot de science-fiction peut ne pas se matérialiser, et les outils spécialisés de manipulation du langage pourraient être plus utiles.
La base d’utilisateurs et la sensibilisation à la sécurité
La base d’utilisateurs du MCP comprend des personnes moins techniques, ce qui rend les problèmes de sécurité particulièrement pertinents. La sensibilisation aux meilleures pratiques de sécurité est cruciale.
Baser Xops sur OpenRPC, qui nécessite la définition du schéma de résultats, aide à planifier la façon dont les sorties se connectent aux entrées, améliorant ainsi la fiabilité des flux de travail complexes.
La technologie est susceptible d’évoluer et de se stabiliser avec le temps.
Redondance et infrastructure cloud
Certains remettent en question les gains de l’utilisation du MCP par rapport à la norme OpenAPI, la considérant comme redondante.
Qu’est-ce que le LLM utilisera pour appeler un système OpenAPI ? Comment se liera-t-il au shell ? Comment l’hôte du LLM orchestrera-t-il cela ?
Le MCP fournit un moyen structuré pour que les LLM effectuent des appels d’outils.
Les serveurs MCP sont déjà des serveurs HTTP.
Le plus grand avantage du MCP est pour les fournisseurs de LLM comme OpenAI, pas pour les développeurs d’applications.
Les LLM sont des cerveaux sans outils, et l’appel d’outils leur donne du pouvoir. Cependant, avec les API normales, les fournisseurs de LLM n’ont pas accès à ces outils. Le MCP leur accorde l’accès, les positionnant comme la passerelle vers l’IA.
CLI vs API
Pourquoi ne pas utiliser la CLI directement, étant donné que les LLM sont formés au langage naturel et que les CLI sont une solution courante lisible et inscriptible par l’homme ?
Le MCP a émergé trop rapidement et a besoin de temps pour mûrir. Il manque un contrôle par un organisme de normalisation conventionnel et est motivé par le battage médiatique.
Il y a un manque d’applications du monde réel.
Applications clés du MCP
Le MCP est utilisé dans Claude Desktop et les applications de chat AI de niche, les outils d’automatisation du code et les frameworks d’automatisation des agents/LLM.
C’est une autre technologie précipitée qui sera probablement abandonnée lorsque le prochain acronyme susceptible d’être surmédiatisé arrivera.
Il existe deux types de protocoles d’appel d’outils de modèle de langage : ceux dont les gens se plaignent et ceux que personne n’utilise.
Anthropic a développé cette ‘norme’ dans le vide, ce qui a conduit à des problèmes de sécurité.
JSON-RPC 2.0
Le MCP est construit sur JSON-RPC 2.0, un protocole léger qui permet la communication client et serveur à l’aide de JSON.
Il ressemble à une spécification centralisée conçue pour un écosystème spécifique, revendiquant l’universalité sans la gagner.
Le MCP est assez puissant pour faire des choses utiles, ce qui soulève des problèmes de sécurité.
Ce n’est pas une norme mature et n’a pas été conçu pour être sécurisé.
Bien que des recommandations existent, elles ne sont ni appliquées ni mises en œuvre.
Langchain et appel d’outil
Langchain est l’un des nombreux frameworks qui mettent en œuvre le modèle d’’appel d’outil’.
Le MCP est une spécification de la façon dont les informations externes entrent dans la fenêtre de contexte d’un modèle de langage, y compris l’appel d’outil, l’entrée basée sur un modèle, l’annulation, le suivi de la progression et l’état des serveurs d’outils.
Il aide à normaliser les détails afin que toute combinaison assistant/intégration soit compatible.
Bien que le MCP ait des problèmes légitimes, les critiques devraient affiner leurs arguments.
L’authentification est cruciale et n’aurait pas dû être omise de la version initiale.
Il y a trop de complexités.