Le Model Context Protocol (MCP) expliqué simplement – avec un exemple n8n

Qui construit des agents IA connaît le problème : pour chaque fonction d’un service connecté, il faut définir un outil distinct. Chercher, créer, modifier, supprimer une entrée d’agenda – cela fait vite quatre briques séparées, et ce pour un seul service. Avec de nombreuses connexions, la charge de maintenance augmente d’autant. Le Model Context Protocol (MCP) suit une autre approche : il standardise la façon dont un modèle de langage communique avec un service – et réduit drastiquement le nombre de briques nécessaires. Cet article résume le concept et un exemple pratique concret avec n8n.

Ce que MCP résout réellement

L’idée de base du Model Context Protocol tient dans son nom : un modèle de langage doit comprendre le contexte d’une application. Concrètement : que sait faire cette application ? À quoi sert-elle ? Et comment y exécuter des actions ?

Classiquement, on connecte chaque outil individuellement lors de la construction d’un agent – chaque fonction est une brique à part. Pour Google Calendar par exemple : un outil pour chercher des entrées, un pour les mettre à jour, un pour les supprimer, un pour les créer. Quatre fonctions pour un seul service. Sur des agents complexes reliés à de nombreux services, cela monte vite à des dizaines de briques.

Serveur, client et le schéma uniforme

MCP fonctionne avec deux rôles :

• Serveur MCP : il se place devant le service proprement dit (p. ex. Airbnb ou Google Calendar) et décrit comment interagir avec ce service.
• Client MCP : il se trouve dans l’agent, récupère les fonctions du serveur et les appelle.

Dans la mise en œuvre actuelle – par exemple dans n8n – deux étapes suffisent au lieu de nombreux outils individuels :

1. List Tools (lister) : l’agent demande au serveur quelles fonctions sont disponibles.
2. Execute Tool (exécuter) : l’agent appelle une fonction précise avec les paramètres correspondants.

Le point décisif est le schéma uniforme. Peu importe le service situé derrière : la réponse à une requête List Tools est toujours construite de la même manière. Elle contient, pour chaque fonction, le nom, une description et un schéma avec les paramètres autorisés. Les contenus et les paramètres diffèrent d’un service à l’autre – la structure, elle, reste constante. C’est exactement ce que le protocole prescrit et standardise.

Un exemple avec l’outil Airbnb

Si l’on demande à l’agent quelles possibilités offre l’outil Airbnb, il va chercher lui-même la liste des fonctions via l’outil List Tools. Reviennent entre autres :

• Airbnb Search : recherche d’offres avec filtres et pagination – lieu, dates d’arrivée et de départ, nombre d’adultes, d’enfants, de bébés et d’animaux, ainsi que fourchette de prix.
• Airbnb Listing Details : informations détaillées sur une offre donnée via son identifiant d’annonce.

L’agent n’a eu besoin d’aucune consigne préalable ici – il s’est procuré lui-même les fonctions disponibles, leurs descriptions et le schéma des paramètres. Dans le schéma, on voit par exemple un champ texte location (ville, région, etc.), les champs de date pour l’arrivée et le départ, le nombre d’adultes ainsi que le prix minimum et maximum.

Si l’on formule ensuite une demande concrète – par exemple un logement à Bangkok pour six personnes à 50 euros la nuit au maximum –, l’agent procède en deux temps : il appelle d’abord List Tools (il n’a rien retenu, aucune mémoire n’étant active), identifie les paramètres nécessaires grâce au schéma et lance la recherche via Execute Tool. Le résultat – par exemple un logement avec trois lits pour environ 35 euros la nuit – revient, et cela avec seulement deux outils ajoutés. Si Airbnb proposait davantage de fonctions, par exemple pour gérer ses propres annonces, elles se refléteraient dans le même schéma, sans qu’il faille définir d’autres briques.

Comment reproduire MCP dans n8n

Les étapes suivantes montrent la configuration sur l’exemple Airbnb. Il se prête bien à l’essai, car aucune clé d’API n’est nécessaire.

