Tous les quelques années, un protocole émerge qui change la façon dont les composants logiciels communiquent entre eux. HTTP l'a fait pour le web. OAuth l'a fait pour l'authentification. GraphQL l'a fait pour les API. En 2025, Model Context Protocol — MCP — le fait pour les outils d'agents IA.
Le problème que MCP résout est d'une simplicité trompeuse. Un agent IA a besoin d'utiliser des outils — chercher sur le web, lire des fichiers, interroger des bases de données, appeler des API. Sans protocole standard, chaque intégration d'outil est une implémentation sur mesure. Le framework d'agent définit son propre format d'outil, le fournisseur d'outil implémente ce format, et l'intégration fonctionne pour ce framework spécifique et cet outil spécifique. Vous voulez utiliser le même outil dans un framework différent ? Réécrivez l'intégration. Vous voulez ajouter un nouvel outil à votre agent ? Écrivez un adaptateur personnalisé.
MCP élimine cette taxe d'intégration par framework et par outil. Un outil qui parle MCP fonctionne avec n'importe quel agent qui parle MCP. Écrivez une fois, utilisez partout. L'analogie avec l'USB-C est pertinente — avant l'USB-C, chaque appareil avait son propre chargeur. Après l'USB-C, un seul câble fonctionne pour tout. MCP fait la même chose pour les outils d'agents IA.
Ce qu'est réellement MCP
MCP est un protocole basé sur JSON-RPC qui définit comment un agent IA découvre, invoque et reçoit les résultats d'outils externes. Un serveur MCP expose un ensemble d'outils avec des schémas typés — des descriptions de ce que fait chaque outil, quels paramètres il accepte et ce qu'il renvoie. Un client MCP (l'agent) se connecte au serveur, découvre les outils disponibles et les invoque selon les besoins pendant la conversation.
Le protocole gère les mécanismes que chaque intégration personnalisée doit réinventer : la découverte d'outils (quels outils sont disponibles ?), la validation de schéma (les paramètres sont-ils corrects ?), l'invocation (exécuter l'outil et renvoyer les résultats) et la gestion d'erreurs (que se passe-t-il quand un outil échoue ?). Ce sont des problèmes résolus qui n'ont pas besoin d'être résolus à nouveau pour chaque intégration.
Anthropic a développé MCP et l'a publié en open source, mais ce n'est pas un protocole spécifique à Anthropic. N'importe quel fournisseur d'IA peut implémenter le support client MCP, et n'importe quel développeur peut construire des serveurs MCP. L'écosystème croît rapidement — il existe déjà des serveurs MCP pour GitHub, Slack, les bases de données, les systèmes de fichiers, les navigateurs web et des dizaines d'autres services. ## Comment NanoClaw utilise MCP
NanoClaw intègre MCP via le MCP SDK, qui fait partie de la même boîte à outils Anthropic que Claude Agent SDK. Quand un agent tourne dans un conteneur NanoClaw, il peut se connecter aux serveurs MCP que l'hôte a configurés, lui donnant accès à des outils sans aucun code d'intégration personnalisé dans NanoClaw lui-même.
C'est un point architectural subtil mais important. NanoClaw n'a pas besoin d'implémenter une intégration GitHub, une intégration Slack ou une intégration de base de données. Il lui suffit de supporter MCP, et ensuite n'importe quel serveur MCP fournit ces capacités. La surface d'intégration est un seul protocole, pas des dizaines d'adaptateurs personnalisés.
En pratique, cela signifie qu'un utilisateur de NanoClaw qui veut que son agent interagisse avec GitHub installe le serveur MCP GitHub (un processus séparé), configure NanoClaw pour s'y connecter, et l'agent peut immédiatement créer des issues, lire des pull requests et chercher dans les dépôts. Pas de modification du code de NanoClaw. Pas de skill Claude Code nécessaire. Pas de fork requis.
Le modèle d'isolation par conteneur fonctionne naturellement avec MCP. Le serveur MCP tourne sur l'hôte, en dehors du conteneur. L'agent à l'intérieur du conteneur s'y connecte via un canal contrôlé. Le serveur MCP peut appliquer ses propres contrôles d'accès — accès en lecture seule aux dépôts, canaux Slack spécifiques uniquement, tables de base de données particulières — indépendamment de ce que l'agent demande. C'est de la défense en profondeur : même si une injection de prompt pousse l'agent à demander quelque chose qu'il ne devrait pas, le serveur MCP peut refuser la requête selon sa propre politique.
Pourquoi MCP compte pour l'écosystème
La portée plus large de MCP est qu'il découple le développement d'outils du développement d'agents. Avant MCP, construire un outil d'agent IA utile signifiait choisir un framework et implémenter l'interface d'outil de ce framework. Votre outil GitHub fonctionnait avec LangChain mais pas avec CrewAI. Votre outil de base de données fonctionnait avec AutoGen mais pas avec NanoClaw. Chaque framework avait son propre format d'outil, et les développeurs d'outils devaient choisir quels frameworks supporter.
MCP brise ce couplage. Un développeur d'outil construit un seul serveur MCP, et il fonctionne avec chaque agent compatible MCP. Un développeur d'agent supporte MCP une fois, et chaque serveur MCP devient disponible pour ses utilisateurs. L'écosystème croît de manière multiplicative plutôt que linéaire — chaque nouveau serveur MCP bénéficie à chaque agent compatible MCP, et chaque nouvel agent compatible MCP bénéficie de chaque serveur MCP existant.
Pour NanoClaw spécifiquement, MCP signifie que le projet n'a pas besoin de construire et maintenir des intégrations pour chaque service que ses utilisateurs pourraient vouloir. Le modèle de skills Claude Code gère les intégrations de canaux (Telegram, Discord, Slack), et MCP gère les intégrations d'outils (GitHub, bases de données, API). Entre les deux, NanoClaw couvre un large éventail de cas d'usage sans la charge de maintenance d'une grande base de code d'intégrations.
La mise en place concrète
Configurer MCP dans NanoClaw est simple. Vous lancez un serveur MCP — soit un que vous avez construit, soit un de l'écosystème croissant de serveurs open source — et vous pointez NanoClaw dessus. L'agent découvre automatiquement les outils disponibles et peut les utiliser en conversation.
L'expérience du point de vue de l'utilisateur est transparente. Vous demandez à votre assistant WhatsApp « crée une issue GitHub pour le bug de connexion dont on a parlé hier », et l'agent utilise le serveur MCP GitHub pour créer l'issue, en tirant le contexte de sa mémoire de conversation pour remplir les détails. Vous n'avez pas besoin de savoir que MCP est impliqué. Vous demandez, et l'agent a les outils pour faire ce que vous avez demandé.
Le protocole est encore jeune — c'est début 2025 que l'adoption a commencé à s'accélérer — mais la trajectoire est claire. MCP est en train de devenir le standard pour l'interaction des agents IA avec les services externes, et les projets qui l'adoptent tôt accèdent à un écosystème d'outils en croissance sans en construire aucun. Le pari de NanoClaw sur MCP est un pari que l'écosystème sera plus précieux que n'importe quel ensemble d'intégrations personnalisées ne pourrait l'être.