MCP ou API ? Pour un agent IA, le choix ne se fait pas entre deux technologies qui rempliraient le même rôle. Gardez un appel API direct lorsque le code connaît l’opération à exécuter et doit en contrôler le chemin. Ajoutez MCP lorsqu’une application IA doit découvrir un catalogue limité de capacités et en choisir une selon la demande. Souvent, la bonne architecture combine les deux : MCP présente les capacités à l’agent, tandis que les API existantes restent les contrats métier derrière elles.
Décidez donc capacité par capacité. Rechercher un dossier, préparer une réponse et envoyer un message n’exposent ni le même effet ni le même risque. Une seule réponse pour toute la stack masque cette différence.
MCP et API ne sont pas au même étage
Une API définit comment un logiciel demande une opération à un autre service : paramètres, réponse, erreurs et règles métier. Le code appelant connaît généralement l’opération à l’avance.
MCP définit un échange entre une application IA hôte, ses clients MCP et des serveurs qui présentent du contexte ou des capacités. Dans la spécification stable du 28 juillet 2026, cet échange utilise JSON-RPC et distingue notamment les ressources, les prompts et les tools.[1] L’hôte crée un client dédié par serveur et reste responsable de la manière dont le modèle reçoit et utilise ce contexte.[2]
Un tool MCP peut interroger une base, effectuer un calcul ou appeler une API.[3] Cette phrase règle une partie du faux débat : l’API peut rester en place derrière le serveur MCP. L’une porte le contrat métier ; l’autre adapte une surface choisie à des applications IA.
Les fournisseurs les combinent déjà de cette façon. La Responses API d’OpenAI accepte des serveurs MCP distants comme outils, en plus du function calling, avec filtrage et approbation configurables.[6] L’API Messages d’Anthropic peut elle aussi se connecter à des serveurs MCP distants et limiter les tools par allowlist ou denylist.[7] Ces documentations prouvent la coexistence de leurs propres implémentations, pas une compatibilité universelle entre tous les clients et tous les serveurs.
Gardez l’API directe pour une transaction connue
L’appel direct est souvent le choix le plus lisible lorsqu’un workflow sait exactement quoi faire. Par exemple : après validation d’un formulaire, créer une tâche avec un schéma précis, une clé d’idempotence et une réponse attendue.
Cette option est particulièrement solide quand :
- l’opération est fixe et déclenchée par une règle déterministe ;
- le contrat métier doit rester explicite dans le code ;
- l’écriture est sensible ou difficile à annuler ;
- le chemin d’erreur et la reprise doivent être maîtrisés sans laisser le modèle choisir un autre outil ;
- aucun autre hôte IA n’a besoin de découvrir cette capacité.
Une API peut aussi être décrite avec OpenAPI ou un SDK. Il serait donc faux d’affirmer qu’elle est, par nature, impossible à documenter ou à découvrir. La différence utile tient à l’interface d’exécution offerte au modèle : dans un appel direct, le logiciel a déjà choisi l’opération.
Ajoutez MCP pour une surface de capacités découvrable
MCP devient intéressant lorsque plusieurs applications IA doivent consulter un catalogue cohérent de capacités. Un client peut demander la liste des tools disponibles, lire leur schéma puis en invoquer un. La liste peut évoluer, et la spécification prévoit une notification de changement pour les clients qui s’y abonnent.[2][3]
Cette découverte ne donne pas carte blanche au modèle. L’hôte choisit les serveurs auxquels il se connecte, les outils qu’il présente et l’interface de consentement. La spécification recommande d’afficher les tools exposés, de rendre leurs appels visibles et de permettre à l’utilisateur de refuser.[3]
L’annonce d’origine d’Anthropic présentait MCP comme un standard ouvert destiné à réduire la multiplication des connecteurs spécifiques entre assistants et sources de données.[8] Cette ambition aide à comprendre le protocole, mais elle date de novembre 2024. Pour une décision technique, la version réellement supportée par le couple hôte-serveur compte davantage que la promesse initiale.
L’architecture hybride est souvent la réponse
Une façade MCP mince peut présenter quelques capacités stables sans déplacer toute la logique métier. Le serveur traduit alors un tool comme preparer_mise_a_jour vers une ou plusieurs API existantes. Les règles de validation, l’identité des données et les contraintes transactionnelles restent dans les services qui les portent déjà.
Cette séparation évite deux excès : reconstruire chaque intégration pour chaque hôte IA, ou transformer automatiquement chaque endpoint en tool. Un catalogue trop large augmente le nombre d’actions que le modèle peut envisager et complique la revue. Une façade utile sélectionne, nomme et borne les capacités qui ont un sens pour l’agent.
Plusieurs comparatifs récents aboutissent aussi à une logique de complémentarité. YouTrust oppose l’intégration API pilotée par le code à une interface MCP tournée vers l’usage agentique.[9] WorkOS présente MCP au-dessus de services REST et insiste sur la découverte via tools/list.[10] Ce sont des sources commerciales secondaires : elles confirment l’intention de comparaison, mais la spécification primaire doit trancher les détails du protocole.
Décidez capacité par capacité
Cette matrice sert au cadrage. Elle n’est pas une règle universelle et doit être testée sur le système réel.
| Question | Signal API directe | Signal MCP | Signal hybride |
|---|---|---|---|
| Qui choisit l’opération ? | Le code connaît l’action exacte | L’application IA choisit parmi des tools bornés | L’agent choisit une capacité, le service exécute la transaction |
| Plusieurs hôtes IA doivent-ils découvrir la surface ? | Non | Oui | Oui, avec les API inchangées derrière |
| L’effet est-il sensible ou irréversible ? | Contrat déterministe privilégié | Exposition minimale et approbation nécessaires | MCP recherche ou prépare, une API bornée écrit |
| La capacité est-elle locale ? | SDK, CLI ou API locale peuvent suffire | Un transport local peut convenir | Le choix dépend de chaque capacité |
| Version et transport sont-ils vérifiés ? | Contrat API connu | Compatibilité MCP confirmée | Les deux frontières sont adaptées et testées |
Ajoutez une quatrième réponse possible : aucune intégration pour l’instant. Une capacité sans propriétaire métier, sans règle d’autorisation ou sans état final vérifiable n’est pas prête à être exposée à un agent.
Gouvernance et sécurité restent à construire
MCP n’est pas automatiquement plus sûr qu’un appel API. L’autorisation est optionnelle dans le protocole. Lorsqu’elle est mise en œuvre sur HTTP, la spécification s’appuie sur OAuth 2.1 et demande une sélection de scopes au moindre privilège.[4]
La frontière des tokens mérite une vérification explicite. Le serveur MCP doit valider qu’un token lui est bien destiné. S’il appelle ensuite une API amont, il doit utiliser un token distinct au lieu de transmettre celui reçu du client MCP. La spécification demande aussi un stockage sûr et PKCE dans le flux d’autorisation concerné.[5]
Le protocole ne choisit pas à votre place :
- les tools réellement visibles par rôle ou par utilisateur ;
- les écritures qui exigent une approbation ;
- la source de vérité et les contrôles métier ;
- l’effet attendu, l’idempotence et la stratégie de reprise ;
- les traces nécessaires pour relier une demande à son effet final.
Pour le risque lié aux contenus externes, le sujet détaillé reste l’injection de prompt indirecte. Une fois l’interface choisie, placez la validation humaine au bon endroit et définissez l’observabilité de l’agent. Changer de protocole ne remplace aucun de ces contrôles.
Portabilité, observabilité et maintenance
Un serveur MCP n’est portable que dans les limites que le client prend réellement en charge. L’implémentation Anthropic documentée ici ne supporte que les tools et demande un serveur distant accessible en HTTP ; elle ne couvre pas directement un serveur local STDIO.[7] OpenAI documente ses propres paramètres de serveur, son filtrage d’outils et ses règles d’approbation.[6] Avant de promettre un changement d’hôte, vérifiez primitives, version, transport, authentification et extensions des deux côtés.
La version 2026-07-28 corrige aussi un raccourci fréquent : le protocole décrit des requêtes sans état et autoportées, avec la version et les capacités portées par chaque requête.[1] Un serveur peut gérer un état métier au moyen d’un identifiant explicite, mais MCP n’impose pas une session implicite au niveau du protocole.[3] Écrire simplement « MCP est stateful » sans dater l’implémentation n’est plus assez précis.
Côté exploitation, tracez au minimum le tool présenté, les arguments validés, l’identité et les scopes, l’approbation éventuelle, l’appel API amont, son résultat et l’état final métier. Cela ne transforme pas cette page en guide complet de logs : l’article sur l’observabilité couvre ce chantier. Ici, la question est de savoir si la frontière choisie peut être comprise et maintenue.
Exemple fictif : rechercher, préparer, mettre à jour
Prenons un agent support fictif. Il doit retrouver un dossier, proposer une réponse et, après accord humain, préparer une mise à jour du CRM.
La recherche peut être exposée comme tool MCP en lecture seule, avec un schéma simple et un résultat sourcé. Plusieurs hôtes IA peuvent alors utiliser la même capacité. La préparation de réponse reste dans l’application hôte, car elle combine le contexte et les règles de ton. La mise à jour CRM passe par une API métier bornée, appelée seulement après validation, avec l’état attendu et la reprise définis.
Le montage peut donc être : hôte IA → client MCP → serveur MCP → API de recherche pour la lecture, puis workflow validé → API métier pour l’écriture. MCP ne remplace aucune API ; il rend une partie choisie du système découvrable par l’agent.
Vous hésitez entre envelopper une API existante, exposer quelques tools MCP ou conserver un workflow déterministe ? Last Word peut cartographier le processus et choisir la frontière par capacité avant un pilote borné. Découvrez le service agent IA support.
Sept vérifications avant un pilote
- Notez la version MCP, le transport et les primitives réellement supportés par chaque composant.
- Inventoriez les tools visibles pour chaque identité, sans confondre découverte et autorisation.
- Vérifiez les schémas d’entrée, les erreurs et l’état final produit par chaque capacité.
- Appliquez des scopes minimaux et séparez le token MCP du token de l’API amont.
- Placez une approbation avant les écritures sensibles et testez le refus.
- Reliez chaque appel à une trace et à un effet métier observable.
- Testez le couple hôte-serveur après chaque changement de version ou de catalogue.
Le protocole d’évaluation avant production permet ensuite de juger ce montage sur des cas normaux, ambigus et dégradés. Si le processus lui-même reste flou, commencez plutôt par cadrer son automatisation, puis décrivez votre contexte.
Questions fréquentes
MCP remplace-t-il une API REST ?
Non, pas en général. Un serveur MCP peut appeler une API existante et présenter certaines de ses capacités à une application IA.[3] MCP peut remplacer un connecteur spécifique côté agent, mais l’API reste souvent le contrat métier derrière cette façade.
Un agent IA peut-il appeler une API sans MCP ?
Oui. Le code de l’application peut appeler directement l’API ou utiliser du function calling. MCP ajoute surtout un contrat commun entre clients et serveurs pour découvrir et invoquer des capacités compatibles.
MCP est-il automatiquement plus sûr qu’une API directe ?
Non. L’autorisation MCP est optionnelle, et la sécurité dépend des tools exposés, des scopes, des tokens, des validations et des approbations mis en œuvre.[3][4][5]
MCP est-il stateful ?
La spécification du 28 juillet 2026 décrit des requêtes sans état et autoportées.[1] Un outil peut conserver un état métier avec un identifiant explicite transmis entre les appels, mais cet état n’est pas une session implicite imposée par le protocole.[3]
Quand utiliser MCP et API ensemble ?
Quand l’API doit rester le contrat métier tandis que MCP expose à l’agent un sous-ensemble de capacités sélectionnées. C’est utile pour séparer la découverte et le choix d’une capacité de l’exécution transactionnelle contrôlée.
Faut-il un serveur MCP pour chaque API ?
Non. Le découpage doit suivre les frontières de confiance, les propriétaires métier et les capacités cohérentes. Transformer mécaniquement chaque API ou chaque endpoint en serveur MCP ajoute de la maintenance sans clarifier l’usage.
Que vérifier avant de changer d’hôte IA ?
Vérifiez la version du protocole, le transport, les primitives, les extensions, l’authentification, les règles d’approbation et le filtrage des tools. Le support de « MCP » seul ne garantit pas que deux implémentations couvrent le même périmètre.[6][7]
Sources
[1] https://modelcontextprotocol.io/specification/2026-07-28 — Model Context Protocol, « Specification », révision stable du 28 juillet 2026, consultée le 10 septembre 2026.
[2] https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture — Model Context Protocol, « Architecture overview », version 2026-07-28, consultée le 10 septembre 2026.
[3] https://modelcontextprotocol.io/specification/2026-07-28/server/tools — Model Context Protocol, « Tools », version 2026-07-28, consultée le 10 septembre 2026.
[4] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization — Model Context Protocol, « Authorization », version 2026-07-28, consultée le 10 septembre 2026.
[5] https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations — Model Context Protocol, « Authorization Security Considerations », version 2026-07-28, consultée le 10 septembre 2026.
[6] https://developers.openai.com/api/docs/guides/tools-connectors-mcp — OpenAI, « MCP and Connectors », date de publication non affichée, consulté le 10 septembre 2026. Documentation fournisseur.
[7] https://platform.claude.com/docs/en/agents-and-tools/mcp-connector — Anthropic, « MCP connector », version mcp-client-2025-11-20, date de publication non affichée, consulté le 10 septembre 2026. Documentation fournisseur.
[8] https://www.anthropic.com/news/model-context-protocol — Anthropic, « Introducing the Model Context Protocol », publié le 25 novembre 2024, consulté le 10 septembre 2026. Annonce du créateur.
[9] https://youtrust.com/fr-fr/blog/mcp-vs-api — YouTrust, « MCP vs API : quelle intégration pour l’IA ? », publié le 24 juillet 2026, consulté le 10 septembre 2026. Source secondaire commerciale.
[10] https://workos.com/blog/mcp-vs-rest — WorkOS, « MCP vs. REST: What’s the right way to connect AI agents to your API? », publié le 13 mars 2026, consulté le 10 septembre 2026. Source secondaire commerciale.