MCP expliqué : ce qu'il connecte, ce qu'il ne fait pas et où il s'intègre

Le Model Context Protocol (MCP) est un protocole ouvert permettant de connecter des applications d'IA à des capacités et des informations externes via des contrats client-serveur standardisés. Un serveur MCP peut exposer des outils, des ressources et des invites ; un hôte ou client compatible MCP découvre et utilise ces capacités pour le compte d'une application d'IA. MCP n'exige pas que le serveur exécute son propre modèle de langage, et il ne remplace pas le runtime de l'agent, l'autorisation métier, l'isolation des locataires, les API applicatives ou l'architecture métier derrière les capacités exposées.

Ce que MCP standardise réellement

Avant MCP, chaque application d'IA pouvait intégrer des systèmes externes via son propre schéma d'outil, format de plugin, convention d'authentification et code de connexion. Le même service pouvait nécessiter différents adaptateurs pour un client d'IA de bureau, un agent IDE et une application personnalisée.

MCP crée une frontière de protocole réutilisable. Le système externe expose des capacités via un serveur MCP, tandis que les hôtes d'IA compatibles implémentent un client MCP. Cela réduit le couplage d'intégration entre l'application d'IA et le fournisseur d'outil ou de données sous-jacent.

Le protocole ne standardise pas l'application entière. Il standardise la manière dont les capacités sont décrites, découvertes et invoquées à travers cette frontière.

L'exemple le plus simple

Supposons qu'une application de codage d'IA ait besoin d'accéder à un répertoire de projet local. Sans MCP, l'application pourrait implémenter directement sa propre intégration de système de fichiers.

Avec MCP, un serveur de système de fichiers peut exposer des capacités telles que lister des répertoires, lire des fichiers approuvés ou écrire dans un espace de travail autorisé. L'hôte d'IA se connecte via un client MCP et présente ces capacités au modèle ou au runtime de l'agent.

Le serveur n'a pas besoin de comprendre la demande en langage naturel de l'utilisateur. L'hôte/le modèle décide quelle capacité est utile ; le serveur MCP exécute la requête structurée selon ses propres règles de sécurité.

Où l'exemple simple s'arrête

MCP ne définit pas comment l'hôte choisit un outil, comment un agent planifie, comment un flux de travail métier est modélisé ou comment un objet métier tel qu'une facture ou un déploiement doit se comporter.

Un protocole peut rendre l'intégration interopérable alors que l'application sous-jacente reste incorrecte, non sécurisée ou mal conçue. Une requête MCP parfaitement valide peut toujours appeler la mauvaise capacité métier.

La frontière centrale est la suivante : MCP normalise la sémantique d'intégration, pas la vérité applicative ni la justesse métier.

L'architecture MCP : hôte, client et serveur

Un hôte peut se connecter à plusieurs serveurs MCP, et un serveur MCP peut être en façade d'un ou de plusieurs systèmes sous-jacents. L'hôte reste responsable de l'intégration des résultats MCP dans l'application IA globale.

Le serveur peut être local à l'hôte, s'exécuter comme un processus séparé ou être distant via un transport réseau. La topologie d'hébergement et l'emplacement du modèle sont des décisions indépendantes.

Les trois primitives serveur fondamentales

Outils : capacités appelables

Les outils sont des opérations structurées qu'un serveur MCP met à la disposition de l'hôte. Un outil possède un nom, une description et un schéma d'entrée ; les implémentations modernes peuvent également fournir une sortie structurée.

Les exemples incluent la recherche dans un dépôt, la lecture d'une fiche client, la création d'un ticket, l'exécution d'une compilation ou l'envoi d'un message. Les outils peuvent être en lecture seule ou avoir des effets de bord.

Une bonne surface d'outils MCP devrait représenter des objectifs cohérents d'utilisateur ou d'agent plutôt que de refléter mécaniquement chaque point de terminaison d'API interne. Les opérations ayant des permissions, des exigences de confirmation ou un rayon d'impact différents devraient généralement être des outils distincts.

Ressources : contexte et données lisibles

Les ressources exposent des données ou du contenu qu'un client peut lister ou lire. Elles conviennent naturellement lorsque l'opération sémantique est « donne-moi cet artefact ou cette information » plutôt que « effectue cette action ».

