Le Model Context Protocol (MCP) expliqué : fonctionnement, outils et sécurité

Le Model Context Protocol (MCP) fournit aux applications IA une méthode standard pour découvrir du contexte et appeler les tools exposés par des systèmes externes. Il peut relier un assistant de code à un dépôt, un agent projet à un board vivant ou un assistant interne à des données d'entreprise autorisées.

MCP résout un problème d'intégration. Il ne rend pas tous les clients aussi capables, n'accorde aucune permission automatiquement et ne rend pas un serveur inconnu digne de confiance.

Qu'est-ce que MCP ?

MCP est un protocole ouvert pour échanger du contexte et des actions entre des applications IA et des systèmes externes. Un serveur décrit ce qu'il peut exposer. Une application hôte s'y connecte, négocie les capacités prises en charge et décide comment les présenter à l'utilisateur ou à l'agent.

L'analogie de « l'USB de l'IA » est parlante, mais incomplète. Un connecteur physique n'a pas à décider qui peut lire un document, si une écriture exige une approbation ou comment le résultat d'un tool est transmis à un modèle. Une intégration MCP en production doit le faire.

La documentation officielle de l'architecture MCP distingue trois rôles :

• L'hôte — l'application IA qui gère l'expérience, les frontières de sécurité et un ou plusieurs clients MCP ;
• Le client — le composant protocolaire intégré à l'hôte qui maintient une connexion avec un serveur ;
• Le serveur — le programme ou service qui expose des capacités et traite les requêtes.

Le modèle d'IA n'est pas lui-même le client MCP. L'hôte décide quand la sortie du modèle doit déclencher un appel de tool, puis comment le résultat est présenté ou réinjecté dans la conversation.

Les capacités exposées par MCP

Les serveurs peuvent exposer trois primitives principales :

• Tools — opérations que l'hôte peut appeler, comme créer une carte, interroger une base de données ou publier un commentaire ;
• Resources — éléments de contexte adressables que l'hôte peut lire, comme un document projet ou un fichier de dépôt ;
• Prompts — modèles de prompts réutilisables proposés par le serveur.

Les clients peuvent aussi annoncer des capacités comme les roots, le sampling ou l'elicitation. Leur prise en charge est négociée à l'initialisation : un serveur ne doit donc pas supposer que chaque hôte implémente toutes les fonctions.

Dans la pratique, beaucoup d'intégrations se concentrent sur les tools. Une définition utile possède un nom clair, une description précise, un schéma d'entrée et des erreurs prévisibles. Le serveur doit tout de même autoriser chaque appel : découvrir un tool ne donne pas le droit de tout exécuter.

Comment se déroule une connexion MCP

Une session suit généralement ces étapes :

1. L'hôte ouvre une connexion par l'intermédiaire d'un client MCP.
2. Le client et le serveur négocient la version du protocole et leurs capacités.
3. Le client découvre les tools, resources et prompts accessibles à cette identité.
4. L'hôte décide quel contexte demander ou quel tool appeler.
5. Le serveur valide l'identité, les permissions et les entrées avant l'exécution.
6. Le résultat, ou une erreur structurée, revient à l'hôte.

MCP standardise cet échange, pas la prise de décision de l'hôte. Un client peut demander une confirmation avant chaque écriture. Un autre peut s'appuyer sur la policy d'approbation du serveur. Un troisième peut ne pas exposer une primitive donnée.

Transports locaux et distants

L'architecture actuelle du protocole documente deux transports standards :

• stdio, où l'hôte lance un serveur local et échange les messages par l'entrée et la sortie standards ;
• Streamable HTTP, où le client se connecte à un endpoint HTTP distant.

Le choix du transport influence le déploiement et l'authentification. Un serveur stdio local hérite des risques de la machine sur laquelle il s'exécute. Un serveur HTTP distant exige une authentification solide, des contrôles réseau et une gestion rigoureuse des identifiants.

L'ancien transport HTTP+SSE peut encore apparaître dans des intégrations existantes. Pour un nouveau développement, mieux vaut suivre la spécification actuelle et les exigences des clients ciblés.

Pourquoi MCP est utile

Une surface d'intégration partagée

