Hermes Agent : comprendre MCP et brancher un premier serveur proprement

Tu as déjà un Hermes qui tient debout. La question qui arrive ensuite, c’est simple : MCP, ça sert à quoi, et à quel moment ça mérite d’entrer dans ton setup ?

Ce tuto répond à ça sans refaire tout le cours sur l’écosystème. On pose ce qu’apporte MCP, on prend un premier serveur concret, et on voit comment le brancher proprement sans alourdir ton setup.

Ce que tu auras à la fin
Une compréhension nette de MCP, la différence brève entre tool, serveur MCP et skill, un premier exemple concret avec un serveur filesystem, une méthode simple pour le brancher, et un cadre clair pour décider s’il mérite de rester.

Pour qui est ce tuto
Tu as déjà compris les tools de base et tu veux étendre Hermes proprement, sans empiler des intégrations au hasard.

MCP, c’est quoi exactement

MCP veut dire Model Context Protocol. Derrière le nom, l’idée est simple : c’est une manière standard de connecter un agent à des capacités externes.

Concrètement, un serveur MCP expose une ou plusieurs capacités, et Hermes vient les découvrir puis les utiliser. L’intérêt n’est pas d’ajouter de la magie. L’intérêt, c’est d’éviter le bricolage intégration par intégration.

MCP n’est donc ni un tool unique, ni une skill. C’est une couche d’intégration qui permet d’amener des capacités externes jusqu’à ton agent de manière plus propre et plus modulaire.

La différence entre tool, serveur MCP et skill

Pas besoin d’en refaire une grande taxonomie. Pour ce tuto, retiens juste ça :

• un tool est une capacité concrète que l’agent appelle
• un serveur MCP expose une ou plusieurs capacités à l’agent via MCP
• une skill décrit une manière de travailler sur un type de tâche

Dit autrement : le tool fait, le serveur MCP branche, la skill cadre.

Pourquoi MCP peut être utile

MCP commence à être intéressant quand tu veux étendre Hermes sans multiplier les petits bricolages séparés.

Trois gains reviennent souvent :

• standardiser l’ajout de capacités externes
• éviter de refaire à la main une intégration déjà propre ailleurs
• garder un setup modulaire, où une brique peut être ajoutée ou retirée sans toucher au reste

MCP n’est pas là pour rendre ton agent soudainement brillant. Il sert surtout à faire propre quand ton setup commence à s’élargir.

Pourquoi MCP n’est pas obligatoire au début

C’est le point à garder froid.

Hermes peut déjà être utile sans MCP. Si tu n’as pas encore tiré quelque chose de clair de ton noyau de base, ajouter un serveur en plus ne va pas régler le problème.

MCP ajoute aussi de la complexité : un processus de plus, une config de plus, un comportement de plus à observer. Tant que tu ne sais pas encore ce que tu attends d’une extension, ça fait surtout du bruit.

La bonne logique reste la même : base stable d’abord, extension ensuite.

Quel premier serveur MCP choisir

Le bon premier serveur n’est pas celui qui expose le plus de choses. C’est celui que tu comprends en une phrase.

Quelques critères suffisent :

• sobre
• utile pour un besoin réel
• facile à tester
• réversible sans douleur
• avec un périmètre clair

Évite les gros ensembles trop tôt. Pour un premier branchement, tu veux voir ce qui apparaît, comprendre à quoi ça sert, puis juger à l’usage.

Exemple concret : un premier serveur MCP filesystem

Le premier candidat le plus simple, pour beaucoup de gens, c’est un serveur MCP filesystem.

L’idée est très lisible : tu autorises un dossier précis, puis Hermes peut le lister, le lire et l’explorer à travers MCP. C’est un bon premier cas parce que tu comprends tout de suite ce qui est exposé, tu peux tester sur un petit dossier propre, et le périmètre reste facile à contrôler.

Pourquoi c’est un bon premier serveur

• Tu comprends immédiatement son rôle
• Tu peux le tester sur un dossier que tu connais déjà
• Le périmètre est simple à limiter
• Il se retire facilement si ça ne sert à rien

Surtout, il matérialise enfin MCP. Tant que MCP reste un mot, tu n’apprends pas grand-chose. Le jour où Hermes explore un dossier de test via un serveur dédié, tu vois tout de suite ce que la couche ajoute réellement.

Comment brancher un premier serveur MCP proprement

La mécanique exacte peut varier selon ta version d’Hermes. Ce qui compte ici, c’est la discipline.

Un serveur à la fois. Tu veux pouvoir attribuer clairement un effet à un seul changement.

Lis ce que tu branches. Avant l’ajout, comprends ce que le serveur expose et ce qu’il demande.

Commence avec un périmètre minuscule. Pour un filesystem, n’ouvre pas un gros dossier par réflexe. Pars d’un dossier de test sans contenu sensible.

Fais une sauvegarde rapide de ta config avant l’ajout. Pas pour faire joli. Pour pouvoir revenir proprement en arrière.

Ne change rien d’autre en parallèle. Pas de nouveau modèle, pas d’autre intégration, pas de réglages retouchés le même soir.

Le but du premier branchement n’est pas d’aller vite. C’est de rester lisible.

Le premier vrai test utile

Une fois le serveur déclaré, résiste à l’envie de lui donner tout de suite une grosse tâche.

Le bon premier test est minuscule : demander à Hermes de lister le dossier autorisé et de résumer ce qu’il contient.

Tu vérifies alors trois choses :

• le serveur est bien visible
• Hermes l’utilise au bon moment
• le résultat revient proprement

Si ça passe, tu peux seulement ensuite monter d’un cran. Si ça ne passe pas, tu règles ça avant d’ajouter quoi que ce soit.

Comment savoir si un serveur MCP mérite de rester

Au bout de quelques usages réels, pose-toi ces questions :

• est-ce qu’il me sert vraiment ?
• est-ce que je comprends encore ce qu’il expose ?
• est-ce qu’il reste stable ?
• est-ce qu’il apporte quelque chose sans envahir le setup ?
• est-ce que je le rebrancherais si je repartais de zéro ?

Si plusieurs réponses passent au rouge, retire-le. Un serveur MCP n’a pas à rester actif juste “au cas où”.

Les erreurs les plus fréquentes

• en brancher plusieurs d’un coup
• ouvrir un périmètre trop large dès le départ
• ne pas comprendre ce que le serveur expose
• confondre installation et validation réelle
• croire qu’un setup devient meilleur parce qu’il empile plus d’intégrations

Le piège classique, c’est de réussir l’ajout technique puis de ne jamais vérifier la valeur réelle.

Ce que tu ne dois pas faire

• transformer Hermes en vitrine d’intégrations dès le début
• brancher un serveur que tu ne comprends pas
• donner à un filesystem un accès plus large que nécessaire
• croire que MCP remplace une base propre
• garder une brique active que tu n’oses plus toucher

La règle reste la même depuis le début : comprendre avant d’empiler.

La suite logique

Tu as maintenant l’essentiel : ce que MCP apporte, pourquoi il ne faut pas le brancher trop tôt, quel premier serveur choisir, et comment le tester sans alourdir tout ton setup.

La suite logique, c’est le tuto sur les skills. Là, on ne parle plus d’étendre les capacités d’Hermes, mais de cadrer proprement sa manière de travailler sur un type de tâche donné.

En attendant, garde le bon réflexe : un petit serveur, un petit périmètre, un vrai test, puis verdict. C’est largement suffisant pour un premier pas propre.