Protocole MCP vs API : définitions et cas d'utilisation

Le protocole MCP (Model Context Protocol) est un standard ouvert utilisé par les agents d'intelligence artificielle pour accéder à des systèmes externes : fonctionnalités d'applications (outils), ressources (notamment des bases de données) et invites.

Contrairement à une API, qui relie deux applications par l'intermédiaire de points de terminaison et de paramètres définis, le protocole MCP permet aux LLM de découvrir des outils actualisés au moment de l'exécution. Le protocole MCP peut également réduire considérablement le temps nécessaire à la maintenance des intégrations.

Le protocole MCP et les API ne sont pas des technologies opposées. Le protocole MCP a été conçu pour offrir aux applications basées sur l'IA un accès complet aux fonctionnalités et informations externes tout en réduisant le besoin de configuration d'API sur mesure. Souvent, les requêtes MCP déclenchent des appels d'API côté serveur, et il existe d'importants cas d'utilisation pour les développeurs où les API restent préférables au protocole MCP.

Le protocole MCP est un protocole libre (un ensemble de règles) qui permet aux outils d'IA d'appeler en toute sécurité et de manière autonome des outils tels que des bases de données, des fonctionnalités logicielles et des invites.
Par rapport aux API préconfigurées, le protocole MCP permet à un LLM de sélectionner des fonctionnalités externes actuelles en fonction des besoins de la tâche sans alourdir sa fenêtre de contexte.
Pour les intégrations logicielles traditionnelles et certains flux de travail de LLM itératifs et fixes, les API sont préférables.
Si les fonctionnalités d'IA de votre application se développent, que vous gérez un volume élevé d'intégrations ou que les caractéristiques des fournisseurs changent fréquemment, le protocole MCP est de loin le meilleur choix.
En dehors de la sphère des développeurs, l'utilisation personnelle de connecteurs MCP avec les principaux agents conversationnels d'IA (Claude, ChatGPT, Perplexity, etc.) ne requiert aucune connaissance en programmation complexe. La plupart proposent des intégrations en un clic.

Le protocole MCP est largement utilisé pour la communication entre un modèle d'IA et un serveur MCP. Il permet à un client MCP d'appeler l'ensemble des outils et des ressources disponibles sur le serveur MCP.

Un flux de travail MCP se compose de trois éléments :

