MCP

Définition, fonctionnement et rôle du MCP dans les architectures IA

Le Model Context Protocol, ou MCP, est un protocole ouvert destiné à standardiser la manière dont les applications utilisant des modèles d’intelligence artificielle accèdent à des données, des outils, des services et des applications externes.

L’idée répond à un problème devenu central avec le développement des assistants et des agents IA : un modèle de langage peut raisonner sur les informations présentes dans son contexte, mais il ne sait pas spontanément consulter un CRM, interroger une base de données, lire un document d’entreprise, rechercher une information dans un CMS ou déclencher une action dans une plateforme marketing.

Sans standard commun, chaque connexion doit être développée spécifiquement. MCP introduit au contraire une interface commune entre les applications IA et les systèmes avec lesquels elles doivent interagir.

Définition courte
Le Model Context Protocol est un standard ouvert d’interopérabilité pour l’IA. Il permet à une application ou à un agent IA de découvrir des données et des capacités proposées par des systèmes externes, puis de les utiliser à travers un protocole commun.

Une analogie souvent utilisée consiste à voir MCP comme une sorte d’USB-C pour les applications d’IA : le protocole ne définit pas ce que fait chaque périphérique — ou ici chaque application métier — mais fournit une façon standard de les connecter.

Pourquoi le Model Context Protocol a-t-il été créé ?

Les premiers usages des grands modèles de langage reposaient essentiellement sur le contenu envoyé dans un prompt. Puis les applications ont commencé à enrichir ce contexte avec des documents, des moteurs de recherche, des bases vectorielles, des appels d’API et des fonctions exécutables.

Cette évolution a rapidement créé un problème d’intégration. Une application souhaitant connecter un modèle à dix services différents devait généralement gérer dix mécanismes d’intégration, dix formats de fonctions, dix systèmes d’authentification et différentes méthodes de description des capacités disponibles.

MCP cherche à réduire cette fragmentation. Un serveur conforme au protocole peut décrire les données et les fonctions qu’il met à disposition. Une application compatible MCP peut ensuite les découvrir et les exploiter sans devoir inventer un mécanisme propriétaire pour chaque nouvelle intégration.

MCP ne supprime donc pas les API. Il fournit plutôt une couche standard permettant aux applications IA de découvrir et d’utiliser plus facilement des API, bases de données, fichiers, logiciels ou services existants.

Comment fonctionne MCP ?

MCP repose sur une architecture client-serveur. Trois rôles sont essentiels : le Host, le Client MCP et le Serveur MCP.

Architecture MCP : sélectionnez un composant pour découvrir son rôle dans les échanges entre une application IA et les systèmes métiers.

Application IA / Host

Le Host est l’application dans laquelle fonctionne l’expérience IA : assistant conversationnel, agent autonome, IDE ou logiciel métier intégrant un LLM.

Il héberge les clients MCP et conserve généralement le contrôle sur les autorisations, l’affichage des résultats et les validations des actions sensibles.

Flux de communication Cliquez sur les composants pour explorer leur rôle.

Tools, Resources et Prompts : les trois primitives essentielles

Le fonctionnement de MCP devient beaucoup plus simple à comprendre lorsqu’on distingue ses trois principales primitives côté serveur.

Tools : des capacités exécutables

Les Tools sont des fonctions que l’application IA peut appeler pour récupérer une information ou réaliser une action.

Exemple : rechercher un client, interroger une API, créer une tâche, mettre à jour un enregistrement ou lancer une analyse.

Ressources : des données accessibles

Les Resources donnent accès à des contenus pouvant être ajoutés au contexte de l’IA.

Il peut s’agir d’un document, d’un contenu CMS, d’un schéma de base de données, de données issues d’une API ou d’un fichier.

Prompts : des modèles d’interaction

Les Prompts sont des modèles réutilisables permettant de structurer certaines interactions avec le modèle.

Ils peuvent encapsuler des instructions, des paramètres ou des exemples adaptés à un workflow particulier.

La distinction est importante. Un outil correspond essentiellement à quelque chose que l’IA peut faire, une ressource à quelque chose qu’elle peut consulter, et un prompt à une manière prédéfinie d’organiser une interaction.

La découverte des capacités : un élément clé de MCP

L’un des intérêts de MCP est que le client n’a pas nécessairement besoin de connaître à l’avance toutes les fonctions proposées par un serveur.

Le protocole prévoit des mécanismes de découverte permettant d’identifier les versions du protocole prises en charge, les capacités disponibles et les Tools, Resources ou Prompts exposés.

Cette caractéristique est particulièrement importante pour les agents IA. Un agent peut découvrir qu’un serveur propose par exemple les outils search_customer, get_campaign_performance ou create_segment, comprendre leurs paramètres puis décider d’utiliser celui qui correspond à son objectif.

