MCP, expliqué simplement : donner des mains à un modèle de langage

Un modèle de langage, aussi brillant soit-il, ne sait rien faire seul : il génère du texte. Il ne lit pas vos courriels, ne cherche pas sur le web, n'exécute aucune action. Le Model Context Protocol (MCP) est ce qui lui donne des mains — une façon standard de brancher un cerveau sur le monde réel.

Le problème : mille intégrations sur-mesure

Imaginez que vous vouliez donner à votre assistant IA l'accès à Gmail, à votre agenda, à une base de données interne et à un moteur de recherche. Avant MCP, chaque connexion était un projet en soi : une intégration bricolée à la main, avec sa propre logique d'authentification, son format de données, ses conventions. Changez de modèle ou d'outil, et vous recommenciez presque tout.

C'est le classique problème du « N fois M » : N applications d'IA qui doivent se connecter à M sources de données, soit N × M intégrations à écrire et à maintenir. Multiplié par le nombre d'équipes qui réinventent la même roue dans leur coin, cela devient ingérable.

MCP, proposé par Anthropic fin 2024 comme protocole ouvert, règle ce nœud de la même manière que l'USB-C a réglé celui des câbles. Au lieu d'un branchement propriétaire par appareil, on définit une prise unique. Un outil parle MCP une fois, et il devient utilisable par n'importe quel agent qui parle MCP. On passe de N × M à N + M.

Client et serveur : qui parle à qui

MCP repose sur une distinction simple mais fondamentale, empruntée à l'architecture classique du web.

• Le serveur MCP expose des capacités. C'est lui qui « sait faire » quelque chose : lire une boîte Gmail, interroger une base, chercher sur le web. Il publie ce qu'il propose de manière standardisée.
• Le client MCP consomme ces capacités. Il est intégré dans l'application qui héberge le modèle (l'agent) et se connecte à un ou plusieurs serveurs pour leur demander des choses.

Concrètement, un serveur MCP peut exposer trois types de choses :

• Des outils (tools) : des actions que le modèle peut décider d'appeler, comme envoyer_email ou rechercher_web. C'est l'équivalent des verbes.
• Des ressources (resources) : des données que l'agent peut lire, comme un fichier, un enregistrement, une page. Les noms.
• Des invites (prompts) : des modèles de requête réutilisables, préparés côté serveur pour guider une tâche.

La communication passe par un transport — typiquement l'entrée/sortie standard (stdio) pour un serveur local, ou HTTP en flux pour un serveur distant — et s'appuie sur des messages JSON-RPC. Le client demande d'abord « que sais-tu faire ? », le serveur répond avec sa liste d'outils et leurs descriptions, et le modèle choisit lesquels appeler.

Agent (hôte)
  └─ Client MCP ──[transport: stdio / HTTP]──► Serveur MCP Gmail
                                               ├─ outil: rechercher_messages
                                               ├─ outil: creer_brouillon
                                               └─ ressource: fil_de_discussion

Un exemple concret : brancher Gmail

Prenons le connecteur Gmail. Le serveur MCP correspondant expose un outil rechercher_messages et un outil creer_brouillon. Côté agent, je n'écris aucun code spécifique à Gmail : mon client MCP découvre ces outils automatiquement et les présente au modèle avec leur description.

Quand je demande « résume-moi les courriels non lus de cette semaine », le modèle comprend qu'il doit appeler rechercher_messages, formule les bons paramètres, reçoit les résultats via le serveur, puis les résume. Le même agent, sans une ligne de plus, peut ensuite se brancher à un serveur d'accès web pour vérifier un lien, ou à un serveur d'agenda pour proposer un créneau. Chaque nouvelle capacité est un serveur de plus, pas un chantier de plus.

Le gain n'est pas seulement technique : c'est un découplage. L'auteur de l'outil et l'auteur de l'agent n'ont plus besoin de se connaître ni de se coordonner. Le protocole est leur langage commun.

Pourquoi je construis Klody Code AI à la fois client et serveur

C'est là que MCP devient réellement intéressant à mes yeux, dans mon travail sur les agents privés et local-first. Un agent n'est pas condamné à un seul rôle.

Klody Code AI est un client MCP : il se connecte aux serveurs qui l'entourent pour lire des fichiers, chercher sur le web, piloter des outils locaux via Ollama ou MLX, sans que rien ne quitte ma machine. Mais il est aussi un serveur MCP : il expose ses propres capacités — analyser un dépôt de code, exécuter une tâche d'ingénierie — pour qu'un autre agent puisse les utiliser à son tour.

Autrement dit, mon agent peut être l'outil d'un autre agent. Cette symétrie change la nature de ce qu'on construit : on ne fabrique plus des assistants isolés, mais des briques qui se composent. Un agent orchestrateur délègue à un agent spécialisé, qui délègue lui-même à un serveur de données, et tout ce beau monde parle le même protocole.

Ce que ça préfigure

On parle beaucoup d'agents « autonomes ». Mais l'autonomie sans capacité d'action reste une conversation. MCP est la couche discrète qui transforme un générateur de texte en acteur : il standardise le geste par lequel un modèle attrape quelque chose dans le monde.

Et parce que le protocole est ouvert, personne n'en détient les clés. C'est ce qui permet à un écosystème d'exister plutôt qu'un jardin clos par éditeur. Le jour où chaque outil expose une prise MCP et où chaque agent sait s'y brancher, la question n'est plus « à quoi ce modèle a-t-il accès ? », mais « à quoi ne l'ai-je pas encore connecté ? ».