Hôte : l'application enveloppe (telle que Perplexity) où l'utilisateur final déclenche une action ou saisit une invite en langage naturel, par exemple « donne-moi la météo à Londres ». L'hôte fournit au LLM une liste d'outils disponibles, et le LLM détermine quel outil est le mieux adapté à l'accomplissement de la tâche.
Client : le gestionnaire de protocole (intégré à l'hôte) qui se connecte à un serveur MCP à l'aide du protocole MCP.
Serveur : l'application qui reçoit les requêtes MCP et met à disposition ou « expose » les différentes fonctionnalités auxquelles elle a accès.

Il convient de noter que les serveurs MCP utilisent souvent des API pour communiquer avec les outils. Si vous connectez Perplexity au serveur MCP Slack, par exemple, le client communiquera avec le serveur MCP, qui utilisera ensuite l'API Slack pour effectuer les requêtes détaillées dans la requête MCP initiale.

Une API est une interface entre deux applications. À l'instar du protocole MCP, elle définit les règles selon lesquelles un système peut demander des données ou des actions à un autre. Un client envoie une requête à l'aide de paramètres spécifiés par le fournisseur, et le serveur renvoie une réponse.

Voici un aperçu des différents éléments d'une requête et d'une réponse API :

Point de terminaison : l'URL à laquelle vous envoyez la requête.
Méthode : l'action que vous souhaitez que l'application serveur exécute.
Paramètres : les données d'entrée que vous envoyez pour que le serveur les traite.
En-têtes : informations supplémentaires telles que l'autorisation et le format de la réponse.
Corps de la requête : les données nécessaires pour exécuter la requête (celles-ci sont parfois facultatives).
Réponse : les informations ou le statut de réussite/d'échec renvoyés par le serveur.

De manière générale, la quasi-totalité des actions d'une API se résume à échanger des données avec un système ou à demander à ce système d'exécuter une opération.

À première vue, cela peut sembler similaire à ce que fait un connecteur MCP. Toutefois, la différence cruciale réside dans le fait qu'avec une approche basée sur les API, les différentes tâches requièrent des points de terminaison, des méthodes et des paramètres distincts, qui doivent tous être maintenus côté client. Un serveur MCP rend l'ensemble de ses fonctionnalités ou données disponibles visibles pour un LLM sans nécessiter de mises à jour côté client.

	MCP	API
Application principale	Flux de travail au sein d'un outil basé sur un LLM	Requêtes définies entre plateformes logicielles
Fonctionnement	Accès à plusieurs outils basé sur le raisonnement du LLM ; toutes les fonctionnalités sont à jour car le fournisseur contrôle le serveur MCP	Le logiciel envoie des requêtes spécifiques au service à l'aide de points de terminaison, de méthodes et de paramètres prédéfinis
Découverte	Le LLM peut voir et utiliser tous les outils exposés par le serveur, y compris les nouveaux	Le logiciel ne peut effectuer que des requêtes API préconfigurées
Cas d'utilisation principaux	Flux de travail basés sur l'IA et les agents ; sélection dynamique d'outils basée sur des invites en langage naturel ; intégrations de fournisseurs pour les outils d'IA	Transferts de données à volume élevé ; flux de travail fixes et répétitifs ; intégrations logicielles traditionnelles
Cas d'utilisation supplémentaires	Assistants de codage avec accès à plusieurs fichiers et référentiels ; accès en langage naturel aux systèmes d'entreprise ; intégrations internes réutilisables pour les outils d'IA	Intégrations personnalisées ; transactions en ligne ; récupération de données planifiée ; intégrations de fournisseurs pour les outils d'IA qui ne prennent pas en charge le protocole MCP
Temps de configuration	Minimal une fois la connexion MCP établie	Les API doivent être configurées individuellement au sein d'une application pour accéder à de nouvelles fonctionnalités
Inconvénients	Coût en jetons souvent élevé pour les tâches complexes ; trop gourmand en ressources pour les tâches de données répétitives et bien définies	Coûts de maintenance extrêmement élevés pour les applications dotées d'intégrations complexes ; ne garantit pas l'accès aux fonctionnalités actuelles
Avantages	Standard universel, capable de gérer des flux de travail complexes, accès accru aux outils, autonomie une fois configuré	Consommation de jetons réduite pour les flux de travail fixes et à volume élevé dans les outils d'IA

Examinons un exemple simple illustrant les différences entre le protocole MCP et les API. Dans ce scénario, la requête est en fait mieux adaptée à une API (elle est simple et ne nécessite pas de contexte). Néanmoins, ces deux exemples montrent clairement à quel point le protocole MCP est optimal pour les flux de travail de LLM en plusieurs étapes.

Voici un script (rédigé en Python) qui envoie une requête API pour obtenir des informations météorologiques à l'aide de l'API Open-Meteo :

python

import requests
url = "https://api.open-meteo.com/v1/forecast"
params = {    "latitude": 51.5072,    "longitude": -0.1276,    "current": "temperature_2m"}
response = requests.get(url, params=params)
data = response.json()
temperature = data["current"]["temperature_2m"]
print(f"Temperature in London: {temperature}°C")

Cet exemple utilise un format de requête précis pour interroger Open-Meteo via HTTPS afin d'obtenir la température actuelle à 2 mètres pour la latitude 51,5072 et la longitude -0,1276 (Londres).

À l'inverse, un client MCP pourrait envoyer une requête JSON-RPC tools/call telle que la suivante à un serveur ayant accès à une base de données météorologiques :

json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "London"
    }
  }
}

Dans cet exemple fictif, le client demande au serveur d'utiliser un outil spécifique (get-weather) de son registre pour exécuter une tâche (décrire la météo à Londres).

La principale différence réside dans le fait que cette fonctionnalité serait l'une des nombreuses proposées par le serveur MCP. Le client MCP n'a pas besoin de connaître les points de terminaison, les paramètres, les structures de réponse ou les méthodes d'authentification spécifiques pour générer la requête. Le LLM peut examiner les descriptions des outils dans le registre pour sélectionner ceux qu'il juge les plus adaptés à l'accomplissement d'une tâche décrite en langage naturel.

Le protocole MCP et les API ne s'excluent pas mutuellement. Le protocole MCP a été conçu pour faciliter la découverte et la maintenance des intégrations. Par conséquent, les API constituent souvent la meilleure option pour les connexions logicielles non liées à l'IA ainsi que pour les tâches et flux de travail de LLM qui sont fixes et reposent sur un groupe spécifique d'API stables.

