Model Context Protocol (MCP)

À quoi sert MCP

Avant qu'un protocole commun existe, chaque appariement d'un assistant et d'un outil était une intégration à part, écrite deux fois et maintenue pour toujours : cinq assistants et vingt outils, cela faisait cent connexions sur mesure. MCP transforme cela en addition plutôt qu'en multiplication. L'auteur d'un outil écrit un serveur, l'auteur d'une application écrit un client, et tout ce qui se trouve d'un côté peut parler à tout ce qui se trouve de l'autre. Anthropic l'a publié comme standard ouvert fin 2024 et il a été adopté bien au-delà depuis. L'esprit tient davantage d'une interface de pilote de périphérique que d'une API produit : la valeur n'est pas dans ce qu'il permet, mais dans le fait que tout le monde s'est accordé sur la forme.

Le montage est client-serveur. L'application qui héberge le modèle est le client ; chaque capacité que vous voulez exposer tourne comme un serveur qui décrit ce qu'il propose de façon lisible par une machine, pour que le modèle voie les options et choisisse. Il est indépendant du transport — un serveur peut être un processus local sur la même machine ou quelque chose joignable en HTTP —, ce qui explique que la même intégration fonctionne dans un assistant de bureau, dans un agent IA tournant sur un serveur et dans un outil de développement sans être réécrite à chaque fois.

Ce qu'expose un serveur

Un serveur propose trois types de choses, et la distinction compte quand on en construit un :

• Outils — des actions que le modèle peut déclencher : envoyer un message, interroger une table, créer un enregistrement. Ce sont celles qui ont des conséquences et celles avec lesquelles il faut être prudent.
• Ressources — des données que le client peut tirer dans le contexte : un fichier, un document, une ligne, le contenu d'une page. De la matière en lecture seule donnée au modèle, pas quelque chose qu'il fait.
• Prompts — des instructions réutilisables et paramétrées qu'une personne choisit délibérément, plutôt que quelque chose que le modèle saisit de lui-même.

Ce que le protocole ne règle pas

Un standard de connexion supprime la plomberie et laisse intact tout ce qui est difficile. La première chose qui apparaît en pratique, c'est qu'avoir des outils n'est pas gratuit. Chaque capacité qu'un modèle peut appeler doit lui être décrite, et ces descriptions occupent le même contexte limité que le travail lui-même : un grand catalogue entre donc silencieusement en concurrence avec la tâche. Nous avons buté exactement là-dessus en construisant des agents pour nos clients chez AgentCeres — le Directeur de la croissance IA sur agentceres.com : au-delà d'un certain nombre de capacités disponibles, le catalogue doit être résumé pour tenir, ce qui signifie que chaque intégration supplémentaire coûte quelque chose même si personne ne s'en sert. La discipline d'ingénierie revient finalement à décider ce qu'un agent ne devrait *pas* pouvoir atteindre.

La seconde lacune est l'autorité. Le protocole décrit comment appeler un outil ; il ne dit rien sur le fait de savoir si cet agent, agissant pour ce client, maintenant, devrait en avoir le droit. Un outil qui lit un tableur et un outil qui publie sur le compte social d'une entreprise sont identiques pour le protocole et totalement différents pour l'activité. Cette frontière appartient à votre propre produit, et c'est pourquoi, chez nous, tout ce qui a une conséquence publique attend derrière une porte d'approbation tenue par une personne, quelle que soit la façon dont la capacité a été branchée.