Le Model Context Protocol (MCP) est un standard ouvert qui définit comment les applications d’IA se connectent à des outils et à des sources de données externes. Anthropic l’a présenté en novembre 2024, et il a depuis été adopté par des assistants d’IA, des outils de programmation et des frameworks d’agents.
Le problème que résout MCP
Un modèle de langage seul ne peut produire que du texte. Pour être utile dans un vrai travail, il doit lire des fichiers, interroger des bases de données, chercher et appeler des API. Avant MCP, chaque application d’IA définissait sa propre façon de brancher tout cela ; un outil conçu pour un assistant devait donc être refait pour le suivant.
MCP remplace cela par un seul protocole. Un fournisseur d’outils écrit un serveur MCP une fois, et toute application compatible MCP peut l’utiliser. La comparaison courante est celle d’un connecteur universel : une prise standard au lieu d’un câble différent pour chaque appareil.
Comment fonctionne MCP
MCP comporte trois rôles.
- Hôte : l’application d’IA que la personne utilise, comme une application de chat, un IDE ou un agent.
- Client : un composant à l’intérieur de l’hôte qui maintient la connexion avec un serveur.
- Serveur : un programme qui expose des capacités à l’hôte.
Host application (assistant, IDE, agent)
| one MCP client per server
v
MCP server ---> files, databases, APIs, or pure computation
Les messages sont du JSON-RPC 2.0. À l’ouverture d’une connexion, le client et le serveur échangent leurs capacités, et le client demande au serveur ce qu’il propose. L’hôte transmet ces définitions d’outils au modèle. Quand le modèle décide d’utiliser un outil, le client envoie l’appel au serveur et renvoie le résultat.
Les briques de base
Les serveurs peuvent offrir trois types de capacités.
| Primitive | Ce que c’est | Qui décide de l’utiliser |
|---|---|---|
| Outils (tools) | Fonctions que le modèle peut appeler, avec nom, description et schéma d’entrée | Le modèle |
| Ressources (resources) | Données en lecture seule identifiées par un URI, comme un fichier ou un enregistrement | L’application ou l’utilisateur |
| Prompts | Modèles de prompts réutilisables fournis par le serveur | L’utilisateur |
Les outils sont les plus utilisés. La définition d’un outil ressemble à ceci :
{
"name": "estimate_tokens",
"description": "Count the tokens in a prompt for a given model.",
"inputSchema": {
"type": "object",
"properties": {
"prompt": { "type": "string" },
"model": { "type": "string" }
},
"required": ["prompt"]
}
}
La description et le schéma sont lus par le modèle ; ce sont donc des prompts à part entière. Des descriptions d’outils claires sont le principal facteur du bon usage d’un outil par un agent. Voir les prompts pour agents IA.
Transports
MCP définit la façon dont les messages circulent.
- stdio : l’hôte démarre le serveur comme un processus local et communique par l’entrée et la sortie standard. Simple, et rien n’est exposé sur le réseau.
- HTTP en flux (Streamable HTTP) : le serveur tourne comme un service web que les clients joignent par HTTP, ce qui convient aux serveurs distants et partagés et fait entrer l’authentification dans le périmètre.
MCP, appel de fonctions et API
Ce sont des couches, pas des concurrents.
- Une API est la façon dont un logiciel parle à un service.
- L’appel de fonctions est la façon dont un modèle demande l’exécution d’une fonction.
- MCP standardise la façon dont les fonctions sont décrites, découvertes et fournies à n’importe quelle application d’IA.
Un serveur MCP enveloppe souvent une API existante. Si vous ne servez jamais qu’une seule application que vous contrôlez, l’appel de fonctions simple suffit. MCP se justifie quand vous voulez qu’un outil fonctionne avec de nombreux clients.
Configurer un serveur
Les hôtes sont configurés avec une liste de serveurs à démarrer. Un serveur stdio local a besoin d’une commande et de ses arguments :
{
"mcpServers": {
"promptflow": {
"command": "node",
"args": ["/absolute/path/to/packages/mcp-server/dist/bin.js"]
}
}
}
Les noms de clés varient un peu d’un hôte à l’autre, mais la forme est la même.
Considérations de sécurité
Connecter un modèle à des outils est puissant, et cela élargit la surface d’attaque.
Les résultats d’outils sont une entrée non fiable. Un serveur qui récupère des pages web ou lit des tickets renvoie du texte qu’un attaquant a pu écrire. Le modèle peut suivre les instructions qu’il contient. Voir l’injection de prompt.
Le modèle fait confiance aux descriptions d’outils. Un serveur malveillant peut décrire un outil de façon trompeuse pour orienter le modèle. N’installez des serveurs que de sources fiables et examinez ce qu’ils déclarent.
Combiner les capacités multiplie le risque. Une session qui peut lire des données privées, lire du contenu non fiable et envoyer des données à l’extérieur peut devenir une voie d’exfiltration. Évitez de donner les trois à une même session.
Le moindre privilège s’applique. Préférez les serveurs qui font une seule chose, utilisez un accès en lecture seule quand c’est possible et exigez une confirmation pour les actions à effets de bord.
Les serveurs locaux s’exécutent avec vos permissions. Un serveur stdio est un programme sur votre machine. Traitez son installation comme celle de tout autre logiciel.
Concevoir un bon serveur MCP
- Proposez un petit nombre d’outils bien nommés, aux finalités distinctes.
- Rédigez des descriptions qui disent quand utiliser un outil et ce qu’il renvoie.
- Validez chaque argument et renvoyez des erreurs exploitables par le modèle.
- Gardez des résultats compacts, car ils consomment le contexte du modèle.
- Marquez comme lecture seule les outils qui ne font que lire, afin que les hôtes puissent les traiter en conséquence.
- Ne renvoyez jamais de secrets dans les résultats ou les journaux.
Un exemple : des outils de prompts via MCP
Le serveur MCP PromptFlowEngine est une petite illustration de ces principes. Il expose le moteur de prompts sous forme d’outils pour analyser, restructurer, optimiser, comparer et assainir des prompts, ainsi que les catalogues de règles et de modèles sous forme de ressources. Il utilise le transport stdio, ne fait aucun appel réseau et n’a aucun accès aux fichiers ni au shell ; tous ses outils sont donc en lecture seule : ils ne peuvent traiter que le texte qu’on leur donne.
Une fois connecté, un agent peut vérifier son propre travail :
Use promptflow to restructure this before you start:
"fix login issue and make google login work and don't break anything"
L’agent appelle l’outil de restructuration et reçoit une spécification en sections avec exigences, cas limites et critères d’acceptation, qu’il implémente ensuite. La configuration est décrite dans la documentation du client MCP.
Où se situe MCP
MCP est la couche de connexion d’un système d’agents. La boucle de raisonnement qui décide quand appeler un outil est traitée dans le prompting ReAct, et les instructions qui la gouvernent dans les prompts pour agents IA.