MCP (Model Context Protocol) : définition, fonctionnement et exemples

Un agent IA qui ne peut parler qu'à lui-même ne sert pas à grand-chose. Pour agir vraiment, il doit lire vos fichiers, interroger vos bases, écrire dans vos outils. MCP est le protocole né pour standardiser cette connexion, plutôt que de la réinventer à chaque nouvel outil.

Définition détaillée

Le site officiel du protocole le définit ainsi : MCP est « un standard ouvert pour connecter des applications IA à des systèmes externes », qui leur permet d'accéder à des sources de données (fichiers locaux, bases de données), à des outils (moteurs de recherche, calculatrices) et à des workflows (prompts spécialisés). Sa propre documentation résume l'idée avec une image simple : MCP est « comme un port USB-C pour les applications IA », un connecteur standardisé plutôt qu'un câble différent pour chaque appareil.

Le protocole a été annoncé par Anthropic le 25 novembre 2024. L'annonce décrit le problème que MCP cherche à résoudre : les assistants IA restaient isolés de données pourtant critiques, chaque nouvelle source imposant une implémentation sur mesure, ce qui créait un problème d'intégration qui se démultipliait à chaque nouvel outil et à chaque nouveau modèle. Anthropic a publié en même temps la spécification, des kits de développement et un dépôt de serveurs MCP de référence pour des outils comme Google Drive, Slack, GitHub, Git ou Postgres. Voir l'annonce d'Anthropic.

IBM propose une formulation technique complémentaire : MCP est « une couche de standardisation permettant aux applications IA de communiquer efficacement avec des services externes, comme des outils, des bases de données ou des modèles de prompts prédéfinis ». Cette description insiste sur un point souvent oublié : MCP ne dit pas à un agent quand utiliser un outil, ni comment orchestrer plusieurs étapes. Il standardise seulement la façon dont l'outil se décrit et se connecte. Voir la fiche IBM sur MCP.

Comment ça marche

MCP suit une architecture client-serveur à trois rôles, décrite en détail par la documentation officielle et reprise par Microsoft dans sa doc .NET. L'hôte MCP (MCP host) est l'application IA elle-même, comme un assistant ou un éditeur de code. Il crée un client MCP dédié pour chaque service auquel il se connecte. Chaque client maintient une connexion avec un serveur MCP, le programme qui expose réellement des données ou des actions. Un serveur MCP peut tourner en local sur la machine de l'utilisateur, ou à distance sur les serveurs du fournisseur de l'outil.

Concrètement, un serveur MCP expose trois types d'éléments : des outils (des actions que l'agent peut déclencher, comme interroger une base ou envoyer un message), des ressources (des données consultables, comme le contenu d'un fichier) et des prompts (des modèles de requête réutilisables). Le client interroge d'abord le serveur pour savoir ce qu'il propose, puis peut appeler un outil précis avec des arguments précis, un fonctionnement proche de celui décrit dans notre article sur le tool calling.

C'est justement là que les sources divergent sur la portée exacte de MCP. IBM et Microsoft s'accordent pour dire que MCP ne remplace pas le tool calling : c'est le mécanisme qui reste en dessous, celui par lequel un modèle demande concrètement l'exécution d'une action. Ce que MCP ajoute, c'est une façon commune de décrire et de découvrir ces outils, indépendante du fournisseur de modèle, là où chaque fournisseur imposait auparavant son propre format d'appel. De la même façon, MCP ne remplace pas les API classiques : la doc .NET de Microsoft précise qu'un serveur MCP « peut fournir une abstraction au-dessus d'une API REST » pour exposer des données métier à un modèle. MCP est donc une façade commune posée sur des API existantes, pas une technologie qui les rend inutiles.

Un serveur MCP peut aussi exposer une base documentaire à interroger avant de répondre, un usage qui recoupe directement le principe du RAG : chercher d'abord dans une source fiable, puis générer la réponse à partir de ce qui a été trouvé.

Exemple concret avec Atako

Le plan Standard d'Atako liste « Atako MCP » parmi ses fonctionnalités incluses, aux côtés des intégrations, de l'observabilité ou du BYOK, sur la page tarifs. Une clé API générée depuis les réglages du compte sert, entre autres usages, à connecter des clients MCP externes à la plateforme.

Le reste de la mise en œuvre précise, quels serveurs, quels outils exposés dans le détail, n'est pas documenté publiquement à ce jour. Mieux vaut rester factuel sur ce point plutôt que de deviner une liste d'outils ou une date de lancement.

Erreurs fréquentes

Première erreur : croire que MCP est un mécanisme entièrement nouveau qui remplacerait le tool calling. Ce n'est pas le cas, MCP standardise la description et la découverte des outils, mais l'appel lui-même reste un appel de fonction classique, produit par le modèle.

Deuxième erreur : penser qu'un « serveur MCP » désigne forcément une grosse machine distante. La documentation officielle distingue clairement les serveurs locaux, qui tournent sur l'ordinateur de l'utilisateur et communiquent en local, des serveurs distants, hébergés par le fournisseur de l'outil et accessibles par HTTP.

Troisième erreur : confondre MCP avec une garantie de sécurité en soi. Le protocole standardise la façon dont un modèle découvre et appelle un outil, il ne décide pas à sa place des permissions accordées à cet outil. Sur une plateforme sérieuse, cette décision reste une couche séparée, indépendante du protocole de connexion utilisé.

Quatrième erreur : croire que tout outil connecté à un agent passe forcément par MCP. Beaucoup d'agents, y compris ceux qui utilisent des intégrations comme GitHub ou Slack, appellent des actions par tool calling classique sans passer par un serveur MCP dédié. Atako ne documente pas publiquement le détail des outils exposés par son propre MCP : MCP reste une option de connexion parmi d'autres, pas un passage obligé pour donner des outils à un agent.

Pour aller plus loin

MCP s'est imposé assez vite comme un standard soutenu par un large écosystème : la documentation officielle cite des applications comme Claude ou des éditeurs de code comme Visual Studio Code et Cursor parmi les clients MCP compatibles. Pour comprendre les briques voisines de ce protocole, direction le glossaire complet, avec les termes tool calling, RAG et BYOK, tous des mécanismes de connexion ou de configuration côté modèle.