Un URI de ressource n'est pas une autorisation d'accès. Le serveur reste maître du contrôle d'accès et doit vérifier quel principal peut lire l'objet sous-jacent.

La révision du protocole du 2026-07-28 ajoute une sémantique de cache pour les réponses de liste et de lecture de ressources, y compris la fraîcheur et la portée du cache, rendant le comportement de mise en cache plus explicite.

Invites : modèles réutilisables

Les invites MCP permettent à un serveur de publier des modèles d'invite réutilisables vers des clients compatibles. Cela peut maintenir les instructions spécifiques au domaine proches du fournisseur de capacités.

Une invite fournie par un serveur MCP n'a pas automatiquement priorité sur les instructions système ou de sécurité de l'hôte. L'hôte décide comment le matériel d'invite entre dans sa hiérarchie de contexte.

Le contenu des invites fourni par le protocole doit donc être traité comme des données de capacité avec une sémantique de confiance explicite, et non comme une autorité d'instruction illimitée.

Outil ou ressource ?

Où se trouve le modèle d'IA ?

MCP n'exige pas que le modèle s'exécute sur le serveur MCP. Le modèle peut être hébergé dans le cloud, hébergé localement, intégré à l'application de bureau ou atteint via un autre fournisseur.

L'hôte possède normalement l'interaction avec le modèle. Le serveur MCP expose une capacité externe. Un serveur MCP local peut donc être utilisé par un hôte dont le modèle s'exécute dans le cloud, et un serveur MCP distant peut être utilisé par un hôte dont le modèle s'exécute localement.

Si le serveur MCP lui-même appelle un LLM en interne, ce modèle fait partie de l'implémentation du serveur derrière la frontière du protocole ; il n'est pas requis par MCP.

MCP ne remplace pas les API

Un serveur MCP encapsule souvent des API ou services existants. REST, GraphQL, SQL, les appels SDK et les contrats de service internes peuvent rester exactement là où ils sont.

MCP ajoute une couche d'interopérabilité orientée IA. L'API de domaine sous-jacente peut rester le contrat applicatif faisant autorité pour les clients déterministes ordinaires.

L'architecture habituelle est donc d'abord l'API/service, puis la capacité orientée IA sélectionnée — et non « remplacer chaque API par MCP ».

MCP vs appel de fonction

OpenAI expose actuellement les serveurs MCP distants comme un type d'outil aux côtés de l'appel de fonction ordinaire, de la recherche web, du shell et d'autres outils. Cette implémentation illustre la relation architecturale : la connectivité MCP et l'interface d'appel d'outil propre au modèle peuvent être composées.

MCP ne crée pas la boucle de l'agent

Un agent IA a besoin d'un environnement d'exécution capable de décider, d'invoquer des outils, d'observer les résultats, de mettre à jour l'état et de continuer ou de s'arrêter. MCP peut fournir certains des outils et données utilisés par cette boucle.

Le serveur MCP ne devient pas automatiquement le planificateur, le système de mémoire ou l'orchestrateur. Ces responsabilités restent normalement dans l'hôte ou l'environnement d'exécution de l'agent.

Une application non agentique peut également utiliser MCP. Un appel d'outil MCP déterministe ne nécessite pas un agent autonome multi-étapes.

MCP vs A2A

MCP connecte principalement un hôte ou un agent IA à des capacités telles que des outils, des ressources et des données. A2A cible la collaboration entre systèmes d'agents indépendants.

Un agent distant peut utiliser MCP en interne pour accéder à des bases de données et des outils tout en exposant une interface A2A à d'autres agents. Les protocoles peuvent donc être superposés plutôt que substitués.

L'article existant sur la pile de protocoles couvre la comparaison plus large MCP/A2A/UCP/AP2/A2UI ; G02 reste la définition canonique de MCP.

L'utilisation locale et distante de MCP repose sur des réalités de transport différentes

MCP peut se connecter à des serveurs locaux et distants. Les intégrations de bureau locales utilisent couramment des transports au niveau du processus tels que stdio ; les serveurs distants utilisent un transport orienté HTTP.

