Model Context Protocol (MCP)
MCP permet à une application d’IA de découvrir et d’utiliser les informations et les outils fournis par un autre programme, par exemple un service de recherche dans les issues d’un dépôt. L’application d’IA est l’hôte : elle passe par un client MCP pour se connecter au serveur MCP qui fournit ces capacités. Le protocole versionné définit les échanges de messages, la découverte des capacités et l’initialisation de la connexion. Il ne définit pas le sens des opérations métier, ne garantit pas la fiabilité du serveur et ne décide pas des actions autorisées au modèle.
Architecture
L’hôte gère l’interaction avec l’utilisateur, le contexte du modèle, l’approbation et l’orchestration des clients. Un client maintient une connexion avec un serveur. Le serveur expose une surface de capacités ciblée et peut lui-même dépendre d’un autre système.
Cycle de vie et négociation des capacités
Une connexion commence par l’initialisation : client et serveur échangent les versions du protocole, les informations d’implémentation et les capacités déclarées. Le fonctionnement normal ne commence qu’une fois l’initialisation terminée. La négociation des capacités est importante, car les fonctionnalités optionnelles et les révisions diffèrent ; « prend en charge MCP » n’est pas un test de compatibilité suffisant.
Les transports courants sont stdio en local et Streamable HTTP. Local ne signifie pas inoffensif : un processus serveur lancé hérite de toutes les autorisations de système de fichiers, d’environnement et de réseau que lui accorde le lanceur. Le transport distant ajoute des préoccupations d’origine, d’authentification, de jetons et de défaillances réseau.
Primitives serveur
Le protocole inclut aussi des notifications et des familles de capacités facultatives. Un produit peut n’en prendre en charge qu’un sous-ensemble.
Exemple de frontière : recherche d’issues en lecture seule
Un serveur ciblé pourrait exposer search_issues(query, repository, limit) et renvoyer des identifiants d’issues, titres, URL et extraits. Un hôte sûr doit néanmoins :
- restreindre les dépôts autorisés et le nombre maximal de résultats ;
- traiter le texte des issues comme des données non fiables ;
- garder les outils d’écriture désactivés pour une tâche de recherche ;
- afficher la provenance et éviter de placer d’énormes résultats en contexte ;
- imposer un parcours d’approbation distinct avant de commenter ou de fermer une issue.
MCP rend l’appel découvrable ; ces contrôles restent de la responsabilité de l’application.
Modes de défaillance de sécurité et contrôles de l’hôte
- Confused Deputy : le modèle ou le serveur exploite les larges autorisations de l’hôte pour exécuter des effets de bord non approuvés.
- Injection indirecte de prompt : des contenus Web ou fichiers non fiables renvoyés par des appels d’outils contiennent des instructions visant à déclencher des actions destructrices secondaires.
- Transmission et fuite de jetons : des identifiants franchissent les frontières de transport sans restriction d’audience ni masquage dans les journaux.
- Extension de périmètre : un méga-serveur pratique expose des outils d’écriture/suppression trop étendus.
Un hôte peut réduire ces risques en traitant la sortie du serveur comme des données non fiables, en validant à nouveau les arguments d’outils proposés avant exécution, en n’accordant à chaque serveur que les identifiants et chemins nécessaires, et en exigeant une approbation pour les effets de bord définis par la politique locale.
Pour les serveurs stdio locaux, l’isolation des processus et un environnement restreint peuvent limiter les dégâts si le serveur est compromis. Pour les serveurs Streamable HTTP distants, une liaison loopback n’est pas un contrôle côté client : utilisez HTTPS, validez l’identité et l’origine du serveur, limitez les jetons d’autorisation à l’audience prévue et suivez les recommandations d’autorisation du protocole. Un serveur exploité localement sur HTTP peut se lier à loopback, mais il s’agit d’un autre cas de déploiement.
Un ordre stable des schémas peut améliorer la réutilisation du cache de prompts dans certains hôtes, mais c’est un choix de performance, non une propriété de sécurité de MCP.
MCP face à des alternatives plus simples
MCP est un mécanisme d’interopérabilité, pas une architecture dont tout système agentique a besoin. Évaluez son adoption au regard de la complexité du cycle de vie, de la latence d’exécution, de la sécurité du transport et des coûts de maintenance.