La véritable rupture n’est donc pas uniquement la standardisation de l’appel d’une fonction. MCP standardise également la manière dont une application IA découvre ce qu’un système est capable de lui proposer.

Un protocole conçu pour des architectures IA plus distribuées

MCP utilise des messages structurés reposant sur JSON-RPC 2.0. La spécification distingue une couche de données, qui décrit les messages et les primitives du protocole, et une couche de transport qui définit la manière dont ces messages circulent.

Pour les intégrations locales, MCP peut utiliser stdio, c’est-à-dire les flux standards entre deux processus exécutés sur une même machine. Pour les serveurs distants, le transport privilégié est Streamable HTTP, adapté aux infrastructures web et cloud.

Le cœur actuel du protocole suit par ailleurs une logique stateless : chaque requête transporte les informations nécessaires à son traitement, notamment la version du protocole et les capacités pertinentes. Cette évolution facilite la répartition des requêtes entre plusieurs instances d’un serveur, le caching et l’intégration avec des architectures cloud classiques.

Lorsqu’une opération nécessite une information supplémentaire en cours d’exécution — une confirmation utilisateur, par exemple — MCP prévoit également des échanges en plusieurs étapes. Le serveur peut demander une information complémentaire, puis le client relancer l’opération avec la réponse obtenue.

MCP peut-il seulement lire des données ?

Non. C’est précisément l’une des différences importantes entre MCP et une simple couche documentaire.

Un serveur peut exposer des ressources en lecture mais également des Tools capables de produire des effets réels : modifier une donnée dans un CRM, créer un document, lancer une requête, déclencher un workflow ou appeler un service externe.

Cette capacité rapproche MCP des architectures dites agentiques, dans lesquelles un modèle ne se contente plus de générer du texte mais peut sélectionner et utiliser des outils afin d’atteindre un objectif.

Elle implique cependant une exigence supplémentaire : la capacité technique d’effectuer une action ne doit jamais être confondue avec l’autorisation de l’effectuer.

Les extensions : MCP va au-delà des simples appels d’outils

Le protocole dispose d’un mécanisme d’extensions permettant d’ajouter de nouvelles capacités sans alourdir son cœur. Ces extensions sont optionnelles : client et serveur doivent annoncer leur prise en charge avant de les utiliser.

MCP Apps : Interfaces interactives

MCP Apps permet à un serveur de fournir une interface utilisateur interactive pouvant être affichée directement par un Host compatible : graphique, formulaire, tableau de bord, média ou interface métier.

Tasks : Travaux asynchrones

L’extension Tasks permet de gérer des opérations longues. Le serveur peut retourner un identifiant durable plutôt que de bloquer la connexion jusqu’à la fin du traitement.

Skills : Instructions de workflow

Les Skills permettent de distribuer des instructions structurées destinées aux agents, notamment lorsque l’utilisation efficace d’un ensemble d’outils nécessite un workflow plus élaboré.

Cette logique d’extensions montre que MCP évolue progressivement d’un protocole de connexion aux données et outils vers une infrastructure plus générale d’interaction entre applications, agents et services IA.

MCP, API et function calling : quelle différence ?

MCP n’est pas destiné à remplacer les API REST, GraphQL ou autres interfaces applicatives. Dans de nombreux cas, un serveur MCP s’appuie justement sur ces API.

Une API décrit généralement la manière dont un logiciel peut dialoguer avec un service précis. MCP ajoute une couche adaptée aux applications d’IA : découverte des capacités, description des outils, échange de contexte et conventions communes entre clients et serveurs.

Le function calling proposé par les fournisseurs de modèles poursuit quant à lui un objectif plus restreint : fournir au modèle une description de fonctions qu’il peut choisir d’appeler. MCP peut s’appuyer sur ce mécanisme mais définit un contrat beaucoup plus large autour de la connexion entre l’application IA et les systèmes externes.

API : comment accéder à un service.
Function calling : comment un modèle demande l’exécution d’une fonction.
MCP : comment une application IA découvre, décrit et utilise de manière standardisée les données et capacités de systèmes externes.

MCP et RAG : deux concepts complémentaires

MCP est également différent du RAG — Retrieval-Augmented Generation.

Le RAG est une architecture destinée à rechercher des informations pertinentes dans une source documentaire puis à les fournir au modèle afin d’améliorer sa réponse. MCP est un protocole d’accès et d’interopérabilité.

Les deux peuvent parfaitement fonctionner ensemble. Un serveur MCP peut, par exemple, exposer un moteur de recherche documentaire comme Tool ou rendre certaines sources accessibles sous forme de Resources. Une application peut ensuite utiliser ces informations dans son propre pipeline RAG.

