Dans le paysage actuel de l’intelligence artificielle (IA), un concept suscite un engouement considérable : le MCP, ou Protocole de Contexte de Modèle. Étonnamment, l’attention portée à ce système de protocole a même éclipsé les dernières versions de modèles d’OpenAI, devenant un point central des discussions de l’industrie.
L’essor de la technologie Agent, stimulé par la montée en puissance de Manus, a alimenté l’enthousiasme des développeurs du monde entier. Le MCP, présenté comme un ‘protocole unifié’ pour l’invocation d’outils Agent, a rapidement gagné du terrain, obtenant le soutien des principaux acteurs de l’IA comme OpenAI et Google en seulement deux mois. Cette ascension fulgurante a transformé le MCP, d’une spécification technique relativement obscure, en une norme fondamentale au sein de l’écosystème de l’IA, marquant un ‘événement phénoménal’ dans le domaine de l’infrastructure de l’IA.
Cependant, à mesure que l’excitation initiale s’estompe, des questions essentielles émergent : le MCP est-il vraiment universellement applicable ? Les attentes concernant ses capacités sont-elles devenues exagérées ?
Cette exploration se penche sur les origines du MCP, dissèque ses forces et ses limites fondamentales, clarifie les idées fausses courantes et examine sa trajectoire future potentielle. Le but n’est pas de rejeter la valeur intrinsèque du MCP, mais plutôt de favoriser une compréhension plus réaliste de son rôle et de ses limites. Ce n’est que grâce à une telle clarté que son potentiel pourra être pleinement réalisé.
Dévoilement du MCP : Un protocole d’invocation d’outil unifié
Définir le MCP
Le MCP est un protocole technique ouvert conçu pour normaliser la façon dont les grands modèles de langage (LLM) interagissent avec des outils et services externes. Considérez-le comme un traducteur universel dans le monde de l’IA, permettant aux modèles d’IA de ‘converser’ avec un large éventail d’outils externes. Il fournit un langage et une structure communs aux LLM pour demander et utiliser les fonctionnalités offertes par différentes applications et services.
La nécessité du MCP
Avant l’avènement du MCP, l’invocation d’outils d’IA était entravée par deux défis clés :
- Fragmentation de l’interface : Chaque LLM utilisait des formats d’instructions distincts, tandis que chaque API d’outil avait ses propres structures de données. Les développeurs étaient obligés d’écrire du code de connexion personnalisé pour chaque combinaison, ce qui entraînait un processus de développement complexe et inefficace.
- Inefficacité du développement : Cette approche de ‘traduction individuelle’ s’est avérée coûteuse et difficile à mettre à l’échelle. C’était comme embaucher un traducteur dédié pour chaque client étranger, ce qui entravait la productivité et l’agilité.
Le MCP s’attaque à ces points sensibles en fournissant un cadre normalisé permettant aux LLM d’interagir avec des outils externes, simplifiant ainsi le processus de développement et permettant une plus grande évolutivité.
Comprendre la fonctionnalité du MCP
L’architecture technique du MCP peut être conceptualisée comme un système comprenant trois composants principaux : l’hôte MCP, le client MCP et le serveur MCP. Ces éléments fonctionnent en synergie pour faciliter une communication transparente entre les modèles d’IA et le monde extérieur.
Pour saisir le rôle du MCP, considérez un environnement d’entreprise moderne. Dans cette analogie :
- Les utilisateurs représentent les cadres supérieurs, responsables de la compréhension des besoins des utilisateurs et de la prise de décisions finales.
- Les grands modèles de langage (LLM) (comme Claude ou GPT) comprennent les instructions des cadres, planifient les étapes des tâches, déterminent quand utiliser des services externes et consolident les informations pour fournir des réponses.
- Les systèmes d’agents fonctionnent comme des assistants personnels ou des secrétaires de direction, exécutant les tâches comme indiqué.
- Le MCP agit comme une plateforme de communication normalisée ou un système d’accès aux services d’entreprise utilisé par les secrétaires. Il ne prend pas de décisions, mais suit plutôt les instructions, communiquant avec divers fournisseurs de services dans un format et un protocole unifiés.
Avant le MCP, l’interaction de l’IA avec des outils externes ressemblait à une ère de normes de communication chaotiques. Chaque fois qu’un secrétaire (Agent) devait contacter un département différent ou un fournisseur externe, il devait utiliser un appareil de communication ou un logiciel différent. Cela nécessitait une familiarité avec divers systèmes, entraînant des inefficacités. Les développeurs devaient écrire des codes de connexion séparés pour chaque outil, entraînant une perte de temps et une évolutivité limitée.
Le MCP rationalise ce processus en fournissant une plateforme de communication unifiée, permettant aux secrétaires de contacter n’importe quel département ou fournisseur de services en utilisant le même système et le même protocole de communication. Les développeurs n’ont besoin d’implémenter l’interface MCP qu’une seule fois, ce qui permet aux systèmes d’IA d’interagir avec tous les outils qui prennent en charge le protocole.
MCP : Une boîte à outils construite sur l’appel de fonction
Il est essentiel de comprendre que le MCP ne remplace pas l’appel de fonction traditionnel ; il s’agit plutôt d’un composant complémentaire qui améliore ses capacités.
L’appel de fonction est le mécanisme principal par lequel les LLM interagissent avec des outils ou des API externes. Il s’agit d’une capacité fondamentale des LLM, leur permettant d’identifier quand un outil est nécessaire et quel type d’outil est requis.
Le MCP agit comme un système de classification d’outils, fournissant un cadre structuré pour organiser et accéder à divers outils. Par conséquent, le MCP ne remplace pas l’appel de fonction, mais fonctionne plutôt en conjonction avec les Agents pour accomplir des tâches complexes.
Le processus complet d’invocation d’outil implique une combinaison de ‘l’appel de fonction + l’agent + le système MCP’.
En substance, le LLM exprime la nécessité d’appeler un outil spécifique via l’appel de fonction. L’Agent suit les instructions pour exécuter l’invocation d’outil, tandis que le MCP fournit une spécification d’invocation d’outil normalisée.
Considérez l’analogie suivante : un patron (utilisateur) veut du café. Au bureau (hôte MCP), le gestionnaire de bureau (LLM) ordonne au secrétaire (Agent) d’acheter un Americano (appel de fonction). Le secrétaire vérifie la liste des fournisseurs et constate qu’un fournisseur de café Americano s’est intégré à Meituan ou au système d’approvisionnement unifié de l’entreprise (serveur MCP implémenté). Le secrétaire localise ensuite le fournisseur dans le système d’approvisionnement (client MCP) et passe une commande.
Auparavant, sans MCP, lorsque le LLM émettait un appel de fonction, l’Agent traduisait et se connectait directement à l’API pour invoquer l’outil. Chaque API nécessitait un mode d’invocation séparé et une liste d’outils définie et un mode d’invocation pour que l’Agent puisse l’interpréter. Avec MCP, de nombreuses API peuvent être commandées directement via le client MCP du fournisseur, ce qui permet à l’Agent de gagner du temps et des efforts. Cependant, l’appel de fonction du LLM reste inchangé, toujours au format {outil : ‘acheter du café’, ‘type’ : ‘Americano’}.
En distinguant l’appel de fonction et le MCP, il devient clair que le MCP ne détermine pas quel outil utiliser, ni ne gère la planification des tâches ou l’intention de l’utilisateur. Ces aspects relèvent de la compétence de la couche Agent. Le MCP fournit simplement une interface d’outil unifiée, devenant un protocole standard reconnu au sein de l’industrie.
Les défis de développement du MCP et le paysage du marché
L’énigme du développement
Depuis février, la communauté de développement de l’IA a été témoin d’une ‘ruée vers l’or du MCP’. En l’absence d’une boutique d’applications officielle, des milliers d’outils se sont volontairement intégrés au protocole MCP en trois mois.
Cette croissance rapide a propulsé le MCP au centre de l’attention de l’industrie, mais a également exposé le fossé entre l’aspiration et la réalité. Les développeurs considéraient initialement le MCP comme une ‘clé universelle’, mais ont constaté qu’il s’agissait plutôt d’une ‘clé spécialisée’, excellant dans certains scénarios, mais se révélant moins efficace dans d’autres.
Les participants au MCP peuvent être classés comme applications clientes locales, applications clientes cloud et développeurs de serveurs MCP. Les applications locales sont similaires aux assistants IA locaux, tandis que les applications clientes cloud ressemblent aux versions Web de ChatGPT. Les développeurs de serveurs MCP sont les véritables fournisseurs d’outils, qui doivent reconditionner leurs API pour se conformer aux règles du MCP.
L’émergence du MCP a d’abord été bien accueillie par les applications clientes locales, mais les applications clientes cloud et les développeurs de serveurs MCP ont été confrontés à des défis.
Le MCP est originaire de l’application Claude Desktop d’Anthropic, initialement conçue comme un protocole d’interface pour invoquer des fichiers et des fonctions locaux, profondément enraciné dans les besoins côté client.
Pour les utilisateurs de clients locaux, le MCP représentait une révolution, offrant une boîte à outils infiniment extensible qui permettait aux utilisateurs d’étendre continuellement les capacités de leurs assistants IA.
Les applications clientes locales comme Cursor et Claude Desktop ont tiré parti du MCP pour permettre aux utilisateurs d’ajouter dynamiquement des outils en fonction des besoins individuels, réalisant ainsi une expansion illimitée des capacités des assistants IA.
Le MCP s’attaque à un point sensible essentiel dans le développement de clients locaux : comment permettre aux applications IA d’interagir de manière transparente avec les environnements locaux et les outils externes sans développer d’interfaces séparées pour chaque outil. Ce protocole unifié réduit considérablement les coûts d’intégration, offrant aux petites startups et aux développeurs individuels un raccourci pour créer des applications IA riches en fonctionnalités avec des ressources limitées.
Cependant, l’attrait du MCP diminue lorsqu’on considère le développement côté serveur (serveur MCP) et les clients cloud. Les premières versions du MCP utilisaient un mécanisme à double liaison pour les serveurs cloud (distants), utilisant une longue connexion SSE pour la transmission unidirectionnelle de messages du serveur vers le client et une courte connexion HTTP pour l’envoi de messages.
Cette approche fonctionnait bien pour la rétroaction et l’intervention opportunes des utilisateurs, mais créait une série de défis d’ingénierie dans les environnements côté serveur.
Premièrement, l’implémentation de l’interface MCP représente une charge de travail supplémentaire pour les grands fournisseurs de services d’entreprise, sans nécessairement générer d’avantages correspondants. Ces services ont souvent des systèmes d’API matures, et fournir une couche d’adaptation MCP supplémentaire peut simplement augmenter les coûts de maintenance sans créer de valeur substantielle. De nombreuses applications de niveau entreprise préfèrent des mécanismes d’invocation d’outils fermés et contrôlables à l’écosystème ouvert du MCP.
De plus, pour gérer les invocations à forte concurrence, les services MCP doivent souvent être mis à l’échelle vers des architectures multi-serveurs. Le modèle à double connexion du MCP introduit la complexité de l’adressage inter-machines. Lorsqu’une longue connexion est établie sur un serveur et qu’une requête est acheminée vers un autre serveur, un mécanisme de file d’attente de diffusion supplémentaire est nécessaire pour coordonner ces connexions distribuées, ce qui augmente considérablement la difficulté d’implémentation et les coûts de maintenance.
Deuxièmement, le MCP a des limites dans le domaine des applications cloud. Les Agents IA cloud (Agents côté serveur) s’exécutent généralement dans des services sans état, traitant les tâches après l’acceptation et libérant les ressources une fois l’exécution terminée. L’utilisation du client MCP côté serveur nécessite la création temporaire d’un lien SSE, l’envoi d’une requête d’invocation d’outil, la réception du résultat du SSE, puis la fermeture du lien SSE, ce qui est une approche inefficace qui augmente la complexité et réduit les performances. Une seule requête RPC devrait suffire dans ce scénario.
En pratique, les applications cloud utilisant le MCP reposent souvent sur des ensembles d’outils prédéfinis et n’utilisent pas la capacité de signature du MCP de découverte dynamique d’outils et de chargement flexible.
Le mode d’interaction des données des environnements cloud limite la capacité d’utiliser librement les outils comme le MCP l’entend. Il nécessite un processus hautement normalisé pour invoquer des outils spécifiques et codés en dur, sacrifiant ainsi la flexibilité.
L’équipe MCP a fait preuve de réactivité aux commentaires des utilisateurs. Après avoir reçu des commentaires des développeurs côté serveur, MCP a mis à jour son protocole le 26 mars, remplaçant le transport SSE d’origine par un transport HTTP en continu. Le nouveau protocole prend en charge à la fois les scénarios de service sans état qui nécessitent uniquement des requêtes d’invocation d’outil uniques et les exigences de transmission en temps réel qui étaient auparavant satisfaites par des liaisons doubles HTTP + SSE.
Ces améliorations suggèrent que les problèmes MCP actuels découlent des limitations de conception initiales, mais ne sont pas insurmontables.
Le désordre du marché
Un autre défi auquel est confronté le MCP est la faible convivialité de nombreuses implémentations sur le marché.
Le marché MCP actuel connaît un cycle de battage médiatique technologique typique. Semblable au chaos du premier App Store, moins de 20 % des milliers d’outils MCP actuellement disponibles ont une valeur pratique. De nombreuses implémentations présentent de graves problèmes, allant de simples erreurs de configuration à une inutilisabilité complète. Certains sont mis sur le marché à la hâte sans tests adéquats, tandis que d’autres sont des produits expérimentaux jamais destinés à un usage pratique.
Un problème plus fondamental est que de nombreuses implémentations MCP peuvent ne pas être nécessaires par le marché. De nombreux outils proposés via MCP sont simplement des API reconditionnées qui étaient déjà disponibles et utilisées avant l’émergence du MCP, ajoutant peu de valeur unique.
Par exemple, des dizaines de services de recherche sont proposés via MCP, mais leur qualité varie considérablement. Certains services peuvent être inexacts ou lents, ce qui les rend moins souhaitables que les solutions existantes.
De plus, le MCP manque d’un système d’évaluation robuste, ce qui rend difficile pour les Agents de sélectionner l’outil le plus approprié en fonction de mesures fiables. Ce processus de sélection inefficace gaspille des ressources informatiques, prolonge les délais d’exécution des tâches et dégrade l’expérience utilisateur.
L’absence d’un système d’évaluation rend difficile pour les agents de sélectionner l’outil le plus approprié. Si plusieurs services MCP offrent des outils avec des noms et des descriptions similaires, l’agent peut avoir du mal à choisir la meilleure option, ce qui entraîne un gaspillage de jetons et une réduction de l’efficacité.
Les applications IA les plus réussies adoptent souvent l’approche inverse, fournissant des outils plus précis plutôt qu’une plus grande quantité d’outils. Manus, par exemple, a choisi de créer des applications internes au lieu d’adopter le protocole MCP, malgré son existence. Manus a privilégié la précision et la stabilité des appels plutôt que l’intégration à l’écosystème MCP.
Les éditeurs de code comme Cursor ont des fonctions de développement intégrées, ce qui rend la plupart des outils MCP externes redondants.
L’état chaotique actuel du marché MCP n’est pas nécessairement un signe d’échec, mais plutôt une étape de croissance nécessaire pour tout écosystème technologique émergent. Les précédents historiques suggèrent que cette surexpansion initiale convergera progressivement grâce à des mécanismes de sélection du marché, laissant derrière elle les éléments les plus précieux.
Ce processus permettra à l’industrie de tirer des leçons des défis actuels et de créer un cadre MCP plus solide et plus fiable. Semblable à la façon dont la bulle Internet a conduit à des innovations révolutionnaires dans le commerce électronique et les médias sociaux, la tendance MCP peut conduire à un écosystème d’outils plus rationalisé et plus précieux.
L’attitude ouverte de l’équipe MCP envers les commentaires des utilisateurs est encourageante, et l’industrie a besoin de meilleurs outils pour évaluer et garantir la qualité des services MCP, ce qui contribuera à rendre l’écosystème plus utilisable.
Le MCP est bon, pas une panacée
Les problèmes mentionnés ci-dessus proviennent des limites et des lacunes du MCP, soulignant ce qu’il peut réellement réaliser. Cependant, d’autres critiques proviennent d’attentes irréalistes.
Une critique récente qualifie le MCP de protocole imparfait, car il ne dicte pas les schémas d’interaction entre les LLM et le MCP.
Certains s’attendent à ce que le MCP améliore automatiquement la prise de décision du système IA ou augmente l’efficacité de la planification des tâches. Cette attente confond les outils avec les artisans.
Le problème découle d’une inadéquation cognitive : s’attendre à ce qu’un protocole de communication effectue les tâches d’un système intelligent. C’est comme blâmer l’USB de ne pas modifier les photos ou de reprocher aux normes 5G de ne pas écrire de code. Le MCP est principalement un ‘socket d’outil’ normalisé, garantissant la compatibilité des prises plutôt que de dicter quel appareil utiliser ou comment.
L’efficacité de l’invocation d’outil Agent dépend de facteurs tels que la compétence en matière de sélection d’outils, les compétences en planification des tâches et la compréhension du contexte, dont aucun ne relève de la compétence du MCP. Le MCP ne garantit qu’une interface d’outil normalisée, pas la façon dont ces outils seront choisis et combinés.
Nous recherchons souvent des solutions miracles en technologie, des solutions universellement applicables. Comme l’axiome de ‘pas de solution miracle’ du génie logiciel, l’utilisation des outils IA n’a pas de solution magique. Un système IA puissant a besoin de composants conçus : LLM pour la compréhension et la génération, des cadres Agent pour la planification et l’exécution, et MCP axé sur les interfaces d’outils unifiées.
Le MCP montre une bonne conception de protocole : se concentrer sur un seul problème et le résoudre bien, plutôt que tous. Sa retenue l’aide à progresser dans l’intégration d’outils côté client.
Des entités comme Qwen d’Alibaba, ‘Xinxiang’ de Baidu et Kouzi Space de ByteDance adoptent le protocole MCP, essayant d’établir des écosystèmes MCP internes plus efficaces.
Cependant, il existe des différences clés dans le déploiement : Baidu et ByteDance sont plus agressifs. Baidu tente une approche C-end, intégrant plusieurs modèles IA et outils externes via le ‘Xinxiang’ (Kokone) tirant parti du protocole MCP, principalement pour les appareils mobiles, pour s’intégrer dans la vie quotidienne des utilisateurs et encourager l’adoption.
Kouzi Space de ByteDance dispose de plus de 60 plugins d’extension MCP. Accessible via une page Web, il a également lancé un IDE natif IA, Trae, qui prend en charge MCP, ciblant principalement les scénarios de productivité.
Alibaba a intégré le protocole MCP dans des produits comme Alipay, permettant l’invocation d’outils IA en un seul clic, et a publié en open source le modèle Qwen3, qui prend en charge le protocole MCP, améliorant ainsi ses capacités Agent.
Les développeurs de Tencent Cloud ont publié une suite de développement IA qui prend en charge les services d’hébergement de plugins MCP. Le moteur de connaissances de grand modèle de Tencent Cloud permet aux utilisateurs d’appeler des plugins MCP. L’agent intelligentde développement logiciel Craft lancé par CodeBuddy de Tencent Cloud est compatible avec l’écosystème ouvert MCP. De plus, Tencent Maps et Tencent Cloud Storage ont publié leur propre SERVEUR MCP.
L’utilisation des outils IA peut évoluer d’un fonctionnement direct et unitaire de l’outil à une collaboration professionnelle d’Agent, tout comme les styles de programmation ont évolué du langage assembleur à l’orientation objet.
Dans ce paradigme, le MCP peut simplement devenir une partie de l’infrastructure sous-jacente, au lieu d’une interface orientée utilisateur ou développeur. Un plan plus complet peut nécessiter des architectures comme Agent to Agents (A2A) pour améliorer la planification des tâches et l’efficacité de la sélection des outils en augmentant les niveaux d’abstraction.
En ramenant le MCP à son rôle de ‘protocole’, nous pouvons reconnaître son véritable pouvoir pour stimuler la normalisation de l’industrie : cela peut être le moment de ‘dé-mystification’ le plus précieux de l’évolution technologique.