La révision du 2026-07-28 rend le cœur du protocole sans état. Les requêtes transportent les informations nécessaires au traitement du protocole au lieu de dépendre du modèle de session antérieur au niveau du protocole.

La révision actuelle place également les noms de méthodes et de capacités dans les en-têtes HTTP afin que les passerelles, les WAF, les limiteurs de débit et les répartiteurs de charge puissent router et mesurer le trafic MCP plus naturellement.

Pourquoi la connaissance des versions de MCP est importante

La version du SDK et la version du protocole sont également deux choses différentes. Le SDK TypeScript v2 actuel est la ligne stable pour la révision du 2026-07-28, tandis que l'ancien v1.x reste une ligne de maintenance pour le comportement de l'ère 2025.

La documentation d'architecture doit enregistrer à la fois la version du SDK/de la bibliothèque et la révision du protocole lorsque le comportement d'interopérabilité en dépend.

Ce qui a changé dans MCP 2026-07-28

Roots, sampling et logging ne sont plus la direction pour les nouvelles implémentations

La version 2026-07-28 marque roots, sampling et logging comme des capacités de protocole obsolètes avec une fenêtre de compatibilité définie.

Les anciens tutoriels peuvent encore présenter ces fonctionnalités comme des primitives centrales. Les nouveaux travaux d'implémentation devraient suivre la spécification actuelle plutôt que de copier aveuglément d'anciens diagrammes de cycle de vie.

La dépréciation ne signifie pas un retrait immédiat. Elle signifie que les nouveaux systèmes devraient éviter les nouvelles dépendances inutiles envers des capacités dont le protocole s'éloigne.

Le travail de longue durée n'est pas la même chose qu'une invocation ordinaire d'outil MCP

Les opérations de longue durée nécessitent une sémantique de cycle de vie au-delà d'un simple résultat d'outil immédiat. Dans l'écosystème actuel, les Tasks ont été déplacées vers une extension MCP dédiée.

Cela renforce un principe de conception utile : le protocole de base n'a pas besoin d'absorber toutes les préoccupations d'exécution des agents.

Une application peut également conserver entièrement la propriété des flux de travail de longue durée dans son propre environnement d'exécution et utiliser les outils MCP ordinaires comme opérations sous-jacentes.

Les MCP Apps étendent les capacités d'interface utilisateur sans redéfinir le protocole de base

Les MCP Apps associent des expériences d'interface utilisateur interactives plus riches aux outils MCP via le modèle d'extension.

L'hôte contrôle toujours la manière dont cette interface utilisateur est intégrée, isolée et sécurisée.

L'échange de capacités de base et le rendu de l'interface utilisateur devraient donc rester des responsabilités architecturales distinctes.

L'autorisation MCP n'est pas votre modèle d'autorisation complet

Le MCP distant nécessite des mécanismes d'authentification et d'autorisation au niveau du protocole afin que les clients et les serveurs puissent établir un accès de confiance. La spécification actuelle continue de renforcer le comportement lié à OAuth/OIDC.

Cette couche répond à la question de savoir si un client est autorisé à se connecter ou à demander des portées de protocole. Elle ne répond pas automatiquement à la question de savoir si Alice peut rembourser la commande 123, si un agent peut écrire la configuration de production ou si le Locataire A peut lire les données du Locataire B.

Ces décisions de domaine appartiennent au modèle d'autorisation du serveur/de l'application et doivent être appliquées avant d'invoquer l'opération sous-jacente.

L'identité peut franchir plusieurs frontières

Une requête MCP peut impliquer l'application cliente MCP, l'humain connecté, une identité d'agent/session et un compte de service en aval.

Le serveur a besoin d'une politique explicite pour déterminer au nom de quel principal l'opération est effectuée. Sinon, un identifiant de service puissant peut devenir un chemin de député confus.

Pour un usage en entreprise, la corrélation entre l'identité de l'utilisateur, l'identité de l'agent, la connexion MCP et l'autorisation en aval est aussi importante que la compatibilité des protocoles.

L'isolation des locataires reste en dehors de la découverte des capacités MCP