Autrement dit, RAG décrit une stratégie d’utilisation de la connaissance ; MCP décrit une manière standard de connecter cette connaissance et d’autres capacités à une application IA.

MCP et communication entre agents

Une autre confusion consiste à assimiler MCP à un protocole de communication entre agents.

Son objectif principal est différent. MCP standardise surtout la relation entre une application IA et les outils ou données dont elle a besoin. Les protocoles orientés agent-à-agent cherchent plutôt à organiser les échanges, la délégation ou la collaboration entre plusieurs agents autonomes.

Les deux approches sont complémentaires. Un agent peut utiliser un protocole de coopération pour dialoguer avec d’autres agents, tout en utilisant MCP pour accéder à ses propres outils et systèmes métiers.

Pourquoi MCP est particulièrement intéressant pour les MarTech ?

Les environnements marketing sont historiquement très fragmentés. CRM, CDP, CMS, DAM, solutions analytics, plateformes publicitaires, marketing automation, outils de social listening ou moteurs de personnalisation possèdent leurs propres API et modèles de données.

Cette fragmentation devient encore plus problématique avec les agents IA. Pour qu’un agent marketing puisse véritablement assister un utilisateur, il doit être capable de naviguer entre plusieurs briques de la stack MarTech.

MCP peut servir de couche d’interopérabilité entre ces systèmes et les nouveaux assistants ou agents.

CRM

Rechercher un compte, résumer l’historique d’un client, préparer une mise à jour ou créer une activité.

CDP

Consulter un segment, analyser ses caractéristiques ou préparer la définition d’une nouvelle audience.

Analytics et BI

Interroger des indicateurs, expliquer une variation ou alimenter une analyse marketing.

CMS et DAM

Rechercher des contenus et assets, récupérer leurs métadonnées ou préparer une modification.

Marketing automation

Consulter un workflow, vérifier une campagne ou préparer une action d’activation.

Customer service

Combiner données CRM, documentation et outils opérationnels pour assister un conseiller ou un agent IA.

À terme, l’intérêt est évident : éviter que chaque assistant IA doive disposer d’un connecteur spécifique développé séparément pour chacune des solutions de la stack.

Cela ne signifie toutefois pas que toutes les MarTech deviennent automatiquement compatibles entre elles. Le protocole standardise l’accès aux capacités, mais il ne standardise pas les concepts métiers eux-mêmes. Deux CDP peuvent continuer à définir très différemment un profil, un événement, une audience ou une identité client.

Quels sont les principaux avantages de MCP ?

Interopérabilité

Une application compatible MCP peut exploiter plusieurs serveurs suivant un contrat technique commun.

Portabilité

Un même serveur peut potentiellement être utilisé par plusieurs Hosts ou environnements IA compatibles.

Composabilité

Un agent peut combiner les capacités de plusieurs serveurs pour réaliser un workflow plus complexe.

MCP peut également réduire la quantité de « glue code » nécessaire entre les modèles et les applications. Pour les équipes techniques, cela rend plus réaliste la construction d’un catalogue de capacités réutilisables par plusieurs assistants ou agents.

Quelles sont les limites de MCP ?

MCP apporte un standard d’interopérabilité, mais un protocole ne résout pas à lui seul les problèmes d’intégration.

Il faut toujours développer ou configurer le serveur capable de communiquer avec le système cible. Les questions de qualité des données, de quotas d’API, de droits utilisateurs, de mapping des objets métiers et de disponibilité des services demeurent.

MCP ne garantit pas non plus qu’un modèle utilisera correctement un outil. Une description ambiguë, des fonctions trop proches ou des paramètres mal conçus peuvent conduire l’agent à sélectionner une mauvaise opération.

Enfin, l’ouverture d’outils opérationnels à des agents augmente mécaniquement la surface de risque. Les architectures sérieuses doivent donc associer MCP à une véritable politique de gouvernance des identités, des données et des actions automatisées.

MCP et sécurité : un protocole d’accès n’est pas une autorisation universelle

La sécurité est l’un des enjeux fondamentaux de MCP. Un Tool peut avoir accès à des données confidentielles ou déclencher une action possédant des conséquences réelles.

La spécification prévoit des mécanismes d’autorisation adaptés notamment aux environnements HTTP et s’appuie sur des standards tels qu’OAuth. Mais MCP ne rend pas automatiquement une intégration sûre.

Principe essentiel

Un agent ne devrait disposer que des données et capacités strictement nécessaires à sa mission. Les actions sensibles doivent pouvoir être identifiées, contrôlées, tracées et, lorsque cela est nécessaire, validées explicitement par l’utilisateur.

