Le Model Context Protocol, ou MCP, est un protocole ouvert qui permet à une application IA de se connecter à des serveurs exposant outils, ressources et prompts réutilisables par une interface client-serveur standardisée.
Une équipe peut confondre protocole de connexion commun, plateforme d’agents complète et frontière de sécurité. MCP standardise la découverte et l’appel, mais identité, autorisation, sûreté des outils, politique métier, vérification, observabilité et récupération restent à la charge de l’application.
MCP est surtout utile comme contrat d’intégration. Il réduit les connecteurs spécifiques et permet aux clients et serveurs d’évoluer séparément. La qualité de production dépend toujours des contrats étroits, droits et contrôles opératoires autour de chaque capacité.
Architecture
MCP standardise la connexion, pas toute l’application
Un hôte MCP est l’application IA dans laquelle travaille l’utilisateur. Il crée des clients qui se connectent aux serveurs. Un serveur annonce des capacités telles que outils, ressources et prompts. La négociation permet aux participants de convenir d’une version et de fonctions prises en charge avant leur usage.
La distinction des fonctions compte. Les ressources fournissent du contexte à lire, les outils permettent au modèle de demander une opération et les prompts fournissent des modèles réutilisables. L’hôte décide comment les présenter au modèle et à la personne. Processus métier, mémoire et autorité finale peuvent rester hors du protocole.
| Composant | Mission principale | Question de contrôle |
|---|---|---|
| Hôte | Exécute l’expérience IA et coordonne les clients | Quel utilisateur et quelle politique gouvernent? |
| Client | Maintient une connexion vers un serveur | Quelles capacités sont acceptées et exposées? |
| Serveur | Adapte données ou actions comme capacités | Quel système et quelle autorité se trouvent derrière? |
| Ressource | Fournit un contexte à lire | Comment le contenu sensible est-il limité? |
| Outil | Offre une opération que le modèle peut demander | Qui valide et approuve son effet? |
Production
L’entreprise a besoin de contrôles au-dessus et sous MCP
Au-dessus du protocole, l’hôte a besoin de consentement, politique, approbation, évaluation et affichage clair des actions. En dessous, serveur et système cible ont besoin d’authentification, autorisation limitée, validation, transactions sûres, journalisation et réconciliation. Un message bien formé n’est pas automatiquement une instruction métier autorisée.
Traitez les serveurs tiers comme des dépendances logicielles avec accès. Examinez éditeur, code ou contrôles du service, traitement des données, mises à jour et réponse aux incidents. Maintenez l’inventaire des serveurs et capacités. La portabilité de l’intégration rend l’ajout et le retrait contrôlés encore plus importants.
- Lier les jetons à leur audience et ne jamais les transférer sans contrôle.
- N’exposer que les capacités minimales nécessaires à la personne et au processus.
- Confirmer les appels importants avant leur exécution.
- Nettoyer les journaux tout en gardant audit et récupération possibles.
- Réévaluer lorsque outils, schémas, serveurs ou modèles changent.
Ce qui caractérise un bon résultat
Résultats concrets pour Model Context Protocol explication
- L’ingénierie relie des clients IA compatibles à des capacités métier par une surface de protocole commune.
- Les outils, ressources de lecture et modèles de prompts restent distincts dans l’architecture.
- L’organisation évalue un serveur selon son autorité, son chemin de données et son implémentation, pas seulement son étiquette MCP.
- La négociation de version et la découverte des capacités deviennent des sujets explicites.
- Les processus agentiques gardent validation, audit et récupération autour des actions importantes.
Modèle opératoire
Comment exécuter le travail
- 01
Définir la capacité métier
Commencez par l’information ou l’action exacte dont l’application a besoin. Décrivez utilisateur, système de référence, périmètre permis et résultat observable. Décidez si la capacité doit être une ressource à lire, un outil à appeler ou un prompt réutilisable.
- 02
Choisir les frontières client et serveur
Identifiez quel hôte contrôle conversation et permissions, quel client maintient la connexion et quel serveur adapte le système sous-jacent. Gardez visibles frontières de confiance et responsabilité de déploiement au lieu de traiter tout serveur comme plugin interchangeable.
- 03
Limiter et valider l’interface
Employez opérations étroites, arguments typés, droits minimaux et états d’erreur explicites. Validez les entrées générées contre les règles métier. Séparez lecture et mutation puis exigez une approbation avant un effet coûteux, externe ou difficile à inverser.
- 04
Tester protocole et comportement métier
Testez découverte, compatibilité de version, autorisation, requêtes mal formées, délais et échecs partiels. Évaluez ensuite si l’agent choisit la bonne capacité, fournit les bons arguments et vérifie le résultat dans des cas réalistes et hostiles.
Évaluation
Les questions qui changent la décision
- La capacité doit-elle être un outil, une ressource ou une étape contrôlée par l’application?
- Où identité et autorisation sont-elles imposées pour chaque serveur et système en aval?
- Une écriture peut-elle être idempotente et réconciliée après une réponse ambiguë?
- Quelles métadonnées et descriptions de serveur sont considérées comme instructions par l’application?
- Qui revoit mises à jour, versions du protocole et nouvelles capacités exposées?
Modes d’échec
Où les équipes perdent le contrôle
Un outil décrit trop largement donne au modèle plus d’autorité que la tâche de l’utilisateur.
Une ressource ou sortie non fiable peut contenir des instructions qui cherchent à détourner le modèle.
Le transfert de jetons ou une faible validation d’audience peut exposer des droits au mauvais serveur.
Un serveur compatible peut toujours avoir des écritures dangereuses, une faible isolation ou un audit insuffisant.
Le succès du protocole peut être confondu avec celui du métier sans réconciliation de l’effet final.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- découverte et négociation de version réussies par client pris en charge
- appels refusés pour arguments, permissions ou politique métier
- succès de l’action après réconciliation avec le système de référence
- effets doublés évités après reprise ou délai
- cas de sécurité et régression réussis par version de serveur
Questions
Questions fréquentes
MCP est-il une API?
MCP est un protocole qui permet aux applications IA et serveurs de découvrir et échanger outils, ressources, prompts et messages. Un serveur peut adapter des API, bases ou fonctions locales existantes. MCP ne remplace pas toutes les API métier sous-jacentes.
Qu’est-ce qu’un serveur MCP?
C’est un programme ou service distant qui expose des capacités par MCP. Une capacité peut lire des données, fournir une ressource ou accomplir une action. Sa sûreté dépend de l’implémentation, des identifiants et des systèmes cibles autant que du protocole.
MCP sécurise-t-il les agents IA?
Non. MCP définit une connexion interopérable et comprend des mécanismes d’autorisation pour certains transports. L’hôte, le serveur et l’organisation doivent encore imposer identité, moindre privilège, approbation, validation, isolation, audit et récupération.
Sources
Sources primaires
- Présentation de l’architecture MCP Model Context Protocol
- Bonnes pratiques de sécurité MCP Model Context Protocol
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→