Le développement de l’IA générative connaît une évolution importante. Les premières applications se concentraient principalement sur la génération de texte, les questions-réponses fondées sur les connaissances et le traitement de contenu. Les Agents d’IA de nouvelle génération commencent toutefois à prendre en charge des tâches plus complexes, telles que l’interrogation de bases de données externes, l’appel de systèmes métier, l’analyse d’informations en temps réel, l’exécution de workflows et la réalisation d’actions spécifiques avec l’autorisation de l’utilisateur. Cette évolution signifie que la concurrence entre les applications d’IA ne dépend plus uniquement de la capacité des modèles à générer des réponses exactes. Elle dépend également de leur capacité à accéder efficacement à des informations externes et à transformer leurs capacités de raisonnement en actions exécutables.
Cependant, des obstacles à la connexion entre les capacités des modèles et les systèmes externes existent depuis longtemps. Les différentes applications disposent généralement de leurs propres interfaces de données, méthodes d’appel d’outils, mécanismes d’authentification et systèmes de gestion des autorisations. Si les développeurs souhaitent qu’un assistant IA se connecte simultanément à plusieurs sources de données et systèmes métier, ils doivent souvent écrire un code d’intégration distinct et maintenir en continu la compatibilité avec différentes interfaces. À mesure que le nombre d’outils et d’applications de modèles augmente, cette approche d’intégration un à un entraîne des coûts de développement et de maintenance importants. Elle complique également la réutilisation des capacités des Agents d’IA sur différentes plateformes.
Le protocole Model Context Protocol (MCP) a attiré l’attention dans ce contexte. Il s’agit d’un protocole ouvert conçu pour standardiser la manière dont les applications d’IA se connectent à des sources de données, des outils et du contexte externes. MCP n’entraîne pas les modèles et ne détermine pas la manière dont les applications d’IA doivent raisonner. Il fournit plutôt un mécanisme de communication relativement unifié qui permet aux applications d’IA de découvrir et d’utiliser les capacités fournies par des systèmes externes. Son importance réside dans la fourniture d’une couche de connectivité commune à l’écosystème des Agents, permettant aux modèles de passer d’environnements conversationnels relativement fermés à des environnements applicatifs dans lesquels ils peuvent collaborer avec des systèmes logiciels du monde réel.
Points clés
-
MCP traite de la standardisation de la connectivité : il réduit la nécessité de développer individuellement des interfaces dédiées entre les applications d’IA et différents outils externes, mais ne gère pas le raisonnement des modèles ni les décisions métier.
-
MCP utilise une architecture Host, Client et Server : l’application d’IA coordonne les connexions, le Client gère la communication du protocole et le Server fournit à l’application des données, des outils ou des modèles de prompts.
-
Les Tools, Resources et Prompts constituent ses capacités principales : ils prennent respectivement en charge les appels d’opérations externes, l’accès aux données contextuelles et les modèles d’interaction réutilisables.
-
MCP facilite le passage des Agents du traitement de l’information à l’exécution de tâches : toutefois, la capacité des outils à accomplir des tâches de manière sûre et précise dépend toujours de la conception des autorisations, de la qualité des données et des workflows d’exécution.
-
Une connectivité standardisée n’établit pas automatiquement la confiance : l’authentification, l’autorisation, la confirmation par l’utilisateur, la journalisation et les contrôles des risques restent des éléments essentiels des déploiements réels.
Pourquoi les Agents d’IA ont-ils besoin d’un protocole de connectivité standardisé ?
Les modèles d’IA ne disposent pas intrinsèquement de la capacité d’accéder à des systèmes logiciels externes. Un modèle peut générer une analyse à partir de ses données d’entraînement et du contexte actuel. Toutefois, s’il doit consulter le solde en temps réel d’un compte, lire les derniers enregistrements d’une base de données ou soumettre une opération à un service externe, il doit le faire par le biais d’interfaces fournies au niveau applicatif. Le modèle est chargé de comprendre la tâche et de générer l’intention d’effectuer un appel, tandis que les outils externes accèdent aux données ou exécutent les opérations. Un mécanisme de communication clair est nécessaire entre eux.
En l’absence de norme de connectivité unifiée, chaque application d’IA peut utiliser une méthode d’intégration différente. Une application peut se connecter à une base de données via des appels de fonctions personnalisés, tandis qu’une autre peut se connecter à un système métier via une API dédiée. Certaines applications peuvent nécessiter des plugins ou des middleware supplémentaires. Même lorsque différentes applications appellent finalement le même service externe, elles peuvent encore devoir maintenir plusieurs ensembles de logique d’intégration d’interface. Cette structure fragmentée complexifie l’intégration des outils et accroît la charge de compatibilité lors des mises à niveau des systèmes.
La valeur de MCP réside dans le passage d’une connectivité propre à chaque application à une couche de protocole plus universelle. Les services externes peuvent exposer leurs données ou fonctionnalités par le biais de MCP Servers, tandis que les applications d’IA compatibles avec MCP peuvent se connecter à ces services via des Clients. Les développeurs n’ont pas besoin de concevoir un mécanisme de connectivité entièrement indépendant pour chaque application de modèle. Ils peuvent plutôt réutiliser les implémentations de Server existantes basées sur les spécifications du protocole.
Cette standardisation peut générer des effets de réseau. À mesure que davantage d’applications d’IA prennent en charge le même protocole, les services externes peuvent atteindre un éventail plus large d’environnements applicatifs. À mesure que davantage de services fournissent des interfaces MCP, les applications d’IA peuvent accéder à une plus grande variété d’outils et de sources de données. Les développeurs d’outils, les plateformes de modèles et les utilisateurs finaux peuvent ainsi former un écosystème qui se renforce mutuellement. Toutefois, la standardisation ne peut que réduire les coûts de connectivité. Elle ne peut pas garantir que tous les outils présentent le même niveau de qualité des données, de stabilité ou de sécurité.
La relation entre MCP et les Agents d’IA eux-mêmes doit également être distinguée. MCP n’est ni un framework d’Agent ni un moteur autonome de prise de décision. Il traite principalement de la manière dont le contexte et les outils sont transmis entre différents composants logiciels. La manière dont un Agent comprend les objectifs, décompose les tâches, sélectionne les outils, évalue les résultats et décide de poursuivre ou non l’exécution dépend toujours des capacités du modèle, de la conception de l’application et des mécanismes de contrôle des workflows. MCP fournit une connectivité aux Agents, mais ne remplace pas leur logique de planification et d’exécution.
MCP utilise une architecture combinant Clients et Servers. Ses principaux participants comprennent les Hosts, les Clients et les Servers. Un Host est une application qui fournit des capacités d’IA, telle qu’un assistant de bureau, un environnement de développement ou une autre application d’Agent. Un Client est un composant au sein du Host qui établit des connexions avec des MCP Servers. Un Server fournit des données externes, des outils ou des modèles d’interaction au Client. Ensemble, ces trois éléments constituent le chemin de connexion entre les applications d’IA et les systèmes externes.
Le Host coordonne généralement le processus global. Il reçoit les données saisies par l’utilisateur, fournit le contexte pertinent au modèle et gère un ou plusieurs MCP Clients selon les besoins du modèle. Une application d’IA peut se connecter simultanément à plusieurs MCP Servers, tels que des systèmes de fichiers, des référentiels de code, des bases de données et des services de données de marché. Chaque connexion est maintenue par son composant Client correspondant, ce qui permet à l’application d’utiliser les capacités de différents services dans un environnement d’interaction unifié.
Le Client est chargé de la communication du protocole et de la gestion des connexions. Il doit comprendre les capacités fournies par le Server, envoyer des requêtes conformément aux structures de messages définies par MCP et recevoir les résultats correspondants. Un Client n’est pas identique au modèle. Il s’agit d’un composant du Host qui gère la connectivité du protocole. Le modèle peut décider d’utiliser un outil particulier en fonction du contexte, mais l’interaction réelle avec le protocole est effectuée par le Client et le Server.
Le Server fournit des capacités externes. Il peut se connecter à une base de données, encapsuler un ensemble d’API ou fournir un point d’accès unifié pour un système métier spécifique. Un Server n’a pas nécessairement besoin de capacités sophistiquées de raisonnement par IA. Sa tâche principale consiste à exposer les fonctionnalités des systèmes externes conformément aux exigences du protocole afin que les Clients compatibles puissent découvrir et utiliser ces capacités.
Cette architecture sépare le raisonnement du modèle, la coordination de l’application et l’accès aux systèmes externes. Le modèle n’a pas besoin de comprendre l’implémentation interne de chaque base de données ou API métier, et le Host n’a pas besoin de concevoir une méthode de communication entièrement différente pour chaque service. Tant que tous les participants respectent les exigences du protocole, les outils deviennent plus faciles à réutiliser et à maintenir.
D’un point de vue technique, la couche de données de MCP utilise JSON-RPC pour l’échange de messages et définit les requêtes, les réponses, les notifications et les descriptions de capacités associées. La couche de transport établit des canaux de communication et transmet les messages. Différents environnements de déploiement peuvent utiliser des méthodes de transport adaptées à leurs scénarios, telles que la communication interprocessus locale ou les connexions HTTP distantes. Pour les déploiements en entreprise, les méthodes de connexion, l’authentification et les mécanismes d’autorisation sont tout aussi importants, car les outils externes peuvent accéder à des données sensibles ou même être autorisés à exécuter des opérations métier réelles.
L’une des caractéristiques de conception les plus importantes de MCP consiste à répartir les capacités fournies par les systèmes externes en différents types. Les Tools, Resources et Prompts ne sont pas trois types de modèles différents. Ce sont trois types d’interfaces de contexte et de fonctionnalités. Ils correspondent respectivement à l’exécution d’opérations, à l’accès aux données et aux modèles d’interaction, ce qui permet aux applications d’IA de sélectionner les capacités appropriées selon la tâche.
Les Tools sont les capacités MCP les plus étroitement associées à l’exécution des tâches. Un Server peut exposer des fonctions spécifiques via des interfaces d’outils, telles que l’interrogation de bases de données, l’appel d’API externes, le calcul de données, la recherche d’enregistrements ou la soumission d’une opération. Les Tools disposent généralement de noms clairs, de descriptions de leur objectif et de structures de paramètres d’entrée. Les Clients peuvent découvrir les outils disponibles et lancer des appels lorsque cela est approprié.
Par exemple, un Agent de recherche financière peut devoir consulter les données de marché d’un actif, obtenir des prix historiques ou lire les enregistrements de transactions d’un compte spécifié. Le service concerné peut regrouper ces capacités sous forme de différents outils. Le modèle sélectionne l’appel approprié en fonction de la tâche de l’utilisateur, et le MCP Client envoie la requête au Server correspondant. Après l’exécution de l’opération par le Server, celui-ci renvoie le résultat, et l’application le fournit au modèle pour une analyse supplémentaire.
L’importance des Tools ne se limite pas à donner aux modèles accès à davantage de fonctionnalités. Plus important encore, les Tools confèrent aux appels d’outils une structure relativement claire. Par rapport au recours exclusif aux modèles pour générer des instructions en langage naturel, les interfaces d’outils structurées peuvent définir les types de paramètres et les limites d’appel, réduisant ainsi certains types d’opérations ambiguës. Toutefois, des paramètres correctement formatés ne signifient pas nécessairement qu’une opération est sûre. L’exécution d’outils requiert toujours des vérifications d’autorisations, la validation des entrées et la confirmation nécessaire de l’utilisateur.
Resources : fournir un contexte externe aux modèles
Les Resources sont principalement utilisées pour fournir aux applications d’IA des données ou du contenu lisibles. Elles peuvent représenter des fichiers, des enregistrements de base de données, des documents, des informations métier ou d’autres ressources externes. Alors que les Tools mettent l’accent sur l’exécution d’opérations, les Resources se concentrent sur la fourniture du contexte dont les modèles ont besoin pour accomplir des tâches.
Par exemple, un Agent de développement peut lire les fichiers d’un projet et les structures de code, un assistant d’entreprise peut accéder aux documents d’une base de connaissances interne, et un outil de recherche financière peut lire des enregistrements de données autorisés. Le modèle utilise ce contenu pour comprendre la tâche actuelle et générer une analyse à partir de la question de l’utilisateur.
Les Resources peuvent réduire la dépendance d’un modèle aux connaissances statiques issues de son entraînement et lui permettre de travailler avec des données externes. Toutefois, l’accès aux données ne signifie pas que ces données sont intrinsèquement fiables. Le contenu externe peut être obsolète, contenir des erreurs ou inclure des instructions malveillantes. Les applications doivent déterminer comment traiter le contenu selon sa source, ses autorisations d’accès et sa nature. Elles ne doivent pas considérer tout texte récupéré comme une instruction fiable.
Prompts : fournir des modèles d’interaction réutilisables
Les Prompts constituent un autre type de capacité pris en charge par MCP. Ils sont principalement utilisés pour fournir des modèles de prompts et des structures d’interaction réutilisables. Un Server peut fournir des modèles adaptés à des scénarios métier spécifiques, afin d’aider les applications d’IA à organiser plus systématiquement les entrées et le contexte des tâches.
Par exemple, un système d’entreprise peut fournir un modèle permettant de générer des synthèses de réunions, tandis qu’un service d’analyse de données peut fournir une structure de prompt pour expliquer les résultats d’une requête. Au besoin, l’application récupère le modèle et le combine avec les données saisies par l’utilisateur et les données réelles afin d’organiser la tâche. Cela réduit la nécessité de rédiger à plusieurs reprises le contenu des prompts et facilite la réutilisation des méthodes d’interaction pour des scénarios métier spécifiques.
Toutefois, les Prompts ne constituent pas des workflows complets. Ils peuvent aider à organiser les entrées du modèle, mais ne peuvent pas garantir indépendamment l’exactitude des résultats du modèle ni remplacer les règles métier et les contrôles d’autorisations. Lorsque les trois capacités sont utilisées conjointement, MCP peut prendre en charge de manière plus complète le processus allant de l’obtention du contexte à l’appel d’outils externes.
Les assistants d’IA traditionnels s’articulent généralement autour des saisies de l’utilisateur et des résultats du modèle, la plupart des interactions se déroulant dans une fenêtre de chat. Les Agents peuvent appeler des outils externes en plus du raisonnement du modèle et exécuter des tâches en plusieurs étapes en fonction des objectifs de l’utilisateur. MCP fournit une méthode standardisée pour connecter ces outils, facilitant l’intégration de différents services par les Agents dans un même workflow de tâches.
Un workflow d’Agent typique peut être divisé en plusieurs étapes. L’application reçoit d’abord l’objectif de l’utilisateur et le fournit au modèle pour interprétation. Le modèle identifie ensuite les données ou outils nécessaires à la tâche. Le Host interroge les capacités disponibles via le MCP Client concerné et fournit au modèle les informations appropriées sur les outils. Le modèle génère une requête d’appel, et le Client envoie la requête au Server. Le Server exécute l’opération et renvoie le résultat. Enfin, le modèle poursuit son analyse à partir des données renvoyées par l’outil et effectue un autre appel si nécessaire, jusqu’à ce que la tâche soit terminée ou qu’une intervention de l’utilisateur soit requise.
Ce modèle permet aux Agents de décomposer des tâches complexes en plusieurs étapes exécutables. Par exemple, lorsqu’un utilisateur demande une analyse d’un projet, l’Agent peut d’abord consulter les informations du projet, puis récupérer les données de marché, appeler un outil de calcul à des fins de comparaison et enfin générer un rapport structuré. Chaque étape peut être prise en charge par un service externe différent, tandis que MCP fournit une méthode relativement cohérente pour connecter ces services aux applications d’IA.
MCP peut également modifier la manière dont les services logiciels sont conçus comme produits. Par le passé, les fournisseurs de services concevaient généralement des interfaces web, des procédures opérationnelles et des API destinées aux utilisateurs humains. À mesure que les Agents deviennent progressivement un nouveau point d’entrée pour l’utilisation de logiciels, les capacités de service doivent également être compréhensibles et appelables par des machines. Un MCP Server peut servir d’interface de capacités pour les applications d’IA, permettant aux services externes de fournir des fonctionnalités aux Agents de manière structurée.
Toutefois, la capacité d’appeler des outils ne signifie pas qu’un Agent peut exécuter des tâches de manière autonome sans restrictions. Pour les opérations à faible risque, telles que la lecture de données publiques ou l’organisation de fichiers, le niveau d’automatisation peut être relativement élevé. Pour les opérations impliquant les fonds d’un compte, les transferts d’actifs, la soumission d’ordres ou des informations sensibles, une conception plus stricte des autorisations et des procédures de confirmation sont nécessaires. Le niveau d’autonomie d’un Agent doit correspondre au risque de la tâche, plutôt que de chercher simplement à réduire l’intervention humaine.
Limites de sécurité de MCP : plus la connectivité est étendue, plus la gestion des autorisations devient importante
MCP abaisse la barrière permettant aux applications d’IA de se connecter à des services externes, mais il permet également aux modèles d’accéder à davantage de données et d’interfaces opérationnelles. À mesure que la connectivité s’étend, les systèmes sont confrontés à des risques qui vont au-delà de résultats erronés du modèle, notamment l’accès non autorisé aux données, les appels d’outils non souhaités, l’injection de contenu malveillant, la fuite d’identifiants et l’utilisation abusive de services externes.
L’authentification et la gestion des autorisations exigent une attention particulière. Lorsqu’un MCP Client établit une connexion avec un Server, il doit vérifier la cible de connexion et ses autorisations d’accès. Pour les services distants, l’authentification, le périmètre d’autorisation et la gestion des identifiants sont particulièrement importants. Les applications ne doivent pas exposer tous les outils au modèle par défaut. Elles doivent plutôt configurer les capacités accessibles en fonction de l’identité de l’utilisateur, des exigences de la tâche et du niveau de risque. Les autorisations en lecture seule et les autorisations permettant d’effectuer des opérations financières doivent être clairement séparées, et les opérations sensibles ne doivent pas dépendre uniquement du modèle pour déterminer si elles doivent être exécutées.
L’injection de prompts et le contexte malveillant doivent également être pris en compte. Un Agent peut lire du contenu provenant de pages web, de documents, d’enregistrements de bases de données ou de services tiers. Ce contenu peut contenir des instructions malveillantes visant à modifier le comportement du modèle. Si un système ne peut pas distinguer les données externes des instructions fiables, un contenu non fiable peut l’inciter à appeler des outils ou à divulguer des informations. Les applications doivent donc isoler et étiqueter le contenu externe, et éviter d’élever directement le texte de sources de données au rang d’instructions hautement prioritaires.
Les outils eux-mêmes peuvent également devenir des vecteurs d’attaque. Un Server malveillant ou incorrectement configuré peut fournir des outils dotés d’autorisations excessives ou accéder à des ressources au-delà du périmètre attendu lors de l’exécution d’une opération. Les développeurs doivent examiner la source du Server, l’implémentation de son code, son périmètre d’autorisations et ses pratiques de traitement des données, puis mettre en place des mécanismes de mise à jour et de surveillance lors du déploiement. Pour les MCP Servers tiers, le simple respect du protocole ne suffit pas à supposer qu’ils sont sûrs et fiables.
Pour les applications impliquant des actifs financiers, les contrôles des risques doivent également couvrir la confirmation des transactions, les autorisations liées aux fonds et l’audit des opérations. Les modèles peuvent aider les utilisateurs à consulter des informations de marché, organiser des données sur les actifs ou générer des plans de trading. Toutefois, avant de soumettre un ordre, de transférer des fonds ou d’exécuter une opération irréversible, le système doit mettre en place des mécanismes de confirmation adaptés au risque métier. Le système doit clairement enregistrer qui a initié l’opération, quels outils le modèle a appelés, quels paramètres il a utilisés et quel a été le résultat final de l’exécution.
Ainsi, la sécurité de MCP ne peut pas être garantie par le protocole seul. Les spécifications du protocole, l’implémentation du Client, la fiabilité du Server, l’autorisation d’identité et les contrôles des risques au niveau applicatif déterminent conjointement le niveau final de sécurité. La connectivité standardisée fournit des limites techniques plus claires, mais les déploiements réels nécessitent toujours des examens de sécurité continus et une gestion des responsabilités.
Valeur à long terme de MCP : d’une norme d’interface à une infrastructure pour l’écosystème des Agents
La valeur à long terme de MCP ne réside pas uniquement dans la réduction du volume de code d’intégration d’interfaces que les développeurs doivent écrire. Il peut également contribuer à établir de nouvelles formes de collaboration entre les applications d’IA et les services logiciels. À mesure que davantage d’outils et de sources de données fournissent des capacités par le biais d’un protocole unifié, les Agents pourraient être en mesure d’accomplir des tâches entre différentes applications et systèmes métier, au lieu d’être limités aux fonctionnalités d’un seul produit.
Cette évolution peut également influencer la manière dont les fournisseurs de services logiciels se font concurrence. Par le passé, les fournisseurs de services attiraient principalement des clients grâce aux interfaces utilisateur, à la conception des fonctionnalités et aux écosystèmes d’API. À l’avenir, la capacité d’être découvert, compris et appelé de manière fiable par des Agents d’IA pourrait également devenir un élément important des capacités d’un service. Les fournisseurs de services doivent réfléchir à la manière de décrire les fonctionnalités des outils, de limiter les autorisations d’accès, de fournir des structures de données fiables et de garantir que les outils puissent fonctionner de manière sûre dans des scénarios automatisés.
Pour les développeurs, MCP peut réduire les coûts d’intégration entre différentes applications de modèles, mais il ne rendra pas automatiquement tous les outils compatibles. Les versions de protocole, les capacités prises en charge, les méthodes de transport, les mécanismes d’authentification et la qualité de l’implémentation peuvent encore varier. Le développement continu de l’écosystème dépendra de la stabilité des spécifications, de la qualité des outils, de l’adoption par les développeurs et de l’interopérabilité entre différentes plateformes.
Pour les entreprises, la valeur de MCP dépend de sa capacité à résoudre des problèmes métier réels. La connexion de bases de connaissances internes, de systèmes de gestion de la relation client, de plateformes d’analyse et d’outils métier aux Agents peut améliorer la recherche d’informations et la collaboration entre systèmes. Toutefois, les entreprises doivent également gérer les autorisations relatives aux données, la protection de la vie privée, les exigences de conformité et les responsabilités d’audit. Plus la connectivité technique devient pratique, plus il est important de préciser quelles données sont accessibles, quelles opérations peuvent être effectuées et qui est responsable en cas d’erreur.
Dans une perspective plus large, MCP représente une tendance selon laquelle les applications d’IA étendent leurs capacités, d’un modèle unique vers une collaboration au niveau du système. Les modèles fournissent la compréhension et le raisonnement, les outils fournissent des capacités d’action externes, les protocoles fournissent la connectivité et les applications assurent la coordination et le contrôle. À l’avenir, la concurrence au sein de l’écosystème des Agents pourrait se jouer non seulement au niveau des modèles, mais aussi sur la qualité des outils, l’infrastructure, les mécanismes de sécurité, les réseaux de services et d’autres domaines.
Le lien entre MCP et l’écosystème IA de Gate
La valeur fondamentale de MCP réside dans la fourniture d’une méthode standardisée permettant aux applications d’IA de se connecter à des outils et services externes. Le secteur des cryptomonnaies dépend lui-même fortement des outils et des données. Les données de marché, les informations sur les actifs, les wallets, les données on-chain, les services de trading et les fonctionnalités de paiement sont répartis entre différents systèmes. Si les Agents d’IA doivent participer à ces scénarios, ils ont besoin de capacités stables d’accès aux données et d’appel d’outils. Par conséquent, l’association de MCP et du secteur des cryptomonnaies représente une direction dans laquelle les Agents d’IA peuvent évoluer, passant d’assistants d’information à des couches de coordination pour les outils financiers.
Gate for AI Agent constitue une application spécifique de cette orientation. Selon la présentation officielle de Gate, son architecture combine Gate Skills, CLI, MCP et d’autres outils afin de fournir aux Agents d’IA des capacités liées au trading, aux données de marché, aux wallets, aux actualités et à l’analyse on-chain. Son architecture sépare les couches d’application, de capacités, de protocole et d’infrastructure. MCP et CLI sont positionnés dans la couche de connectivité des protocoles, tandis que les Skills servent à organiser et orchestrer les capacités associées. Cette approche en couches aide à expliquer comment les Agents peuvent se connecter aux services crypto par le biais d’interfaces standardisées et comment différents outils peuvent fonctionner ensemble pour prendre en charge des tâches plus complexes.
Gate.AI fournit un point d’entrée d’interaction IA destiné aux utilisateurs, MCP et Skills figurant parmi ses capacités sous-jacentes. Les utilisateurs peuvent soumettre des questions ou des tâches en langage naturel, et l’application d’IA peut traiter les requêtes concernées à l’aide des capacités disponibles. Pour les utilisateurs, l’intérêt de ces produits ne réside pas simplement dans l’ajout d’une interface de chat supplémentaire. Ils facilitent plutôt l’accès aux informations de marché, à l’analyse des actifs et à certaines fonctions métier grâce à une méthode d’interaction unifiée.
Toutefois, connecter des Agents d’IA aux capacités de trading et de wallet implique également de prendre au sérieux les limites des autorisations. Les utilisateurs doivent comprendre à quelles données un Agent peut accéder, quelles opérations il peut effectuer, comment l’autorisation est gérée et si les tâches impliquant des fonds et le trading nécessitent une confirmation supplémentaire. L’interaction en langage naturel abaisse la barrière d’utilisation de ces fonctions, mais elle ne peut pas remplacer le jugement de l’utilisateur concernant les conditions de trading, les risques et les résultats finaux de l’exécution.
Il est important de préciser que MCP est un protocole ouvert, tandis que l’utilisation de MCP et d’outils d’Agent par Gate constitue une implémentation spécifique à son écosystème. Les autorisations des outils, le périmètre des services et les mécanismes d’exécution varient selon les plateformes. Lors de l’utilisation de fonctionnalités associées, les utilisateurs doivent se référer aux capacités effectivement prises en charge par le produit, à ses instructions d’autorisation et à ses informations sur les risques.
À long terme, le développement des Agents d’IA dépendra non seulement des capacités de raisonnement des modèles, mais aussi de leur capacité à se connecter de manière fiable à des services externes et à accomplir des tâches dans le cadre d’autorisations clairement définies. MCP fournit une base standardisée pour cette connectivité, tandis que Gate for AI Agent illustre les applications potentielles de cette orientation technique dans les outils de marché crypto, les données et les scénarios de trading.
FAQ
Qu’est-ce que MCP ?
MCP (Model Context Protocol) est un protocole ouvert utilisé pour standardiser les connexions entre les applications d’IA et les sources de données, outils et contextes externes. Il aide les applications d’IA à découvrir et utiliser des services externes de manière relativement cohérente, mais ne gère ni l’entraînement des modèles ni la prise de décision autonome.
En quoi MCP est-il différent d’une API ?
Une API définit généralement l’interface qu’un service particulier fournit en externe, tandis que MCP standardise davantage la manière dont les applications d’IA se connectent et interagissent avec les capacités des services externes. Un MCP Server peut appeler des API existantes en interne, puis exposer des outils ou des données aux applications d’IA par le biais d’un protocole unifié.
Quelles sont les responsabilités du Host, du Client et du Server dans MCP ?
Le Host est l’application qui fournit les capacités d’IA et coordonne les tâches. Le Client établit une connexion au protocole avec le MCP Server. Le Server fournit des outils, des ressources ou des modèles de prompts au Client. Ensemble, ils gèrent la communication entre l’application d’IA et les services externes.
Les Tools servent à appeler des opérations externes, les Resources fournissent des données et du contexte, et les Prompts fournissent des modèles de prompts réutilisables. Ils prennent respectivement en charge l’exécution, la récupération d’informations et l’organisation des interactions.
MCP signifie-t-il que les Agents d’IA peuvent exécuter des tâches de manière entièrement autonome ?
Non. MCP fournit une connectivité aux outils, mais le niveau d’autonomie d’un Agent dépend du modèle, de la conception de l’application, de la configuration des autorisations et des contrôles des risques. Des mécanismes d’autorisation et de confirmation appropriés doivent toujours être mis en place pour les opérations impliquant des fonds, le trading et des données sensibles.
MCP est-il disponible uniquement pour Claude d’Anthropic ?
Non. MCP est un protocole ouvert conçu pour standardiser les connexions entre différentes applications d’IA et outils externes. La prise en charge de MCP dépend de l’implémentation de l’application et de l’outil concernés.
Que signifie MCP pour le secteur des cryptomonnaies ?
Le secteur des cryptomonnaies couvre un large éventail de services, notamment les données de marché, les wallets, le trading, l’analyse on-chain et les paiements. MCP peut fournir une méthode standardisée permettant aux Agents d’IA de se connecter à ces capacités externes, ce qui leur facilite les requêtes d’informations entre outils et les workflows métier.