Vous devez gérer un ensemble d'outils vaste ou en expansion : un client MCP peut découvrir tous les outils exposés par le serveur d'un fournisseur au moment de l'exécution, ce qui réduit les efforts de configuration des API individuelles à mesure que votre ensemble d'outils s'agrandit.
Le choix de l'outil dépend des requêtes de l'utilisateur : le protocole MCP est utile lorsque les étapes de la tâche ne peuvent pas être prédéterminées, par exemple si les utilisateurs formulent un large éventail de requêtes auprès d'un agent conversationnel. Le LLM peut examiner les noms, les descriptions et les schémas des outils disponibles, puis choisir ceux qui conviennent le mieux à une tâche.
Les fonctionnalités des fournisseurs changent fréquemment : lorsque les fournisseurs ajoutent de nouvelles fonctionnalités à leurs applications, celles-ci sont immédiatement disponibles via le protocole MCP. Vous n'avez pas besoin d'ajouter de nouvelles API ni de reconfigurer les API existantes.
Vous souhaitez disposer des mêmes intégrations dans plusieurs applications d'IA : un serveur MCP peut exposer les mêmes capacités à plusieurs agents ou applications, ce qui réduit le travail d'intégration redondant.

Vous récupérez des données structurées : si votre outil d'IA extrait des informations structurées prévisibles, telles qu'un statut d'expédition ou un numéro de billet de support client, à une étape précise du flux de travail de l'utilisateur, une requête API standard consomme moins de jetons et de temps.
Votre flux de travail est organisé selon une séquence fixe : si votre flux de travail suit une séquence stricte et répétable avec des API précises et un résultat exact, il n'est pas nécessaire d'utiliser le protocole MCP.
Votre application exécute un flux de travail à volume élevé : l'utilisation de jetons peut s'avérer particulièrement prohibitive pour les tâches à volume élevé. Si un flux de travail complexe nécessite des entrées ou des sorties itératives à volume élevé en association avec un raisonnement, il est préférable d'utiliser une combinaison de requêtes MCP et API.
Le raisonnement de l'IA n'apporte aucun avantage : si la logique d'application ordinaire peut accomplir adéquatement une tâche, un appel d'API direct est généralement plus simple et moins gourmand en ressources.

La question du choix entre le protocole MCP et une API concerne principalement les développeurs qui conçoivent des applications dotées de fonctionnalités d'IA. Toutefois, vous vous demandez peut-être aussi s'il convient d'utiliser le protocole MCP pour vos flux de travail professionnels dans l'outil d'IA de votre choix.

Les mêmes règles générales s'appliquent : si vous souhaitez un accès actualisé aux fonctionnalités d'applications tierces avec une large couverture, les protocoles MCP constituent la solution idéale. Pour les tâches répétitives et à volume élevé, une configuration d'API simple consommera moins de jetons.

La plupart des outils d'IA, y compris Perplexity, permettent aux utilisateurs de configurer et d'utiliser des connecteurs MCP sans aucune programmation. Il est ainsi possible d'orchestrer des flux de travail en plusieurs étapes sans quitter l'interface de clavardage. Par exemple, il est possible de s'intégrer à des plateformes telles que Gmail, HubSpot et Supabase en quelques clics.

Répertoire des connecteurs de Perplexity illustrant des intégrations telles que Gmail, Outlook, HubSpot, Monday.com, Supabase et Vercel.

Les principaux avantages du protocole MCP sont la découverte dynamique et la réduction des frais généraux de maintenance des API. En connectant votre application à un serveur MCP, vous obtenez un accès à tous les derniers outils, données et invites mis à disposition par les fournisseurs de votre choix (ou par vos systèmes locaux).

Cependant, les API restent essentielles. Elles constituent l'architecture sous-jacente de l'interconnectivité des applications. Le protocole MCP agit comme une couche intermédiaire entre une application et une fonctionnalité externe. Il permet aux agents d'IA d'accéder au plus large ensemble d'outils possible dans un format adapté à des flux de travail complexes.

Protocole MCP par rapport aux API : quelles sont les principales différences ?

Qu'est-ce que le protocole MCP (Model Context Protocol) ?

Qu'est-ce qu'une interface de programmation d'applications (API) ?

Cas d'utilisation, avantages et inconvénients

Illustration pratique du protocole MCP par rapport aux API

Comment choisir entre le protocole MCP et une API

Quand utiliser le protocole MCP

Quand utiliser une API directe

Utilisation d'un connecteur MCP dans Perplexity

Pourquoi le protocole MCP rend les applications basées sur les LLM plus puissantes