MCP & API

Définition

MCP et API : deux façons d’exposer des fonctions

Une API REST suppose un développeur qui a lu la documentation, choisi les routes utiles et écrit le code d’appel. Un serveur MCP suppose un modèle qui reçoit la liste des outils disponibles, leur description et leur schéma, puis décide seul lequel appeler. Le contrat est le même, le lecteur du contrat change.

Cette différence de destinataire explique le reste : la façon d’écrire les descriptions, le découpage des opérations, la gestion des erreurs. MCP n’est pas une API plus moderne, c’est une couche de présentation destinée à un lecteur qui n’ouvre aucune documentation.

Ce qu’une API REST fournit déjà

Une API REST correctement conçue apporte déjà l’essentiel. Un point d’entrée stable, un format d’échange normalisé, une authentification, des codes de statut interprétables, une gestion des quotas et, dans le meilleur des cas, une spécification lisible par une machine. Aucun de ces éléments ne disparaît quand vous ajoutez MCP.

Ce qu’elle ne fournit pas, c’est le sens. Une route sait ce qu’elle accepte, pas dans quelle situation l’utiliser, ni ce qu’il ne faut pas en faire. Cette connaissance vit dans la documentation et dans la tête des développeurs, deux endroits inaccessibles à un modèle au moment de l’appel.

Ce que MCP apporte en plus pour un LLM

MCP apporte trois choses qu’une API seule ne donne pas. Une description des outils rédigée pour être comprise par un modèle. Une découverte dynamique : l’hôte interroge le serveur et obtient la liste courante des outils, sans que rien soit codé en dur. Un contrat d’usage, qui dit quand appeler l’outil et avec quelles précautions.

La découverte dynamique change la maintenance. Une opération ajoutée côté serveur devient utilisable immédiatement, sans mise à jour du client. Une opération retirée disparaît du catalogue et le modèle cesse de l’appeler, là où un code d’intégration classique aurait continué jusqu’à l’erreur.

MCP ajoute aussi deux primitives absentes du monde REST : les resources, qui exposent des données à lire pour se repérer, et les prompts, qui fournissent des modèles d’invite réutilisables. Leur fonctionnement est décrit sur la page serveurs MCP.

Arbitrage

Coût en tokens, performance et limites : MCP ou appel direct à l’API ?

Le coût propre à MCP tient à un point précis : la description des outils occupe du contexte. Chaque outil déclaré consomme des tokens à chaque échange, que le modèle l’appelle ou non, en proportion du nombre d’outils, de la longueur des descriptions et de la complexité des schémas. Un appel direct à l’API ne paie pas cette charge.

Critère	Appel direct à l’API	Exposition via MCP	Point de vigilance
Découverte des opérations	Codée en dur par un développeur	Dynamique, le modèle lit le catalogue	Un catalogue trop fourni dégrade la sélection du bon outil
Coût en contexte	Nul, rien n’est chargé côté modèle	Proportionnel au nombre et à la taille des descriptions	La charge est payée à chaque échange, même sans appel
Latence	Un aller-retour vers l’API	Un saut supplémentaire par le serveur MCP	Le filtrage des réponses ajoute du traitement côté serveur
Contrôle du périmètre	Défini dans le code appelant	Défini par les outils exposés et les portées du serveur	Ce que le serveur n’expose pas reste inatteignable, y compris en cas de besoin urgent
Évolution	Toute modification de l’API impose une mise à jour du client	Le catalogue se met à jour côté serveur	Renommer un outil déjà utilisé casse les consignes écrites par vos utilisateurs

La lecture pratique du tableau : MCP gagne dès que la variété des demandes est forte et imprévisible. L’appel direct gagne dès que le scénario est stable et répété. Les deux cohabitent très bien dans un même système, sur des chemins différents.

Applications

Cas d’usage

• Rendre une API interne de facturation utilisable par un assistant IA
• Exposer une API métier à un agent sans développer de client dédié
• Restreindre un agent à trois endpoints sur une API qui en compte cent
• Filtrer et résumer les réponses API avant de les renvoyer au modèle pour limiter les tokens

Vos questions

Questions fréquentes

MCP remplace-t-il les API REST ?

Non. Un serveur MCP appelle presque toujours une API en dessous de lui. Il ne se substitue pas à elle, il en propose une lecture destinée à un modèle, avec un sous-ensemble d’opérations et des descriptions exploitables.

Le raisonnement inverse est plus utile : si vous n’avez pas encore d’API, construisez-la d’abord. Un serveur MCP posé sur une logique métier mal découpée hérite de ce découpage, et vous vous retrouvez à corriger deux couches au lieu d’une.

Peut-on générer un serveur MCP à partir d’une spécification OpenAPI ?

Techniquement oui : une spécification décrit les routes, les paramètres et les réponses, de quoi produire automatiquement des outils correspondants. C’est un bon point de départ pour une première version.

Le résultat brut est rarement utilisable tel quel. Vous obtenez autant d’outils que de routes, avec des descriptions écrites pour des développeurs et des réponses complètes non filtrées. Le travail utile commence après la génération : réduire le nombre d’outils, réécrire les descriptions, restreindre les réponses.

Comment authentifier les appels d’un serveur MCP vers une API ?

Avec des identifiants stockés côté serveur, propres à cet usage, et limités aux portées nécessaires. Le serveur s’authentifie auprès de l’API comme le ferait n’importe quelle application cliente ; l’hôte, lui, n’a jamais besoin de connaître ces identifiants.

La question à trancher est celle de l’identité : le serveur agit-il au nom d’une application unique, ou au nom de l’utilisateur connecté ? Le second cas impose de propager l’identité jusqu’à l’API, sans quoi tous vos utilisateurs partagent les mêmes droits. Voir aussi connecter ChatGPT et Claude à vos outils métier.

Un serveur MCP consomme-t-il beaucoup de tokens ?

Cela dépend entièrement de sa conception. La consommation vient de deux sources : la description des outils, chargée à chaque échange, et le contenu des réponses renvoyées par les outils appelés. La seconde dépasse largement la première dès que les réponses ne sont pas filtrées.

Le levier le plus efficace est donc le filtrage des réponses, avant la réduction du nombre d’outils. Un outil qui renvoie une liste complète là où trois champs suffisaient coûtera plus cher que dix descriptions bien écrites. Sur le volet automatisation et déclenchement, voir API et webhooks.