« MCP vs API » peut donner l’impression d’un choix entre deux technologies concurrentes. Or, elles s’inscrivent dans la même pile. Une API expose les capacités d’un système. Un serveur MCP peut alors mettre certaines de ces capacités à la disposition d’applications d’IA, que ces capacités proviennent d’une API, d’une base de données, de fichiers locaux ou d’une autre source.
La question n’est donc pas de savoir si le MCP remplacera les API ou en quoi elles diffèrent intrinsèquement. Il s’agit plutôt de déterminer ce que chaque couche vous apporte, où chacune d’elles ajoute de la complexité, et dans quels cas il est plus judicieux d’utiliser les deux plutôt que d’en choisir une seule.
« MCP vs API » peut donner l’impression d’un choix entre deux technologies concurrentes. Or, elles s’inscrivent dans la même pile. Une API expose les capacités d’un système. Un serveur MCP peut alors mettre certaines de ces capacités à la disposition d’applications d’IA, que ces capacités proviennent d’une API, d’une base de données, de fichiers locaux ou d’une autre source.
La question n’est donc pas de savoir si le MCP remplacera les API ou en quoi elles diffèrent intrinsèquement. Il s’agit plutôt de déterminer ce que chaque couche vous apporte, où chacune ajoute de la complexité, et dans quels cas il est plus judicieux d’utiliser les deux plutôt que d’en choisir une seule.
En bref
Le choix entre MCP et API dépend de l'identité de l'appelant. Une API est plus adaptée lorsque votre code contrôle le chemin d'accès, que la séquence est connue et que vous souhaitez des appels directs et testables. Le MCP est plus adapté lorsqu'un système d'IA doit choisir parmi les actions disponibles à mesure que la requête évolue.
La plupart des équipes développant des produits axés sur l’IA proposeront les deux. L’API reste l’interface complète destinée aux développeurs. Le serveur MCP expose un sous-ensemble plus restreint et bien défini que les agents peuvent découvrir et appeler de manière autonome. Aucun des deux ne remplace l’autre ; ils s’adressent à des utilisateurs différents d’une même fonctionnalité.
Un élément à prendre en compte avant la validation : le MCP entraîne un coût de jeton par appel, qu’un outil soit utilisé ou non. Des tests de performance réalisés sur cinq familles de modèles montrent qu’un serveur de 26 outils ajoute environ 0,03 $ à chaque requête sur Claude Opus, mais seulement 0,003 $ sur Gemini Flash, soit un écart de 10 fois selon le modèle. Cette surcharge est récupérable grâce à la mise en cache, mais cela signifie que le profil de coût du MCP est une variable de conception, et non une constante.
MCP vs API : aperçu général
| Fonctionnalité/Catégorie | API | MCP |
|---|---|---|
| Cas d'utilisation principal | Connecter des logiciels via des interfaces programmatiques définies | Connectez les applications IA à des outils, des données et des systèmes externes |
| Qui contrôle le flux ? | C'est généralement la logique applicative qui détermine ce qui est appelé | Un hôte IA peut choisir parmi les capacités exposées lors de l'exécution |
| Découverte | L'intégration commence généralement par des points de terminaison ou des schémas connus | Le client peut demander au serveur quelles sont les fonctionnalités disponibles |
| Effort d'intégration | Cela varie souvent en fonction du prestataire, du modèle d'authentification, du schéma et du style d'API. | Utilise un protocole unique sur l'ensemble des serveurs et clients compatibles MCP |
| Orchestration | Généralement conçues et gérées au sein du code de l'application | Certaines décisions peuvent être transférées vers l’hôte ou l’agent IA |
| Déterminisme | Convient mieux aux chemins d'appel fixes qui doivent être faciles à tester et à reproduire | La sélection de l'outil peut varier lorsqu'un modèle décide de l'action à entreprendre |
| Performances et coûts | Les appels directs évitent une inférence supplémentaire du modèle | L'utilisation d'agents peut allonger le temps d'inférence et augmenter le coût en jetons |
| Modèle de sécurité | Les permissions et les chemins d'appel sont généralement gérés au niveau de la logique applicative | Nécessite les mêmes contrôles, ainsi que des mesures de protection concernant l'utilisation d'outils pilotés par des modèles |
| Peuvent-ils travailler seuls ? | Oui | Oui, même si les serveurs MCP exposent souvent des fonctionnalités s'appuyant sur des API ou des systèmes existants |
| Où ça coince | Les intégrations entre différents prestataires peuvent nécessiter des schémas, des mécanismes d’authentification et des logiques d’orchestration différents. | L'assistance pour les clients varie, les vastes catalogues d'outils nécessitent une gestion du contexte, et la spécification est encore en cours d'évolution |
Qu'est-ce que le MCP ?
Le MCP, ou Model Context Protocol, est une norme ouverte qui offre aux applications d’IA un moyen commun de découvrir et d’utiliser des outils, des données et des services externes.
Comment fonctionne le MCP ?
Au lieu de coder en dur toutes les actions possibles, un client MCP peut demander à un serveur connecté ce qu’il propose. Le serveur renvoie alors un catalogue d’outils comprenant leurs noms, leurs descriptions et leurs schémas d’entrée. Le modèle d’IA peut ensuite déterminer quel outil correspond à la demande de l’utilisateur.
À noter : les outils constituent la partie du MCP qui s'apparente le plus aux actions API. Mais les serveurs MCP peuvent également exposer des ressources, telles que des fichiers ou des enregistrements de base de données, ainsi que des invites, qui sont des instructions ou des modèles réutilisables qu'une application d'IA peut demander.
La découverte à l'exécution est l'un des principaux avantages du MCP. Au lieu d'apprendre un modèle d'intégration différent pour chaque service, le client dispose d'une méthode standard pour identifier les fonctionnalités offertes par un serveur et les invoquer en cas de besoin.
Anthropic a lancé le MCP en novembre 2024 et en a fait don à l'Agentic IA Foundation, rattachée à la Linux Foundation, en décembre 2025.
Dans quels cas le MCP est-il le plus adapté ?
Le MCP s'avère particulièrement pertinent lorsqu'un assistant ou un agent IA doit accéder à plusieurs outils et choisir lequel utiliser au moment de l'exécution.
Destiné à : les agents IA, les assistants de codage, les copilotes internes et les systèmes devant fonctionner avec plusieurs outils en constante évolution.
À ignorer si : votre application ne nécessite qu'un petit nombre d'intégrations fixes et que le flux de travail est déjà connu à l'avance.
Qu'est-ce qu'une API ?
Une API (interface de programmation d’application) est un contrat publié. Un fournisseur s’engage à fournir un ensemble d’opérations, à définir la forme de chaque requête et à préciser la réponse renvoyée. Votre code lit ce contrat une seule fois et l’appelle de la même manière à chaque fois.
Comment fonctionnent les API ?
En général, un développeur consulte la documentation de l'API, choisit un point de terminaison, définit les paramètres requis, puis écrit le code permettant d'effectuer la requête.
Par exemple, une application peut appeler un point de terminaison pour créer une tâche et un autre pour récupérer la fiche d'un client. L'application sait déjà quel point de terminaison utiliser, car cette logique a été intégrée au logiciel.
À noter : le terme « API » recouvre plusieurs styles incompatibles. REST organise les opérations autour des ressources et des verbes HTTP. GraphQL expose un seul point de terminaison et permet à l’appelant de spécifier les champs qu’il souhaite. gRPC utilise des charges utiles binaires sur HTTP/2 pour les appels de service à service où la latence est un facteur critique.
Ce qui se rapproche le plus d’une norme de description commune, c’est OpenAPI, que de nombreux fournisseurs publient, mais que beaucoup d’autres ne publient pas. Ce dont disposent les API, ce sont environ deux décennies d’outils accumulés : passerelles, tests de contrats, traçage distribué, conventions de gestion des versions et infrastructure de limitation de fréquence que la plupart des équipes d’ingénierie exploitent déjà. Le MCP est encore en train de mettre en place son équivalent.
Quelles sont les API les plus adaptées pour
Les API fonctionnent bien lorsque l'application a besoin d'un accès prévisible à un service connu, et que les développeurs souhaitent contrôler directement ce qui est appelé et à quel moment.
Conçu pour : les intégrations backend, les pipelines de données, les applications web et mobiles, ainsi que les flux de travail comportant des actions fixes.
À ignorer si : vous développez un système d'IA qui doit découvrir et choisir dynamiquement parmi de nombreux outils.
MCP vs API : quelles sont les principales différences ?
Une API et un MCP exposent tous deux des actions, mais ils gèrent la connexion différemment. Les API partent d’une opération connue. Le MCP part d’une question : qu’est-ce qui est disponible ? Il en découle trois différences, et aucune d’entre elles ne porte sur la question de savoir quelle interface l’emporte. Elles portent sur la question de savoir quelle interface gère quel appelant.
Les API commencent par une opération connue
Avec une API, l'application sait déjà de quel point de terminaison elle a besoin. Un développeur définit la requête, configure les paramètres et écrit le traitement de la réponse.
Les API sont donc particulièrement adaptées aux flux de travail fixes. Un paiement est validé, votre système crée une facture. Le chemin d’appel est défini une seule fois, testé, puis réutilisé à chaque fois.
Avec le MCP, toutes les possibilités restent ouvertes. Un client en connexion examine les outils exposés par un serveur, puis les met à la disposition du système d’IA. L’action suivante dépend de la requête de l’utilisateur, et non d’un flux prédéfini.
La couche d'interface fonctionne différemment
Les API se présentent sous de nombreuses formes. Un fournisseur utilise REST, un autre GraphQL, tandis qu'un troisième s'appuie sur un SDK. L'authentification, les erreurs, la pagination et les formats de requête varient d'un service à l'autre.
Le MCP offre aux clients /IA un protocole unique pour effectuer la connexion aux serveurs et lire les données qu’ils exposent. Cela ne rend pas pour autant tous les outils identiques. Deux serveurs peuvent toujours nommer ou concevoir des actions similaires de manière différente. Mais le client n’a pas besoin d’un protocole différent pour chacun d’entre eux.
Le contexte de l'outil influence la manière dont le modèle effectue ses choix
Une description de l’API est fournie aux développeurs et à leur code. L’application sait quoi appeler avant même que la requête ne soit lancée.
Avec le MCP, les noms des outils, leurs descriptions et les schémas d’entrée sont transmis au contexte de travail du modèle. Le modèle lit ces informations, détermine quelle action correspond à la requête et renseigne les arguments.
Cette différence est notamment visible dans les flux de travail des agents, où le système peut être amené à choisir l'action suivante en fonction de la requête plutôt que de suivre une séquence fixe.
Comment choisir entre le MCP et une API
Choisissez entre le MCP et une API en fonction de la manière dont la fonctionnalité doit être exposée. Les API fonctionnent bien lorsque votre application sait déjà quel service ou quelle opération appeler. Le MCP est utile lorsqu'une application IA a besoin d'un moyen standard pour découvrir et utiliser des fonctionnalités sur différents systèmes lors de l'exécution.
Optez pour une API lorsque
- C'est votre code qui est le consommateur, et aucun modèle n'a besoin de choisir l'action à effectuer
- L'opération suit un parcours fixe et contrôlé où le jugement du modèle n'apporte que peu de valeur ajoutée, comme le traitement des paiements, le calcul des salaires ou la déclaration des rapports réglementaires.
- Vous traitez de grands volumes d'enregistrements via un pipeline prévisible, pour lequel les outils classiques d'automatisation des processus constituent la solution la plus simple.
- Le fournisseur expose une fonctionnalité via son API, mais ne l'a pas encore intégrée à son serveur MCP.
Optez pour le MCP lorsque
- Un assistant ou agent IA est l'appelant, et les utilisateurs formulent leurs tâches en langage naturel
- La séquence d'actions passe d'une requête à la suivante, comme dans les flux de travail multi-agents
- Vous souhaitez qu'un seul serveur fonctionne avec plusieurs clients compatibles MCP sans avoir à développer une intégration distincte pour chacun d'entre eux
- Vous souhaitez exposer des outils via un schéma commun que plusieurs clients IA compatibles MCP peuvent découvrir et appeler
À utiliser les deux lorsque : vous êtes un fournisseur au service des développeurs et des agents IA. Conservez l’API comme interface programmatique complète, puis exposez un ensemble plus restreint de fonctionnalités sécurisées pour les agents via le MCP.
Les limites des API
Les API présentent des limites, car chaque intégration est personnalisée ; elles ne peuvent pas s'adapter lorsque les utilisateurs demandent quelque chose que le développeur n'a pas codé ; les flux de travail multi-services vous imposent de gérer l'ensemble de l'orchestration ; et la qualité de la documentation varie d'un fournisseur, prestataire, à l'autre.
- Chaque nouvelle intégration est un travail personnalisé. Chaque API possède son propre schéma d’authentification, sa structure de requête/réponse, son format d’erreur et ses limites de fréquence. Connecter dix services implique d’écrire et de maintenir dix intégrations distinctes. Le rapport « State of the API » de Postman, basé sur un sondage mené auprès de plus de 5 700 développeurs et architectes, a révélé que 69 % d’entre eux consacrent désormais plus de 10 heures par semaine à travailler avec des API. Ce coût s’alourdit à chaque outil que vous ajoutez.
- Aucune flexibilité d’exécution. Une intégration via une API ne peut faire que ce qu’un développeur a déjà programmé. Si un utilisateur demande quelque chose que le code ne prend pas en charge, la requête est bloquée jusqu’à ce que quelqu’un déploie une nouvelle logique. Pour les produits basés sur l’IA, où l’intention de l’utilisateur varie à chaque requête, cette rigidité devient un goulot d’étranglement.
- La charge de l'orchestration vous incombe. Lorsqu'un flux de travail fait appel à plusieurs API, votre application doit tout de même gérer l'ordre des appels, transmettre les données entre les services, gérer les échecs et les nouvelles tentatives, et suivre l'état du système. Les moteurs de flux de travail et les plateformes d'intégration peuvent alléger une partie de cette charge, mais la logique d'orchestration sous-jacente doit tout de même être conçue et maintenue.
- La qualité de la documentation varie énormément. Certaines API sont fournies avec une documentation interactive, des journaux de modifications versionnés et des environnements de test. D’autres se contentent de vous remettre un PDF datant de 2019. L’absence d’une norme universelle de description signifie que chaque intégration commence par une phase de découverte.
À lire également : Les meilleurs connecteurs Claude MCP pour le marketing
Les limites du MCP
Les principales limites du MCP sont la complexité du débogage, des descriptions d’outils qui peuvent ne pas être synchronisées avec le comportement du serveur, l’absence d’un registre universel des serveurs, ainsi que des modèles d’identifiants qui n’ont pas été normalisés pour une utilisation en entreprise.
- Le débogage est plus difficile. Lorsqu’un appel API direct échoue, vous obtenez un code de statut et un corps d’erreur. Lorsqu’un appel à un outil MCP échoue, l’échec peut provenir du raisonnement du modèle, du schéma de l’outil, de la réponse du serveur ou de l’interprétation que fait le client de ces trois éléments. Les outils d’observabilité pour les traces spécifiques au MCP sont limités par rapport à ce qui existe pour REST.
- Les descriptions des outils peuvent s'écarter de leur comportement réel sans pour autant causer de dysfonctionnement. Un serveur MCP peut renommer un paramètre, restreindre une énumération ou restructurer une réponse, tout en renvoyant un JSON valide. Le modèle continue d'appeler l'outil ; l'appel continue de « fonctionner », mais le résultat est erroné. Une étude portant sur 10 831 serveurs MCP a révélé que 73 % d’entre eux comportaient des noms d’outils en double et que 3 093 ne disposaient d’aucune description des valeurs de retour, ce qui creuse l’écart de sélection des outils jusqu’à 52 points de pourcentage lors de comparaisons directes entre des serveurs bien décrits et mal décrits.
- Pas de registre universel. Il n’existe pas de méthode standard pour recenser les serveurs MCP existants ni pour vérifier leur qualité. Les annuaires communautaires se développent, mais la validation d’un serveur tiers nécessite toujours une inspection manuelle de ses métadonnées et de ses permissions.
- La gestion des identifiants manque de modèle standard. La spécification prend en charge OAuth 2.1 pour les serveurs distants, mais de nombreux serveurs communautaires attendent toujours que les clés API soient transmises sous forme de variables d’environnement. Si vous effectuez cinq connexions sur des serveurs MCP, vous gérez cinq flux d’identifiants distincts, sans coffre-fort partagé, sans politique de rotation ni piste d’audit. Des outils d’entreprise dédiés à cela font leur apparition, mais rien n’est encore normalisé.
Rien de tout cela n’est définitif. La spécification évolue rapidement, et les outils suivent le rythme. Mais si vous évaluez aujourd’hui le MCP en vue d’un déploiement en production, basez-vous sur ces contraintes plutôt que de partir du principe qu’elles auront disparu d’ici le lancement.
Appel de l'outil MCP vs requête API directe
Une requête API est envoyée directement à un point de terminaison connu avec des paramètres fixes définis au préalable par votre code. Un appel d’outil MCP encapsule la même action dans une enveloppe JSON-RPC qu’un modèle d’IA sélectionne lors de l’exécution après avoir consulté le catalogue d’outils du serveur. Le serveur MCP exécute ensuite l’appel API sous-jacent pour le compte du modèle.
Voici comment « créer une tâche dans ClickUp » à travers chaque couche.
Via l'API
Votre application connaît déjà l’identifiant de la liste, l’individu assigné et le point de terminaison exact. Elle l’appelle directement.
La réponse est renvoyée avec l’objet de tâche créé. Aucun modèle n’a été utilisé. Le développeur a écrit la logique, choisi le point de terminaison et géré le résultat.
Via MCP
Un client IA se connecte au serveur MCP de ClickUp et demande quels outils existent :
Le modèle lit le schéma, détermine que `create_task` correspond à la requête de l’utilisateur, puis renvoie des arguments structurés :
La même tâche est créée. En arrière-plan, le serveur MCP continue d’appeler l’API REST de ClickUp pour l’exécuter.
Quelles sont les différences concrètes ?
Le résultat est identique. Ce qui a changé, c’est qui a pris la décision.
Avec l’API, votre code connaissait le point de terminaison avant même le début de la requête. Avec le MCP, le modèle lit un catalogue d’outils au moment de l’exécution et choisit create_task parmi plus de 40 outils disponibles en fonction de ce que l’utilisateur a demandé en langage naturel.
Aucune des deux approches n’est meilleure en termes absolus. L’API est plus rapide, moins coûteuse et déterministe. Le MCP est flexible, facile à découvrir et conçu pour les appelants qui s’expriment en langage naturel.
À lire également : Comment rédiger la documentation d'une API
Le MCP est-il avec état ou sans état ?
Selon la spécification du 28 juillet 2026, le cœur du protocole MCP est sans état. La distinction sur laquelle s’appuyaient les anciennes comparaisons (REST est sans état, MCP maintient une session) décrit désormais un mode de transport obsolète.
L'ancienne poignée de main « initialize » et l'en-tête « Mcp-Session-Id » ont disparu. Chaque requête comporte sa propre version de protocole, son identité de client et ses capacités. Tout appel peut aboutir sur n'importe quelle instance de serveur derrière un simple équilibreur de charge de type round-robin. Pas de routage persistant, pas de stockage de session partagé.
La spécification intègre également les noms des méthodes et des outils dans les en-têtes HTTP. Les passerelles, les limiteurs de fréquence et les pare-feu d'applications web (WAF) peuvent désormais acheminer ou mesurer le trafic MCP sans avoir à analyser au préalable le corps JSON.
Lorsque plusieurs échanges sont encore nécessaires, le MCP propose deux modèles. Les requêtes « Multi-Round-Trip » gèrent les échanges légers au sein d’un même appel. L’extension « Tasks » gère les opérations de longue durée : le serveur renvoie un identifiant de tâche durable, et s’il a besoin de plus d’informations en cours d’exécution, il se met en pause avec un statut « input_required » jusqu’à ce que le client fournisse les données manquantes. Le comportement « avec état » hérité est en période de migration, et les fonctionnalités Roots, Sampling et Logging (trois anciennes fonctionnalités permettant aux serveurs de demander des informations en retour au client) sont dépréciées séparément, avec un délai d’au moins 12 mois avant leur suppression.
Le caractère « avec état » n’est donc plus le critère déterminant. La différence qui subsiste se situe au-dessus de la couche de transport : une API s’appuie sur une logique écrite par le développeur pour déterminer ce qui doit être appelé. Le MCP permet au modèle d’IA de découvrir et, dans la plupart des cas, de choisir par lui-même.
Quelle est la différence entre le MCP et l'appel de fonction ?
L'appel de fonction est une fonctionnalité des modèles. Le MCP est une norme de découverte et de transport qui la prend en charge. L'appel de fonction permet à un modèle d'émettre une requête structurée pour invoquer une fonction que vous avez définie dans votre propre code. Le MCP normalise la provenance de ces définitions, la manière dont un client les récupère depuis un serveur lors de l'exécution, ainsi que le fonctionnement de l'autorisation. Un modèle utilise l'appel de fonction pour agir sur les outils fournis par le MCP.
L'appel de fonctions (également appelé « utilisation d'outils ») est intégré aux API de modèles d'OpenAI, d'Anthropic et de Google. Vous définissez un ensemble de fonctions, transmettez leurs schémas au modèle, et celui-ci renvoie des arguments structurés lorsqu'il estime qu'une fonction est pertinente. Vous choisissez toujours les fonctions à proposer, écrivez le code d'exécution et gérez la réponse. Le modèle choisit quelle fonction appeler. Votre code s'occupe du reste.
Le MCP opère à un niveau supérieur. Il normalise la manière dont un client IA identifie les fonctions disponibles, sur plusieurs serveurs, sans nécessiter de codage en dur de votre part. Le serveur publie la liste de ses outils. Le client les lit au moment de l'exécution. Le modèle utilise ensuite l'appel de fonction pour invoquer celle qu'il a sélectionnée.
En termes simples : l'appel de fonction correspond à la manière dont un modèle dit : « Je souhaite appeler cet outil avec ces arguments. » Le MCP est ce qui indique au modèle quels outils sont disponibles pour être appelés.
La plupart des clients compatibles MCP exécutent les deux simultanément. Ils récupèrent les schémas d’outils depuis le serveur MCP, les mettent en forme sous forme de définitions de fonctions pour le modèle, puis renvoient la sortie structurée du modèle via MCP pour exécution. Les deux constituent des couches d’une même pile ; vous les verrez donc généralement fonctionner en séquence sur une même requête.
Le MCP est-il plus lent ou plus coûteux qu’une API ?
Oui, le MCP est à la fois plus lent et plus coûteux qu’un appel API direct. Le MCP intègre un modèle d’IA dans la boucle de requêtes, ce qui ajoute un délai supplémentaire et des coûts liés aux jetons. Les API directes envoient les requêtes directement à un point de terminaison, tandis que le MCP nécessite un LLM pour choisir, exécuter et lire les outils de manière dynamique.
Pourquoi le MCP est-il plus lent ?
- Temps de traitement : les appels API directs s’effectuent en quelques millisecondes. Le MCP oblige le modèle à analyser une invitation, à choisir l’outil approprié, à exécuter la requête et à traiter les résultats.
- Boucles d’agent : les boucles d’agent à plusieurs étapes multiplient ce délai d’exécution sur plusieurs passages séquentiels
Pourquoi le MCP est-il plus coûteux ?
- Surcoût lié au schéma de l’invite : le MCP nécessite d’ajouter des descriptions d’outils dans l’invite système. Cela ajoute des milliers de jetons à chaque requête.
- Utilisation des jetons : les appels API directs ne consomment pas de jetons d’inférence de modèle, tandis que le MCP utilise des jetons payants pour mettre en forme les paramètres et les résumés de sortie
Utilisez les API directes pour les tâches d’application prévisibles qui nécessitent des réponses rapides et un faible coût.
Utilisez le MCP pour créer des agents IA flexibles qui doivent choisir leurs actions de manière dynamique au cours d'une discussion.
Le MCP est-il moins sécurisé qu'une API ?
Pas nécessairement. Le MCP impose les mêmes exigences de sécurité que n'importe quelle API : authentification, autorisation, permissions limitées et validation des entrées. La différence réside dans le fait de savoir qui décide de ce qui est appelé.
| Domaine de la sécurité | API | MCP |
|---|---|---|
| Authentification et permissions | Obligatoire | Obligatoire |
| Qui effectue la sélection de l'action ? | Code d'application | Il peut s'agir d'un modèle IA |
| Injection de prompt | Ce n'est pas inhérent à l'API | Cela peut influencer la sélection des outils et leur mise en œuvre |
| Métadonnées de l'outil | Description de l'interface | Peut influencer le comportement du modèle |
| Risque lié à l'interopérabilité entre outils | Limité aux intégrations programmées | Les agents peuvent combiner dynamiquement des outils et des sources de données |
Deux risques méritent d'être mentionnés :
Empoisonnement d’outil. Un serveur MCP malveillant renvoie des instructions cachées dans la réponse d’un outil. Le modèle traite cette réponse comme un contexte de confiance et suit les instructions intégrées. L’OWASP classe cela comme une injection indirecte de prompt à l’encontre d’agents connectés au MCP. Cela fonctionne car les descriptions des outils sont vérifiées une seule fois au moment de la connexion, mais les réponses des outils sont directement intégrées au contexte du modèle lors de l’exécution, sans vérification équivalente.
Le « trio mortel ». C'est l'expression utilisée par Simon Willison. Elle désigne un agent ayant accès à des données privées, qui consomme du contenu non fiable et peut communiquer avec l'extérieur. Combinez ces trois éléments, et l'injection de commandes devient une voie d'exfiltration des données. Le MCP facilite cette combinaison, car les utilisateurs effectuent des connexions à des outils provenant de multiples sources.
La question pratique n’est pas de savoir si le MCP est « sécurisé ». Il s’agit plutôt de déterminer si vous avez limité ce que le modèle peut voir, choisir et exécuter, et pas seulement ce que le code peut appeler.
Pour les déploiements MCP :
- Considérez les serveurs tiers comme des sources non fiables, tant pour les métadonnées de leurs outils que pour chacune des réponses qu’ils renvoient
- Limitez les permissions de chaque outil au strict minimum nécessaire
- Exiger une validation avant toute action sensible ou irréversible
- Ne combinez jamais des données privées, des entrées non fiables et un accès sortant illimité au sein d'un même agent
Comment ClickUp utilise à la fois le MCP et les API
ClickUp est un exemple du modèle « développer les deux » que nous avons décrit jusqu’à présent.
L'API ClickUp est l'interface complète destinée aux développeurs. Les équipes l'utilisent pour créer des connexions personnalisées, synchroniser des données entre différents systèmes et exécuter des flux de travail tout en contrôlant directement chaque requête.
Le serveur MCP de ClickUp expose bon nombre de ces mêmes actions via le MCP. Les clients IA tels que Claude Code, Cursor et ChatGPT peuvent se connecter, identifier les outils ClickUp disponibles et les invoquer à partir de commandes en langage naturel. Cela inclut la création de tâches, la recherche dans un environnement de travail ClickUp, l’utilisation de documents, la publication de commentaires et la saisie du temps passé.
La couche d’IA destinée aux utilisateurs se situe au-dessus. ClickUp Brain extrait le contexte des tâches, des documents, du chat et d’autres éléments de travail.
Les Super Agents de ClickUp s'appuient sur ce contexte pour prendre des décisions et exécuter eux-mêmes des flux de travail en plusieurs étapes. Vous pouvez leur attribuer des tâches, leur envoyer des messages et les laisser agir au sein d'un environnement de travail.
ClickUp dispose ainsi de trois niveaux. L’API s’adresse aux développeurs qui souhaitent un accès complet. Le MCP offre aux clients IA externes un moyen standard de trouver et d’utiliser les outils ClickUp. Brain et les Super Agents intègrent le raisonnement IA au cœur même du produit.
Bien sûr, ClickUp vous permet également de réaliser une connexion avec vos autres outils via ses serveurs MCP. Aucun travail sur l'API n'est nécessaire.
Limites : Le serveur MCP est encore en version bêta publique et n’expose pas l’intégralité de l’API. Si l’outil dont vous avez besoin n’y figure pas, ou si votre flux de travail nécessite un contrôle direct sur chaque requête, l’API est la meilleure solution.
Cessez de comparer les protocoles de transport et commencez à comparer les consommateurs
Le MCP et les API ne sont pas des normes concurrentes, et les différences les plus souvent citées sont celles qui ont le plus vite perdu de leur actualité.
Il s'agit en fin de compte d'un véritable choix architectural. Une API est un contrat destiné aux développeurs. Un serveur MCP est un contrat destiné aux modèles, ce qui en fait à la fois une invite, des instructions et une surface d'attaque.
Concevez votre système en conséquence. Conservez l’API comme épine dorsale déterministe. Décidez ensuite, outil par outil, ce qu’un agent est autorisé à faire sans la présence d’un humain, et ne publiez que cela. Évaluez le coût du catalogue dans son contexte, et partez du principe que chaque description d’outil et chaque réponse d’outil sont contrôlées par un attaquant jusqu’à ce que vous ayez vérifié le contraire.
Que vous choisissiez l'API ou le MCP, ClickUp fonctionne avec les deux. Commencez à utiliser ClickUp gratuitement.
Foire aux questions sur le MCP et l'API
Le format de transmission est JSON-RPC 2.0 sur HTTP, délibérément banal. La valeur réside dans le catalogue de capacités normalisé, les schémas d’outils et le modèle d’autorisation qui s’appuient sur celui-ci. Conformément à la spécification de juillet, chaque requête est autodescriptive et sans état, le nom de la méthode et de l’outil étant transmis dans les en-têtes HTTP afin que les passerelles puissent acheminer les requêtes sans analyser le corps du message. Une seule intégration permet désormais de prendre en charge Claude, ChatGPT, Cursor, Gemini et Copilot sans avoir à développer de couche d’interfaçage sur mesure pour chacun d’entre eux.
ClickUp dispose-t-il à la fois d'une API et d'un serveur MCP ?
Oui. ClickUp propose une API REST avec une spécification OpenAPI pour des intégrations déterministes et pilotées par du code, ainsi qu’un serveur MCP distinct (en bêta publique) qui permet à des assistants tels que Claude, ChatGPT et Cursor d’interagir avec les données de l’environnement de travail en langage naturel. L’interface MCP est un sous-ensemble délibéré de l’API ; par conséquent, tout ce qui ne relève pas de celle-ci utilise toujours l’API REST. Elle est disponible sur tous les forfaits.
Claude Desktop, Claude Code, ChatGPT (forfaits payants, notamment Plus, Pro, Business et Enterprise), Cursor, GitHub Copilot, VS Code (via l’extension Copilot), Gemini, Windsurf et Microsoft Copilot Studio prennent tous en charge le MCP depuis mi-2026. OpenAI, Google, Microsoft et plusieurs autres acteurs ont rejoint l’Agentic AI Foundation de la Linux Foundation, qui régit la spécification. L’assistance des clients est large mais inégale : tous les clients ne prennent pas en charge toutes les fonctionnalités du MCP (par exemple, les ressources et les instructions sont en retard par rapport aux appels d’outils).
Oui, et l’encapsulation d’une API existante est la démarche la plus courante. Le serveur effectue l’authentification auprès de l’API, associe un ensemble d’endpoints sélectionnés à des outils, puis publie les noms, descriptions et schémas JSON de chacun d’entre eux. Évitez de mapper tous les endpoints. Chaque description d’outil entre dans le contexte du modèle à chaque tour, donc un catalogue volumineux coûte des jetons et élargit la surface d’injection d’invites. N’exposez que les actions que vous êtes prêt à laisser un agent effectuer de manière autonome.
Autant que l’exige le cas d’utilisation. L’équipe d’ingénierie d’Anthropic a indiqué que les définitions d’outils et les résultats combinés peuvent consommer plus de 50 000 jetons avant même que le modèle ne lise la requête de l’utilisateur. Les recommandations de la communauté s’accordent sur un plafond de 10 à 20 outils par serveur avant que des techniques de gestion du contexte (divulgation progressive, recherche d’outils) ne deviennent nécessaires. Si vous dépassez les 50, répartissez-les sur plusieurs serveurs dédiés à des domaines spécifiques.
Non, bien que la plupart des déploiements en possèdent un. Un serveur MCP peut exposer des fichiers locaux, une base de données ou une logique en cours d’exécution sans faire appel à une API HTTP, ce qui correspond à la conception initiale du transport stdio. Ce dont le MCP a toujours besoin, c’est d’un moyen d’exécuter l’outil. L’enveloppement d’une API existante est tout simplement la solution la plus rapide, car l’authentification, la validation et la gestion des erreurs sont déjà en place.
Les outils sont des actions appelables (créer une tâche, exécuter une requête) et s’apparentent le plus aux points de terminaison d’une API. Les ressources sont des données en lecture seule que le modèle peut intégrer au contexte (fichiers, enregistrements de base de données, documents en temps réel). Les invites sont des modèles d’instructions réutilisables que le client IA peut demander, comme un flux de travail « résumer ce PR ». Si les outils retiennent le plus l’attention, ce sont les ressources et les invites qui distinguent le MCP d’une simple liste d’appels de fonctions : elles permettent au serveur de façonner le contexte du modèle, et pas seulement ses actions.