Sans protocole, chaque hôte IA et chaque système métier doivent définir un contrat spécifique. MCP leur donne un vocabulaire commun pour la découverte, les schémas, les appels, les résultats et les erreurs.

Cela peut réduire le travail dupliqué, sans supprimer les tests propres à chaque client : formats d'authentification, transports, primitives prises en charge et expérience d'approbation varient encore.

Un contexte vivant et limité

Un agent est plus utile lorsqu'il peut récupérer l'état actuel d'un projet au lieu de dépendre d'un texte copié dans une conversation. MCP peut exposer ce contexte vivant tout en laissant au système source la responsabilité du contrôle d'accès.

Un bon serveur renvoie le contexte minimal utile. Il n'expose pas un workspace entier lorsqu'une carte, un document ou une requête limitée au projet suffit.

Des actions gouvernées

Les tools MCP peuvent transformer un assistant en participant opérationnel. L'identité et la policy deviennent alors plus importantes, pas moins. Avant qu'une écriture atteigne la source de vérité, le serveur peut vérifier l'accès au projet, les scopes, les règles de l'agent et les approbations requises.

Plus de choix, sans portabilité automatique

MCP peut faciliter la connexion de plusieurs clients compatibles au même serveur. Il peut aussi réduire la dépendance à un format propriétaire d'appel de tools. Mais changer de client n'est pas nécessairement transparent : capacités, configuration, authentification, limites de contexte et comportement de l'interface peuvent différer.

MCP dans le travail projet

Un serveur de gestion de projet peut exposer un ensemble ciblé de capacités :

• lire le contexte des projets, cartes, dépendances, documents et décisions ;
• créer ou modifier du travail dans un périmètre projet défini ;
• faire remonter les blocages, approbations en attente et signaux de delivery ;
• permettre à un agent dédié de récupérer une mission et d'en publier le résultat ;
• connecter des plugins autorisés sans donner au modèle un accès système illimité.

Dans Stellary, le même endpoint MCP peut servir un client humain interactif ou un agent de workspace dédié. Leurs tools et leur comportement d'écriture diffèrent, car le serveur applique l'identité, les permissions, les scopes et la policy d'autonomie. Consultez la référence MCP de Stellary pour l'implémentation actuelle.

Les questions de sécurité à poser

Traitez un serveur MCP comme un logiciel capable de lire des données ou d'effectuer des actions, pas comme une simple bibliothèque de prompts.

Avant de l'activer, vérifiez :

1. Qui exploite le serveur ? Examinez son éditeur, sa source et son mode de déploiement.
2. À quelles données accède-t-il ? Préférez des scopes limités au projet ou à la ressource.
3. Quelles actions peut-il effectuer ? Séparez la lecture, l'écriture et les opérations sensibles.
4. Où l'approbation est-elle appliquée ? Une confirmation côté client aide ; une policy serveur protège tous les clients.
5. Qu'est-ce qui est journalisé ? Conservez l'acteur, le tool, les entrées, le résultat, l'erreur et la décision d'approbation lorsque c'est pertinent.
6. Comment les tokens sont-ils stockés et révoqués ? Utilisez des identifiants distincts pour chaque client ou agent.

Les descriptions et résultats de tools sont des entrées non fiables. Les hôtes et serveurs doivent tenir compte de l'injection de prompt, du contenu malveillant, des permissions excessives et des données provenant de services tiers.

Démarrer avec MCP

En tant qu'utilisateur :

1. vérifiez que le client choisi prend en charge le transport et l'authentification du serveur ;
2. créez un identifiant révocable et limité ;
3. connectez le serveur et inspectez les tools découverts ;
4. testez des appels en lecture seule sur un projet non critique ;
5. ajoutez progressivement les écritures, avec approbation pour les actions à fort impact.

En tant que développeur de serveur, partez de la documentation officielle MCP, implémentez la spécification actuelle avec un SDK officiel lorsque c'est pertinent, puis testez chaque hôte ciblé au lieu de considérer la mention « compatible MCP » comme une matrice de compatibilité complète.

Pour connecter un client IA à Stellary, suivez le guide d'intégration MCP actualisé.