Il faut notamment prendre en compte les risques liés à des serveurs non fiables, au détournement d’autorisations, au passage incorrect de jetons d’accès, aux appels vers des ressources non prévues ou à des contenus susceptibles d’influencer le comportement du modèle.

Dans les environnements d’entreprise, MCP doit donc être intégré aux mécanismes habituels de gestion des identités, contrôle d’accès, journalisation, supervision et principe du moindre privilège.

De Anthropic à une gouvernance ouverte

MCP a été initialement lancé en open source par Anthropic avec l’ambition de créer un standard commun permettant aux assistants IA de se connecter aux systèmes où résident les données.

Le protocole a depuis dépassé le cadre d’un seul fournisseur. Sa gouvernance a été transférée à l’Agentic AI Foundation, hébergée par la Linux Foundation, afin de développer le projet dans un cadre plus neutre et communautaire.

Cette évolution est importante : la valeur d’un protocole d’interopérabilité augmente avec le nombre de plateformes capables de l’implémenter. MCP présente donc davantage d’intérêt comme standard transversal que comme fonctionnalité associée à un modèle ou à un éditeur particulier.

Pourquoi MCP pourrait devenir une couche importante des architectures IA

L’enjeu de MCP dépasse la simple connexion d’un chatbot à quelques API.

À mesure que les applications deviennent plus agentiques, les modèles ont besoin d’un moyen cohérent pour découvrir leur environnement, récupérer du contexte, sélectionner des outils, demander des informations supplémentaires et lancer des actions.

MCP fournit une partie de cette infrastructure.

Il ne définit ni le modèle utilisé, ni la stratégie de raisonnement de l’agent, ni la logique métier du logiciel. Il crée plutôt une frontière standardisée entre l’intelligence du système et les ressources qu’elle peut mobiliser.

Pour les MarTech, l’intérêt potentiel est considérable : MCP peut devenir une couche commune entre les assistants et agents IA d’un côté, et la stack marketing de l’autre.

Le véritable changement serait alors de passer d’une logique où chaque IA possède ses propres connecteurs à une logique où les capacités métiers deviennent découvrables et réutilisables par plusieurs environnements IA.

Questions fréquentes sur MCP

MCP est-il une API ?
Non. MCP est un protocole qui peut notamment permettre à une IA d’utiliser des services exposés par des API. Il standardise la manière de présenter et d’utiliser ces capacités dans des applications IA.
MCP remplace-t-il le RAG ?
Non. Le RAG est une méthode permettant d’enrichir la génération grâce à des informations récupérées dans des sources externes. MCP peut fournir un moyen standard d’accéder à certaines de ces sources.
Un serveur MCP est-il nécessairement distant ?
Non. Un serveur MCP peut être exécuté localement, par exemple via stdio, ou être proposé à distance via HTTP.
MCP permet-il d’effectuer des actions ?
Oui. Les Tools peuvent effectuer des opérations et pas uniquement lire des données. Les permissions et les validations deviennent donc essentielles dès qu’un outil produit des effets de bord.
MCP est-il lié à un modèle d’IA particulier ?
Non. MCP est conçu comme un standard ouvert indépendant d’un modèle précis. Son intérêt réside justement dans la possibilité d’être utilisé par différents Hosts, modèles et environnements.
MCP garantit-il la sécurité des agents ?
Non. Le protocole fournit un cadre et des mécanismes d’autorisation, mais la sécurité dépend également du Host, du serveur, des politiques d’accès, des outils exposés et de la gouvernance mise en œuvre.

À retenir

Le Model Context Protocol est une couche d’interopérabilité destinée aux applications et agents IA. Il standardise la manière de découvrir et d’utiliser des outils, des données et des capacités proposées par des systèmes externes.

Son intérêt ne réside donc pas seulement dans la connexion d’un LLM à une source de données. MCP contribue à créer un écosystème dans lequel les capacités d’une application peuvent être exposées une fois puis potentiellement réutilisées par de nombreux environnements IA compatibles.

Quelques références

« Introducing the Model Context Protocol » — Anthropic — Anthropic — novembre 2024
« Model Context Protocol Specification » — MCP Core Maintainers — Model Context Protocol — juillet 2026
« Architecture overview » — MCP Core Maintainers — Model Context Protocol — juillet 2026
« The 2026-07-28 Specification » — David Soria Parra, Den Delimarsky — Model Context Protocol Blog — juillet 2026
« MCP Apps – Bringing UI Capabilities To MCP Clients » — MCP Core Maintainers — Model Context Protocol Blog — janvier 2026
« Linux Foundation Announces the Formation of the Agentic AI Foundation » — The Linux Foundation — Linux Foundation — décembre 2025