Un serveur MCP multi-locataires doit appliquer la portée du locataire lorsqu'il lit ou modifie des ressources appartenant à un locataire. Le retour d'un outil nommé search_documents ne définit pas à quel locataire appartiennent les documents éligibles.

La portée du locataire doit être dérivée d'une identité ou d'une appartenance de confiance et propagée dans les bases de données, les caches, la recherche vectorielle, le stockage d'objets et les API en aval.

Récupérer du contenu inter-locataires et demander au modèle de ne pas l'utiliser constitue déjà une défaillance d'isolation.

MCP ne définit pas la source de vérité

Un serveur MCP peut exposer une base de données, un référentiel de documents, un service de recherche web ou un résumé généré par IA. Le protocole ne déclare pas quelle source fait autorité pour une affirmation.

Les règles de source de vérité relèvent de l'architecture applicative ou métier. L'hôte ou le serveur peut encoder l'autorité via la conception des outils, les métadonnées, la politique d'accès ou la validation, mais MCP lui-même ne rend pas une capacité « vraie ».

Un outil peut donc être parfaitement appelable via MCP et néanmoins renvoyer des informations obsolètes, secondaires ou non faisant autorité.

MCP et ingénierie du contexte

MCP peut accroître les capacités et les informations disponibles pour une application d'IA, mais l'ingénierie du contexte détermine toujours ce qui parvient au modèle.

Les catalogues d'outils consomment le contexte visible par le modèle dans de nombreux hôtes. Les résultats d'outils peuvent être volumineux. Les ressources peuvent être nombreuses. Un hôte a besoin de sélection, de filtrage, de chargement dynamique et de compactage plutôt que d'exposer tout à chaque tour.

La disponibilité des capacités et le contexte visible par le modèle doivent donc être traités comme des couches distinctes.

Concevoir les outils MCP autour des résultats et des limites de risque

Les approbations relèvent de l'architecture d'exécution

Un hôte peut exiger l'approbation de l'utilisateur avant d'invoquer certains outils MCP. L'intégration MCP actuelle d'OpenAI prend en charge des modèles d'exécution automatiques ou avec approbation explicite.

L'approbation par l'hôte est utile mais ne doit pas être la seule protection du serveur, car un autre client MCP compatible peut utiliser un modèle d'approbation différent.

Pour les actions destructrices ou ayant des conséquences financières, utilisez la défense en profondeur : un contrat d'outil clair, une approbation à l'exécution lorsque cela est approprié, une autorisation côté serveur, une validation métier et un audit.

L'observabilité MCP doit relier les appels de protocole aux actions métier

Une trace MCP est plus utile lorsqu'elle peut être corrélée à l'appel applicatif sous-jacent, à la modification de base de données ou à la transaction métier.

L'écosystème du 2026-07-28 standardise les conventions de propagation du W3C Trace Context, ce qui facilite le suivi d'une requête à travers l'hôte, le client, le serveur et les services en aval.

Les journaux de protocole seuls ne suffisent pas pour les opérations à conséquences. Les preuves d'audit doivent également enregistrer le principal concerné, le tenant, la ressource cible, l'approbation et le changement d'état résultant.

Ce que MCP ne peut pas corriger

Preuves d'implémentation originale : Aaasaasa AI Client

L'application peut exécuter un point de terminaison MCP Streamable HTTP authentifié sur l'interface de bouclage. Le point de terminaison n'expose que les répertoires sélectionnés via le courtier de permissions central de l'espace de travail.

Le point de terminaison local et la route distante sont des préoccupations distinctes : le connecteur local peut se lier uniquement à l'interface de bouclage, tandis qu'un Secure MCP Tunnel peut rendre le service MCP approuvé accessible à un client IA externe autorisé sans exposer toute la machine locale.

Le modèle de permissions central distingue les profils chat uniquement, lecture seule, écriture de projet et répertoire personnalisé. Direct Chat n'a aucun accès au système de fichiers ni au shell ; les environnements d'exécution d'agents capables d'utiliser des outils utilisent le profil de permissions sélectionné.

Il s'agit d'une implémentation directe de la frontière G02 : MCP fournit la connexion de capacité standardisée, tandis que le courtier de permissions propre à l'application décide quels répertoires le serveur peut exposer.

