Le Model Context Protocol (MCP) expliqué aux développeurs

Les grands modèles de langage sont brillants pour raisonner sur du texte, mais isolés du monde réel. Un LLM seul ne connaît pas votre base de données, ne lit pas vos fichiers et ne sait pas passer un appel à votre API interne. Le Model Context Protocol (MCP) répond exactement à ce problème : c’est un standard ouvert qui permet de brancher un modèle sur des outils et des sources de données, de façon uniforme. Voici comment il fonctionne et pourquoi il compte pour les développeurs.

Le problème que le MCP résout

Avant un standard commun, connecter un LLM à un outil externe — un dépôt Git, une base PostgreSQL, une API météo — imposait d’écrire une intégration sur mesure à chaque fois. Chaque application IA réinventait sa propre plomberie, incompatible avec les autres. Résultat : du code dupliqué, des intégrations fragiles et aucune réutilisation.

Le MCP, introduit par Anthropic puis adopté plus largement, applique au monde des LLM une idée éprouvée ailleurs : un protocole unique pour que n’importe quel modèle parle à n’importe quel outil. On le compare souvent au rôle qu’a joué le Language Server Protocol (LSP) pour les éditeurs de code : écrire un serveur une fois, l’utiliser partout.

Architecture : client, serveur, hôte

Le MCP repose sur une architecture claire à trois rôles.

L’hôte : l’application qui embarque le modèle (un assistant de code, un chatbot, un agent). C’est elle qui orchestre la conversation avec l’utilisateur.
Le client MCP : le composant, à l’intérieur de l’hôte, qui parle le protocole. Il maintient une connexion avec un serveur MCP.
Le serveur MCP : un programme qui expose des capacités — des outils à appeler, des ressources à lire, des prompts réutilisables. Chaque serveur encapsule une intégration : un serveur « fichiers », un serveur « GitHub », un serveur « base de données »…

La communication passe par des messages structurés (au format JSON-RPC). Un serveur peut être lancé localement et communiquer via l’entrée/sortie standard, ou être exposé à distance. L’important : tant qu’un outil respecte le protocole, tout hôte compatible MCP peut l’utiliser sans code spécifique.

Ce qu’un serveur MCP expose

Un serveur MCP peut offrir trois grandes catégories de capacités :

Les outils (tools) — des fonctions que le modèle peut décider d’appeler : « lire un fichier », « exécuter une requête SQL », « créer une issue ». Chacun est décrit par un schéma d’entrée que le modèle comprend.
Les ressources (resources) — des données que l’hôte peut charger dans le contexte : le contenu d’un fichier, un enregistrement, une page de documentation.
Les prompts — des modèles de requêtes réutilisables, paramétrables, que l’utilisateur peut invoquer.

Cette séparation est ce qui rend le MCP puissant : le modèle raisonne, le serveur agit, et le protocole garantit qu’ils se comprennent.

Un exemple conceptuel

Imaginons un serveur MCP minimal qui expose un seul outil : récupérer la météo d’une ville. Côté déclaration, l’outil se décrit par un nom, une description et un schéma de paramètres :

{
  "name": "get_weather",
  "description": "Renvoie la météo actuelle d'une ville",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "Nom de la ville" }
    },
    "required": ["city"]
  }
}

Côté implémentation, le serveur définit ce que fait réellement l’outil quand il est appelé :

# Pseudo-code illustratif d'un serveur MCP
@server.tool("get_weather")
def get_weather(city: str) -> dict:
    data = weather_api.fetch(city)
    return {
        "city": city,
        "temperature": data.temp_c,
        "condition": data.condition,
    }

Le déroulé est alors le suivant : l’utilisateur demande « Quel temps fait-il à Lyon ? ». Le modèle, voyant l’outil get_weather disponible, décide de l’appeler avec {"city": "Lyon"}. Le client MCP transmet la requête au serveur, qui exécute la fonction et renvoie un résultat structuré. Le modèle reçoit ces données et formule une réponse en langage naturel. À aucun moment le modèle n’a « inventé » la météo : il a utilisé un outil réel.

Cas d’usage pour les développeurs

Le MCP ouvre des scénarios concrets dès qu’un LLM doit sortir de sa bulle textuelle :

Assistants de code connectés au dépôt, aux tests et à la documentation interne.
Agents de données capables d’interroger une base ou un data warehouse en langage naturel.
Automatisations métier reliant l’IA à un CRM, un outil de tickets ou un système de fichiers.
Intégrations d’entreprise où un même serveur MCP est réutilisé par plusieurs applications IA.

L’intérêt stratégique est la réutilisabilité : une entreprise qui écrit un bon serveur MCP pour son système interne le rend exploitable par tous ses outils IA, présents et futurs. Cette logique de briques interopérables est aussi le socle des agents autonomes : un agent devient utile précisément parce qu’il dispose d’outils fiables à actionner.

Un standard qui structure l’écosystème

Le MCP n’est pas une technologie propriétaire enfermée dans un produit : c’est une spécification ouverte, avec des implémentations de référence et un nombre croissant de serveurs communautaires. Pour un développeur, apprendre le MCP aujourd’hui, c’est investir dans la couche d’interconnexion qui reliera durablement les modèles au reste du système d’information — plutôt que de recoder, encore, une énième intégration jetable.