MCP Hermes : la checklist avant de connecter un outil externe
Tu veux connecter un outil externe à Hermes. Un MCP pour GitHub, une base de données, une API interne. L’idée est bonne. Mais avant de lancer l’installation, il y a six points à vérifier.
Un MCP, c’est un raccordement à un serveur d’outils externes. Hermes l’utilise comme n’importe quel autre outil, une fois connecté. Le problème n’est pas le mécanisme. Le problème, c’est ce qu’on laisse entrer sans vérifier.
Voici la checklist. Six points. Si un seul est rouge, tu n’installes pas.
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é.
1. Le besoin : est-ce que ce MCP sert à quelque chose ?
La première question n’est pas technique. Elle est pratique.
Tu as peut-être vu un MCP dans le catalogue et tu t’es dit « ça a l’air utile ». Mais est-ce que tu as un vrai besoin aujourd’hui ? Ou est-ce que tu installes par curiosité, en te disant que ça servira plus tard ?
Un MCP installé sans besoin réel, c’est une surface d’attaque de plus. Et une complexité de plus dans ta config. Le catalogue Hermes est sélectionné et relu par Nous Research, les entrées sont désactivées par défaut. Ce n’est pas un hasard.
La règle : installe seulement ce qui répond à un besoin que tu peux nommer en une phrase. Si tu hésites, ne l’installe pas.
2. La source : d’où vient ce MCP ?
Un MCP, c’est du code qui s’exécute. Avant de l’installer, tu dois savoir d’où il vient.
Si le MCP vient du catalogue Hermes, il a été revu par Nous Research avant d’être mergé. Le manifeste est dans le dépôt hermes-agent, dans optional-mcps/<nom>/manifest.yaml. Tu peux le lire avant d’installer.
Si le MCP vient d’ailleurs, d’un dépôt GitHub que tu ne connais pas, ou d’un lien qu’on t’a passé, la vérification est encore plus importante. Regarde le dépôt source, la date du dernier commit, le nombre de contributeurs, les issues ouvertes.
Un MCP maintenu par une personne seule, sans mise à jour depuis six mois, avec zéro étoile, c’est un risque. Tu peux quand même l’installer si tu sais ce que tu fais. Mais au moins, tu le sais.
3. Le manifeste : lis-le avant d’installer
Le manifeste d’un MCP contient tout ce que l’installateur va exécuter : la commande de transport, les arguments, les commandes de bootstrap (pip install, npm install), et l’URL du dépôt source.
Même pour une entrée du catalogue, lis le manifeste. La revue par Nous réduit le risque, elle ne l’annule pas. Le champ source: te dit quel dépôt sera cloné. Le champ install.bootstrap: te dit quelles commandes seront exécutées sur ta machine. Le champ transport.command: te dit quel binaire sera lancé.
Si quelque chose dans le manifeste te semble flou ou disproportionné, ne l’installe pas. Tu peux toujours poser la question sur le dépôt du MCP ou chercher un retour d’expérience.
4. Les permissions : active seulement ce dont tu as besoin
C’est le point le plus important, et le plus souvent raté.
Quand tu installes un MCP via le catalogue, Hermes sonde le serveur pour lister tous les outils qu’il expose. Il te présente une checklist. Tu peux cocher ou décocher chaque outil.
La documentation recommande une exposition minimale : seuls les outils que tu vas vraiment utiliser doivent être activés. Les autres restent décochés.
Un exemple concret. Tu installes un MCP pour une base de données. Il expose 12 outils : read, write, delete, create_table, drop_table, list_databases, etc. Tu as seulement besoin de read et list_databases. Si tu actives tout, tu donnes à Hermes la capacité de supprimer des tables ou des bases entières. Pour aucun bénéfice.
La règle : coche uniquement les outils dont tu peux expliquer l’usage en une phrase. Si tu ne sais pas à quoi sert un outil, décoche-le.
5. Le test : vérifie avant d’utiliser en production
Tu as installé le MCP. Tu as sélectionné les outils. Avant de l’utiliser dans un vrai projet, teste-le.
Ouvre une session Hermes dédiée. Demande au MCP une opération simple et sans conséquence. Pour un MCP fichiers, liste un répertoire. Pour un MCP GitHub, lis les infos d’un repo public. Pour un MCP base de données, fais une requête SELECT en lecture seule.
Ce que tu vérifies :
- Le MCP répond sans erreur.
- Les outils que tu as activés sont bien disponibles.
- Les outils que tu as désactivés ne sont pas accessibles.
- Le comportement correspond à ce que tu attendais.
Si le test échoue, ne contourne pas. Désactive le MCP et cherche la cause. Un MCP qui ne répond pas comme prévu en test ne deviendra pas fiable en production.
6. Le repli : savoir désactiver ou désinstaller
Le dernier point de la checklist, c’est le retour arrière.
Avant de connecter un MCP, tu dois savoir comment le désactiver ou le désinstaller. La commande hermes mcp te donne l’état de chaque MCP installé. Tu peux désactiver un MCP sans le désinstaller, ou le supprimer complètement.
Si tu installes un MCP manuellement dans ~/.hermes/config.yaml, commenter le bloc mcp_servers.<nom> suffit à le désactiver. Supprimer le bloc le désinstalle.
La règle : si tu ne sais pas comment revenir en arrière, n’installe pas. Un MCP doit pouvoir être retiré en moins de deux minutes, sans casser le reste de ta config.
La checklist en un coup d’oeil
| Point | Question | Feu vert si |
|---|---|---|
| Besoin | Est-ce que j’ai un vrai besoin aujourd’hui ? | Tu peux le nommer en une phrase |
| Source | D’où vient ce MCP, qui le maintient ? | Dépôt connu, maintenu, revu (catalogue) ou vérifié par toi |
| Manifest | Qu’est-ce que l’installateur va exécuter ? | Tu as lu le manifeste et rien ne te semble anormal |
| Permissions | Quels outils sont activés ? | Seulement ceux dont tu as besoin |
| Test | Est-ce que ça marche comme prévu ? | Test réussi sur une opération sans conséquence |
| Repli | Est-ce que je sais comment désactiver ? | Désactivation possible en moins de deux minutes |
Ce que la checklist ne couvre pas
Cette checklist réduit les risques liés à l’installation d’un MCP. Elle ne les annule pas.
Un MCP reste du code tiers qui s’exécute sur ta machine ou se connecte à des services externes. La revue du catalogue par Nous Research est un filtre utile, pas une garantie. Le manifeste peut évoluer après ton installation. Les outils que tu as activés peuvent avoir des comportements que tu n’anticipes pas.
La checklist te donne un cadre pour décider. Elle ne remplace pas ta vigilance.
Pour aller plus loin sur la sécurisation d’un environnement Hermes, l’article sur les points de contrôle des agents IA en production couvre les bonnes pratiques de configuration et de supervision. Et si tu veux apprendre à configurer un environnement Hermes complet avec les bons MCP et les bonnes permissions, tu peux faire une demande d’accès à la formation Hermes Agent. Le programme couvre l’installation, la configuration des profils, et la mise en place d’un board Kanban pour ne pas avancer seul.