Quand MCP est adapté

Quand vous n'avez pas besoin de MCP

N'ajoutez pas MCP simplement parce que l'application utilise l'IA. Si votre backend appelle déjà une API interne et qu'aucun client MCP indépendant n'a besoin de cette capacité, un appel de fonction ou de service ordinaire peut être plus clair.

MCP apporte de la valeur à une frontière d'interopérabilité. Sans cette frontière, le protocole peut devenir une couche d'adaptation inutile.

La question architecturale n'est pas « Ce projet a-t-il de l'IA ? » mais « Des hôtes IA et des fournisseurs de capacités évoluant indépendamment bénéficient-ils d'un contrat standard ? »

Liste de contrôle de sécurité MCP

Idées fausses courantes

Une séquence de conception MCP pratique

Liste de contrôle de l'architecture MCP

Cas limites et limitations

Un serveur MCP stdio local peut avoir une faible exposition réseau tout en restant dangereux si le processus lui-même dispose de permissions excessives sur le système de fichiers ou le shell.

Un serveur MCP distant peut n'exposer que de la documentation publique ou des actions d'entreprise hautement sensibles. « MCP distant » dit peu de choses sur le risque sans le contexte de capacité et d'autorisation.

Certains serveurs peuvent n'utiliser que des outils et ignorer les ressources/invites. La compatibilité MCP n'exige pas que chaque primitive optionnelle soit également importante.

Un hôte peut traduire entre son propre modèle d'outil interne et MCP. Les utilisateurs peuvent ne jamais voir directement la frontière du protocole, ce qui est acceptable si la sécurité et l'attribution restent claires.

MCP continue d'évoluer rapidement. Les extensions, les modèles d'autorisation, les API des SDK et les conventions de l'écosystème peuvent changer plus vite que la distinction architecturale fondamentale.

Qu'est-ce qui changerait cette réponse ?

Les futures révisions de MCP peuvent modifier le cycle de vie, les transports, l'autorisation et les mécanismes d'extension. La révision de juillet 2026 démontre déjà pourquoi les affirmations spécifiques à une implémentation doivent être datées.

La frontière canonique ne changerait que si MCP s'étendait d'un protocole d'interopérabilité à une norme d'architecture d'application/agent de bout en bout. Ce n'est pas ce que définit le protocole actuel.

Pour le travail d'implémentation, consultez toujours la spécification actuelle et la ligne SDK exacte au lieu de copier des exemples sensibles à la version provenant d'anciens tutoriels.

Connaissances canoniques associées

MCP se situe en aval de l'IA agentique : comprenez d'abord la frontière agent/runtime/outil, puis utilisez MCP lorsque des capacités externes nécessitent un contrat de protocole portable.

MCP dépend également du RBAC et de l'isolation des locataires, car l'exposition des capacités au niveau du protocole ne détermine pas l'autorisation applicative.

L'article plus large sur la pile de protocoles explique où MCP se situe aux côtés d'A2A, UCP, AP2 et A2UI. G02 reste la source canonique pour MCP lui-même.

Questions fréquentes

Glossaire

Conclusion

MCP est plus facile à comprendre lorsque sa frontière reste étroite : il connecte les applications d'IA à des capacités externes via un protocole standard.

Le modèle n'a pas besoin de résider sur le serveur MCP. Le serveur ne devient pas le runtime de l'agent. Un outil répertorié ne devient pas une action métier autorisée. Et MCP ne remplace pas l'API sous-jacente, la source de vérité, l'isolation des locataires ou l'architecture du domaine.

Cette étroitesse est la force du protocole. MCP peut standardiser la manière dont les systèmes d'IA accèdent aux outils et aux données tout en laissant la propriété applicative, la sécurité, la sémantique métier et le choix du modèle aux couches qui en sont réellement responsables.

Sources primaires et documentation actuelle

MCP évolue rapidement, donc les affirmations sensibles à la version dans cet article sont liées à l'état du 8 octobre 2026. La section Aaasaasa AI Client est une preuve d'implémentation originale et est explicitement limitée au périmètre vérifié du connecteur MCP et du courtier de permissions.