1. Définir la variable d’environnement : mettez N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE sur true. Cela autorise les nodes communautaires à accéder aux outils. Dans une installation Docker (p. ex. sur un serveur Hetzner), inscrivez-la dans la section environment du fichier docker-compose et redémarrez l’instance.
2. Créer l’AI Agent : créez un AI Agent et associez-lui un modèle (dans la vidéo, GPT-4.1 Mini).
3. Installer le node communautaire : sous Settings → Community Nodes, installez le paquet n8n-nodes-mcp et confirmez l’avertissement concernant l’installation de code non vérifié provenant de sources publiques.
4. Ajouter l’outil client MCP : via le plus à côté de Tools, cherchez « MCP ». Attention : à ne pas confondre avec le MCP Client Tool maison de n8n – la variante communautaire se reconnaît au symbole de boîte et est actuellement plus complète.
5. Créer les identifiants : comme type de connexion, vous avez le choix entre Command Line, Server-Sent Events et HTTP Streamable. Dans l’exemple, on reste sur Command Line. Les bonnes valeurs figurent dans le dépôt du serveur MCP concerné, à la section consacrée à l’installation. Pour Airbnb : commande npx, arguments saisis un par un – -y, le paquet @openbnb/mcp-server-airbnb et, en option, --ignore-robots-txt.

Remarque sur robots.txt : l’option --ignore-robots-txt passe outre les règles d’accès d’un site web. Pour une démonstration, c’est défendable – en production, respectez le fichier robots.txt des services concernés.

Configurer les deux opérations

Il vous faut ensuite deux outils client MCP avec des opérations différentes :

• List Tools : nommez l’outil p. ex. « Airbnb List Tools » et indiquez en description qu’il sert à récupérer tous les outils Airbnb disponibles. Un clic de test (Execute Step) devrait renvoyer la liste de fonctions connue, avec nom, description et schéma.
• Execute Tool : un second outil client MCP avec l’opération Execute Tool. Description : sert à exécuter des outils Airbnb, listables via l’outil List Tools. Vous transmettez le nom de l’outil sous forme d’expression, de sorte que l’agent décide lui-même quelle fonction appeler ; vous laissez les paramètres de l’outil libres pour qu’il les détermine lui-même.

Après avoir rangé et enregistré, l’agent peut être testé – par exemple à nouveau avec la demande sur Bangkok. Il récupère la liste des fonctions, la renvoie au modèle, opte pour la recherche et fournit des logements adaptés. Exactement le comportement décrit dans la partie conceptuelle, cette fois dans votre propre workflow.

Au-delà de n8n – et un mot sur la sécurité

MCP ne se limite pas aux plateformes d’automatisation. Des applications de bureau comme Claude Desktop peuvent elles aussi être reliées à des serveurs MCP. On peut ainsi déléguer, depuis le chat, des tâches à des programmes installés localement – un exemple souvent cité est le pilotage du logiciel 3D Blender via MCP, où une personne sans connaissance de Blender réalise des rendus. Le serveur MCP tourne alors en local, le modèle de langage passant toujours par le service cloud.

Malgré l’enthousiasme : MCP est un développement récent. Il existe déjà des réserves de sécurité, et des failles ont été découvertes. En environnement de production surtout, la technologie est à manier avec prudence – il vaut la peine d’observer la suite avant d’y adosser des processus critiques.

Conclusion

Le Model Context Protocol est une approche de standardisation pragmatique : via un serveur MCP, un modèle de langage apprend lui-même ce qu’un service sait faire et comment s’y adresser – au lieu de prédéfinir chaque fonction une par une. Pour des agents IA complexes, cela signifie nettement moins de briques et moins de maintenance ; dans l’exemple n8n, deux étapes suffisent : lister et exécuter. L’approche est convaincante, mais encore jeune. Qui veut l’essayer devrait commencer par des services non critiques et prendre au sérieux, en production, les questions de sécurité restées ouvertes.

Source : Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) – chaîne YouTube Philip Thomas (en allemand).