Model Context Protocol

Vous voulez connecter un agent à des fichiers, un outil métier et une API. Sans contrat commun, chaque connexion possède son propre format, sa méthode de découverte et sa gestion des erreurs. MCP fournit un langage partagé pour exposer ces capacités à une application IA.

Le Model Context Protocol, ou MCP, organise la communication entre trois rôles. L’hôte est l’application qui coordonne l’expérience et les décisions de sécurité. Il crée un client pour chaque connexion. Le client échange avec un serveur MCP qui expose des capacités spécialisées. Un serveur peut être exécuté localement ou accessible à distance. [S1]

Le protocole repose sur JSON-RPC et prévoit la négociation des capacités prises en charge. Un serveur peut notamment exposer des ressources, des outils et des prompts. Le client et le serveur annoncent ce qu’ils savent traiter afin d’éviter de supposer qu’une fonction existe. [S1]

Quand MCP apporte une valeur réelle

MCP devient utile lorsque plusieurs applications ou serveurs doivent partager le même contrat de connexion.

Situation	Choix de départ
Une seule application appelle une API stable et bien documentée	Intégration directe
Plusieurs outils doivent être découverts et appelés avec un format commun	MCP peut réduire les adaptateurs spécifiques
Des documents ou données doivent être exposés à plusieurs clients IA	MCP peut fournir une interface commune
Le besoin principal est l’authentification, la gouvernance ou l’approbation	MCP seul ne répond pas au besoin
Le serveur ou son code n’est pas digne de confiance	Ne pas le connecter avant analyse et isolation

Un protocole commun améliore l’interopérabilité. Il ne rend pas automatiquement une intégration plus simple si un seul appel direct suffit. Il ajoute aussi un serveur, une négociation de capacités et un cycle de version à maintenir.

Ce que le protocole standardise

MCP décrit notamment :

• les rôles d’hôte, de client et de serveur ;
• les messages échangés et leurs erreurs ;
• la découverte des capacités prises en charge ;
• la liste et l’appel d’outils avec des schémas d’entrée ;
• l’exposition de ressources et de modèles de prompts ;
• les notifications et abonnements prévus par les capacités annoncées. [S1] [S2]

Pour un outil, le serveur fournit un nom, une description et un schéma des paramètres. Le modèle peut alors choisir de l’appeler. Le protocole ne prescrit toutefois pas l’interface qui présente cet appel, ni le niveau de confirmation attendu. [S2]

Une capacité annoncée signifie qu’une fonction du protocole est disponible. Elle ne prouve ni que le serveur est digne de confiance, ni que l’utilisateur est autorisé à réaliser l’action, ni que le résultat de l’outil est exact.

Ce que MCP ne sécurise pas à lui seul

L’hôte reste responsable des limites appliquées à chaque connexion. Il doit contrôler les permissions, le cycle de vie des clients, les politiques de sécurité, le consentement et l’agrégation du contexte. Chaque client ne communique qu’avec un serveur afin de préserver les frontières entre connexions. [S1]

Avant d’autoriser un serveur, vérifiez :

1. Son origine. Qui publie et maintient le serveur ? Son code ou son binaire peut-il être inspecté ?
2. Ses accès réels. Quels fichiers, réseaux, comptes, outils et secrets peut-il atteindre avec les privilèges du processus ?
3. Les capacités exposées. Les outils visibles sont-ils nécessaires, différenciés et décrits sans ambiguïté ?
4. L’autorisation. Les jetons sont-ils destinés au bon serveur, limités aux opérations utiles et validés côté serveur ? [S3]
5. Le consentement. Une action sensible est-elle visible et confirmée avant son effet ? [S2]
6. L’isolation. Un serveur local est-il exécuté avec le minimum d’accès au système, au réseau et aux données ? [S4]
7. La traçabilité. Les appels, refus, erreurs et changements de capacités peuvent-ils être examinés sans journaliser de secrets ?

La spécification interdit notamment de transmettre au service en amont le jeton reçu par le serveur MCP. Le serveur doit utiliser un jeton distinct, destiné à cette ressource, et valider que chaque jeton entrant lui est bien adressé. [S3]

Un serveur local peut exécuter du code avec les privilèges du client. Une installation en un clic doit donc montrer la commande complète, demander un consentement explicite et proposer une isolation avec des accès minimaux. [S4]

Concevoir une connexion MCP

1. Partir du besoin. Listez les décisions que l’agent doit soutenir et les données ou actions strictement nécessaires.
2. Comparer à une intégration directe. Gardez l’API existante si MCP n’apporte ni réutilisation, ni découverte, ni portabilité utile.
3. Séparer lecture et action. Des serveurs ou outils distincts permettent d’accorder des permissions différentes.
4. Limiter les schémas. Chaque outil accepte seulement les paramètres attendus et retourne un résultat exploitable. [S2]
5. Appliquer les autorisations hors du modèle. Le code valide l’identité, la portée, la ressource cible et les règles métier avant l’effet. [S3]
6. Afficher l’action réelle. L’interface montre le serveur, l’outil, les paramètres importants et la conséquence avant une opération sensible. [S2]
7. Tester les échecs. Couvrez un serveur indisponible, un outil retiré, un schéma invalide, un refus d’autorisation et une réponse incohérente ou trompeuse.
8. Revoir après évolution. Une nouvelle version du protocole, du serveur ou des capacités rend la vérification précédente partiellement obsolète.

Limites à garder visibles

• Un schéma d’outil contrôle la forme des paramètres, pas la justesse de la décision.
• Un serveur peut fournir un contenu trompeur ou une description d’outil malveillante.
• Une authentification réussie ne donne pas automatiquement l’autorisation métier.
• Une connexion locale peut avoir autant de pouvoir que le processus qui la lance.
• Plusieurs serveurs augmentent le nombre de dépendances, de permissions et de résultats à surveiller.
• Une compatibilité déclarée avec MCP ne garantit pas la prise en charge de toutes les capacités ou versions.

Choisissez MCP lorsque son contrat commun réduit réellement le coût de plusieurs intégrations. Gardez l’hôte responsable de la confiance, des permissions, de l’approbation et de la vérification des effets. Le protocole relie les composants. Il ne décide pas à leur place ce qui est sûr.