Un serveur MCP est un processus léger qui expose des capacités, telles que l'accès aux fichiers, les requêtes en base de données ou les appels d'API, à un modèle de langage via le Model Context Protocol. Il permet à un modèle de demander et d'utiliser des ressources externes de manière structurée et cohérente, sans nécessiter de code d'intégration personnalisé pour chaque outil.
Contexte
Les modèles de langage n'ont pas d'accès persistant aux systèmes extérieurs à leur appel d'inférence. Si un modèle doit lire un fichier, interroger une base de données ou appeler une API, l'application doit gérer cette plomberie. Avant qu'un standard n'existe, chaque équipe résolvait ce problème différemment : schémas de fonctions personnalisés, formats JSON sur mesure, code de liaison fait maison.
Anthropic a publié le Model Context Protocol (MCP) fin 2024 pour standardiser la communication entre les modèles et les outils. Il définit une architecture client-serveur. L'application côté modèle est le client ; chaque capacité externe est encapsulée dans un serveur.
Ce que fait concrètement un serveur MCP
Un serveur MCP déclare trois types d'éléments :
- Des outils. Des fonctions que le modèle peut appeler, telles qu'exécuter une commande shell, rechercher dans un code source ou soumettre un formulaire.
- Des ressources. Des sources de données lisibles, telles que des fichiers, des lignes de base de données ou des réponses d'API, servies à la demande.
- Des prompts. Des modèles de prompt réutilisables que le serveur expose afin que le client puisse les invoquer par leur nom.
Le serveur s'exécute en tant que processus séparé. Il communique avec le client via une couche de transport, généralement l'entrée/sortie standard pour les serveurs locaux, ou HTTP avec server-sent events pour les serveurs distants. Le client découvre ce que le serveur propose en interrogeant son manifeste au démarrage.
Pourquoi un protocole standard est utile
Sans protocole partagé, connecter un modèle à dix outils différents signifie écrire dix couches d'intégration distinctes, et les maintenir à mesure que les interfaces des outils évoluent. MCP rend les connexions aux outils composables. Un client qui parle MCP peut se connecter à n'importe quel serveur conforme sans code spécifique.
C'est important pour le codage agentique et les workflows agentiques plus larges, où un modèle peut avoir besoin d'appeler de nombreux outils en séquence, en transmettant les résultats de l'un à l'autre. Un protocole standard réduit la surface sur laquelle les choses peuvent dysfonctionner.
Il rend également les périmètres de capacités explicites. Le serveur déclare exactement ce qu'il expose. Le modèle ne peut pas aller au-delà de cette déclaration, ce qui est pertinent pour la sécurité : un serveur mal configuré ou malveillant constitue une surface d'attaque définie plutôt qu'un socket ouvert.
Comment les serveurs MCP s'intègrent dans les systèmes en production
En pratique, une équipe d'ingénierie peut faire tourner plusieurs serveurs MCP aux côtés de son application :
- Un exposant leur documentation interne en tant que ressource
- Un encapsulant leur base de données avec des outils de requête en lecture seule
- Un donnant accès à un environnement d'exécution de code isolé
L'agent IA ou l'outil de codage se connecte à chacun au démarrage et utilise les capacités requises par la tâche. Le client, souvent une passerelle IA ou une couche d'orchestration, gère le routage.
MCP est relativement récent. Son adoption progresse dans les outils pour développeurs et les agents de codage, mais la maturité des déploiements en production varie considérablement. Les équipes qui s'appuient dessus doivent s'attendre à ce que la spécification évolue.
Risques à connaître
Les serveurs MCP étendent les capacités d'un modèle, ce qui accroît les conséquences des erreurs. Un outil qui écrit en base de données ou exécute du code peut causer des dommages réels si le modèle en fait un mauvais usage. La prompt injection est un risque particulier : une entrée malveillante pourrait demander au modèle d'appeler un outil destructeur.
Les bonnes pratiques appliquent aux permissions des outils MCP les mêmes principes qu'aux permissions d'API : moindre privilège, périmètres explicites, journalisation des appels effectués.
Ce que nous évaluons
Les ingénieurs qui travaillent avec des systèmes agentiques doivent comprendre comment les outils sont exposés aux modèles et où se situent les points de défaillance. Notre sélection couvre cela directement : dans l'évaluation AI-native, les candidats sont notés sur l'orchestration d'outils et la vérification des sorties IA, deux critères qui révèlent rapidement si quelqu'un est en train de concevoir ou de déboguer un workflow reposant sur MCP. Le développement piloté par les spécifications est également important ici, car des définitions d'outils insuffisantes produisent les mêmes résultats médiocres que la frontière soit un appel de fonction ou une interface MCP. Tous les détails sur how we vet.
Réponses courtes
MCP est-il spécifique à Claude ou aux modèles Anthropic ?
Non. Anthropic a publié la spécification, mais MCP est un protocole ouvert. N'importe quel client de modèle peut l'implémenter, et plusieurs outils de codage et frameworks en dehors de l'écosystème Anthropic ont ajouté la prise en charge de MCP.
Quelle est la différence entre un serveur MCP et un schéma de function-calling ?
Les schémas de function-calling sont définis par modèle et par intégration. MCP est un standard au niveau transport : tout client conforme se connecte à tout serveur conforme sans code personnalisé. Il encapsule le concept d'outils appelables dans un protocole cohérent.
Un serveur MCP peut-il exposer un accès en lecture-écriture à une base de données ?
Oui, mais cela doit être traité avec soin. Le serveur peut exposer des outils d'écriture, mais l'accès doit suivre les principes du moindre privilège. Il est conseillé de journaliser chaque appel d'outil effectué par le modèle avant d'accorder toute capacité destructrice.
