Outils natifs ou MCP dans Hermes : décider avant d’ajouter une dépendance
Tu installes Hermes. Tu explores ce qu’il peut faire. Et assez vite, tu tombes sur le catalogue MCP : des dizaines de connecteurs prêts à brancher. GitHub, Linear, Notion, un filesystem, des APIs internes.
Le réflexe est humain : tu coches. Tu actives. Tu te dis que plus il y a d’outils, plus l’agent sera capable.
C’est le premier piège.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Hermes embarque déjà une trentaine d’outils natifs. MCP ne les remplace pas. Il les étend vers l’extérieur, vers des services que Hermes ne connaît pas nativement. Ajouter un connecteur MCP pour un besoin déjà couvert par un outil natif, c’est ajouter une dépendance, un point de défaillance, et de la maintenance pour zéro gain.
La règle est simple : regarde d’abord ce que Hermes sait faire sans rien ajouter. Si le besoin n’est pas couvert, MCP. Sinon, passe ton chemin.
Ce que Hermes sait faire sans rien ajouter
Hermes livre avec un registre d’outils natifs organisé en toolsets, activables ou désactivables par plateforme. Voici l’inventaire par catégorie.
Web. web_search et web_extract couvrent la recherche et l’extraction de contenu. Pas besoin d’un MCP pour lire une page web.
Terminal et fichiers. terminal, process, read_file, patch, write_file, search_files. Tu peux exécuter des commandes, lire, éditer, rechercher dans des fichiers. Le terminal supporte plusieurs backends : local, Docker, SSH, Modal. Pas besoin d’un MCP filesystem pour manipuler des fichiers locaux.
Browser. browser_navigate, browser_snapshot, browser_click, browser_vision. Un navigateur interactif complet, avec capture d’écran et analyse visuelle. Pas besoin d’un MCP Playwright pour interagir avec une page web.
Media. vision_analyze, image_generate, text_to_speech. Analyse d’image, génération d’image, synthèse vocale. Pas besoin d’un MCP pour ces capacités multimodales.
Orchestration. liste de tâches, delegate_task, kanban_*. Planification, délégation à des sous-agents, file de tâches durable. Pas besoin d’un MCP pour orchestrer des agents.
Mémoire et recherche. memory, session_search. Mémoire persistante et recherche dans l’historique des sessions.
Automatisation. cronjob. Tâches planifiées avec création, listing, pause, reprise.
Intégrations. ha_* pour Home Assistant, et les outils MCP eux-mêmes une fois configurés.
La documentation officielle organise ces outils en toolsets que tu actives ou désactives par plateforme. En CLI, hermes tools te montre la liste complète et te laisse configurer ce qui est disponible.
Ce que MCP apporte
MCP, pour Model Context Protocol, est un standard qui connecte Hermes à des serveurs d’outils externes. La documentation le décrit comme un raccordement à des serveurs d’outils en dehors de Hermes : GitHub, bases de données, systèmes de fichiers distants, navigateurs headless, APIs internes.
Hermes embarque un catalogue curé de serveurs MCP. Chaque entrée a été revue par l’équipe Nous Research avant d’être mergée dans le dépôt. Les entrées sont désactivées par défaut : tu installes seulement ce dont tu as vraiment besoin.
L’installation se fait en deux commandes :
hermes mcp # picker interactif
hermes mcp install n8n # installation par nomPendant l’installation, Hermes sonde le serveur MCP pour lister tous les outils qu’il expose, puis te présente une checklist. Tu coches uniquement les outils que tu veux rendre disponibles à l’agent. Seuls les outils cochés sont écrits dans la configuration. Si tu sélectionnes tout, aucun filtre n’est écrit, mais le comportement est identique.
Natif ou MCP : le tableau de décision
| Critère | Outil natif | MCP |
|---|---|---|
| Disponibilité | Immédiate, sans dépendance externe | Dépend d’un serveur externe qui doit tourner |
| Maintenance | Gérée par les mises à jour de Hermes | À ta charge : version du serveur, compatibilité, tokens |
| Périmètre | Fonctions intégrées à Hermes (web, fichiers, terminal, browser) | Services externes (GitHub, Linear, Notion, APIs maison) |
| Sécurité | Gouvernée par les toolsets et les modes d’approbation Hermes | Dépend du serveur MCP, de ses permissions, et de son code |
| Quand l’utiliser | Le besoin est couvert par l’inventaire natif | Le besoin porte sur un service externe absent du natif |
Les 3 questions à te poser avant d’ajouter un MCP
Avant d’installer un connecteur, pose-toi ces trois questions. Elles t’éviteront la plupart des dépendances inutiles.
1. Le besoin est-il déjà couvert par un outil natif ?
Exemple concret : tu veux que ton agent lise et modifie des fichiers. Hermes a read_file, write_file, patch, search_files, et terminal. Installer un MCP filesystem pour ça, c’est ajouter un processus Node.js qui tourne en permanence pour faire ce que Hermes fait déjà. Zéro gain, une dépendance de plus.
Autre exemple : tu veux que ton agent navigue sur le web. Hermes a browser_navigate, browser_snapshot, browser_click. Installer un MCP Playwright, c’est maintenir un deuxième navigateur pour la même capacité.
2. L’outil externe est-il indispensable au workflow ?
Si tu gères tes projets dans Linear et que tu veux que ton agent crée des tickets ou lise des issues, le MCP Linear a un vrai rôle : Hermes n’a pas d’outil natif pour interagir avec l’API Linear. Le connecteur est justifié.
Si tu utilises Notion une fois par mois pour stocker des notes, le MCP Notion est probablement superflu. Tu peux copier-coller l’information dans ta session Hermes, ou utiliser un export markdown que l’agent lira avec read_file.
3. La maintenance du connecteur vaut-elle le gain ?
Chaque MCP ajoute une surface de maintenance. Le serveur doit tourner. Les tokens OAuth expirent. L’API du service change. Le manifeste du catalogue MCP évolue. Si le gain est marginal, la maintenance finit par coûter plus cher que le service rendu.
Ce qui peut mal tourner
Le premier piège, c’est l’empilement. Tu actives cinq MCP « au cas où ». Trois ne servent jamais. Un quatrième casse après une mise à jour de Hermes et tu passes une heure à debugger un connecteur que tu n’utilises pas. Le cinquième tourne en permanence et consomme des ressources pour rien.
Le deuxième piège, c’est la confusion des responsabilités. Un MCP filesystem qui expose / en écriture, c’est un agent qui peut modifier n’importe quel fichier de ton système. Un MCP GitHub avec des permissions trop larges, c’est un agent qui peut pusher sur tes repos sans revue. La checklist de sélection d’outils à l’installation est faite pour ça : coche uniquement ce dont l’agent a vraiment besoin.
La documentation MCP est claire sur le modèle de confiance : chaque entrée du catalogue exécute le code spécifié dans son manifeste. L’équipe Nous Research a revu chaque entrée avant de la merger, mais tu dois lire le manifeste avant d’installer, surtout le champ source: (le dépôt), les commandes bootstrap:, et l’invocation transport.command:.
Comment décider en pratique
La règle est simple, et elle tient en une phrase : ajoute un connecteur MCP seulement pour un besoin absent du natif.
Pas pour « au cas où ». Pas pour « ça pourrait servir ». Pas pour « c’est facile à installer ».
Quand tu hésites, commence par l’outil natif. Tu pourras toujours ajouter un MCP plus tard si le besoin se confirme. L’inverse est plus lourd : désinstaller un MCP, nettoyer sa configuration, et se demander si un processus fantôme tourne encore quelque part.
Pour maîtriser la configuration des outils natifs, l’activation des toolsets par plateforme, et l’intégration propre d’un MCP quand le besoin est réel, la formation Hermes Agent couvre l’ensemble du cycle : inventaire natif, catalogue MCP, sélection d’outils, et patterns de configuration qui tiennent dans la durée. Tu peux faire une demande d’accès directement sur la page de la formation.
