MCP standardise la manière dont une application d’IA se connecte à des capacités externes. Un hôte comme un assistant gère des clients qui communiquent avec des serveurs. Ceux-ci peuvent exposer des outils, des ressources et des prompts sans que chaque intégration invente son propre protocole.
Les rôles
L’hôte contrôle l’expérience utilisateur et les politiques. Le client maintient la connexion à un serveur et négocie les capacités. Le serveur encapsule une source ou un service. Cette séparation permet de réutiliser le même serveur dans plusieurs clients, mais elle n’autorise pas automatiquement toutes ses actions.
Outils, ressources et prompts
Un outil représente une action appelable avec des arguments structurés. Une ressource expose un contenu adressable que le client peut lire. Un prompt fournit un modèle réutilisable proposé par le serveur. Le client décide comment présenter ces capacités au modèle et à l’utilisateur.
Local ou distant
Un serveur local peut être lancé comme processus et accéder à un périmètre de fichiers ou commandes. Un serveur distant utilise un transport réseau et nécessite authentification, autorisation, disponibilité et protection contre les attaques Web. Dans les deux cas, limitez permissions et secrets.
MCP et function calling
MCP distribue et décrit les capacités ; le function calling est souvent le mécanisme par lequel le modèle propose d’utiliser l’un des outils découverts. L’application valide ensuite l’appel. MCP peut encapsuler une API REST existante plutôt que la remplacer.
FAQ
MCP est-il un modèle d’IA ?
Non. C’est un protocole d’intégration.
Un serveur du registre est-il sûr ?
Pas automatiquement. Auditez code, éditeur, permissions et dépendances.
Peut-on connecter une base de données ?
Oui, idéalement avec un compte en lecture limitée et des requêtes ou outils contrôlés.