Comprendre MCP
Le Model Context Protocol organise la manière dont une application d'IA accède à des outils et ressources externes. Il définit des interfaces, mais ne garantit pas qu'un serveur est fiable ou qu'une action est autorisée.
Clients, hôtes et serveurs
Une application hôte décide quels serveurs connecter et ce qu'un agent est autorisé à faire. Les serveurs exposent des capacités telles que des outils ou des ressources. Une description d'outil indique comment l'appeler ; elle ne confère aucun droit d'accès indépendant.
Lire une capacité avant de l'appeler
La découverte des capacités doit être suivie d'une validation du schéma des paramètres et d'une évaluation des effets secondaires. Un appel d'outil peut lire, écrire ou transmettre des données selon sa conception ; la permission doit refléter cette différence.
Évolutions des versions
Le protocole évolue : la version publiée le 28 juillet 2026 comporte notamment des changements de cœur de protocole et d'autorisation. Une intégration doit documenter la version utilisée et tester la compatibilité des clients et serveurs.
Sécurité des connexions
Un serveur peut être mal configuré ou compromis. Appliquer une liste d'origines autorisées, minimiser l'accès aux secrets, inspecter les paramètres et enregistrer les opérations sensibles reste la responsabilité de l'application.
Cycle de vie d’un outil et des autorisations
Lorsqu’un client MCP se connecte à un serveur, les versions et capacités pertinentes doivent être établies selon la spécification applicable. Le client découvre ensuite les outils, ressources ou invites mis à disposition et peut envoyer des appels structurés. Les schémas aident à valider les paramètres mais ne garantissent pas l’innocuité de la fonction. Les accès HTTP demandent une vérification rigoureuse des jetons et de leur audience attendue.
Exercice : documenter une interface de recherche
Créez un descripteur d’outil de consultation documentaire avec un paramètre question et une sortie listant les identifiants de documents. Testez le comportement en cas de paramètre absent, de corpus vide et de tentative d’accès non autorisé. Documentez chaque décision liée aux permissions et mesurez la stabilité des réponses entre deux versions du serveur. Ne présentez pas ce prototype comme une interopérabilité universelle.
Les grandes étapes
- 01Découvrir le serveur
- 02Lire les capacités
- 03Approuver et appeler
- 04Auditer les effets
Trois questions à poser
La version de la spécification et du SDK est-elle documentée ?
Les paramètres et résultats des outils sont-ils traités comme non fiables ?
L'accès sensible est-il soumis à une confirmation ?
Consulter les textes originaux
Les versions, conditions de réutilisation et statuts des documents peuvent évoluer. Vérifiez-les sur les sites d’origine.