Catalogue MCP Hermes : ce que “reviewed” veut dire — et ce que ça ne garantit pas

Quand tu ouvres le catalogue MCP de Hermes Agent, chaque entrée affiche un statut. « Available », « installed », « enabled ». Et quelque part dans le manifeste, un indicateur plus discret : l’entrée a été revue par l’équipe Nous Research avant d’être mergée dans le dépôt.

C’est rassurant. Mais ça ne répond pas à la vraie question : qu’est-ce que cette revue garantit, concrètement, et qu’est-ce qu’elle ne couvre pas ?

Si tu installes un MCP sans lire son manifeste, tu délègues une partie de ta sécurité à une revue de PR dont tu ne connais pas le périmètre. Cet article te donne les critères pour décider par toi-même.

Communauté Kavyro

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.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Ce que le statut « reviewed » signifie vraiment

Le catalogue MCP de Hermes n’est pas un store ouvert. Les entrées sont stockées dans le dossier optional-mcps/ du dépôt hermes-agent sur GitHub, et une entrée n’y arrive que par une pull request mergée par l’équipe Nous Research.

Ça veut dire trois choses :

1. Quelqu’un a lu le manifeste. La PR a été relue avant merge. Le fichier manifest.yaml qui décrit la source, les commandes d’installation et le transport a été examiné.
2. La source est identifiée. Le champ source: pointe vers un dépôt public. Tu sais d’où vient le code.
3. L’entrée est désactivée par défaut. Même après merge dans le catalogue, le MCP n’est pas actif. Tu dois explicitement l’installer avec hermes mcp install <nom>.

C’est un premier filtre utile. Mais ce n’est pas un audit de sécurité.

Ce que la revue ne garantit pas

La revue d’une PR catalogue vérifie la cohérence du manifeste et la légitimité apparente de la source. Elle ne remplace pas une inspection du code que le MCP va exécuter.

Ce que « reviewed » garantit	Ce que « reviewed » ne garantit pas
Le manifeste est syntaxiquement valide et cohérent	Le code du dépôt source est exempt de comportement malveillant
La source pointe vers un dépôt public identifiable	Le dépôt source n’a pas été compromis après la revue
Les commandes de bootstrap sont explicites	Les dépendances installées par le bootstrap sont sûres
L’entrée est désactivée par défaut	L’utilisateur a lu le manifeste avant d’installer

La doc de Hermes est claire sur ce point : « Installing a catalog entry runs whatever the manifest specifies, git clone, the entry’s bootstrap commands, and ultimately the MCP server’s own code. Manifests are gated by PR review into the hermes-agent repo, so Nous has reviewed each entry before it shipped, but you should still read the manifest before installing. »

Le « but » est important. La revue est une porte d’entrée, pas une certification.

Les trois couches de contrôle que tu as (et que tu devrais utiliser)

Hermes ne te laisse pas sans outils. Tu as trois leviers pour réduire le risque, et ils sont tous activables sans être développeur.

1. Lire le manifeste avant d’installer

Le picker interactif (hermes mcp) affiche la source de chaque entrée. Le dashboard web de Hermes surface aussi ces infos : transport, type d’auth, commandes de bootstrap, et un lien cliquable vers le dépôt source.

Avant de taper install, regarde trois champs :

• source: le dépôt Git d’où vient le code. Est-ce que c’est un dépôt que tu connais ? Est-ce qu’il a une historique de maintenance visible ?
• install.bootstrap: les commandes exécutées pendant l’installation. Un pip install ou npm install va chercher des dépendances. Sont-elles légitimes ?
• transport.command: la commande qui lance le serveur MCP. Qu’est-ce qui s’exécute sur ta machine ?

Si un de ces champs te met mal à l’aise, n’installe pas. Le catalogue n’est pas une obligation.

2. Filtrer les outils exposés

Quand tu installes un MCP, Hermes sonde le serveur et te présente une checklist des outils disponibles. Tu peux décocher ceux dont tu n’as pas besoin.

Un exemple concret : le MCP Linear expose un outil delete_workspace. Si ton usage se limite à lire des issues et en créer, décoche cette case. L’outil ne sera pas enregistré, et Hermes ne pourra pas l’appeler.

Tu peux aussi configurer le filtrage directement dans ~/.hermes/config.yaml :

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, search_code]

Seuls les outils listés dans include sont exposés. Si tu préfères une approche par exclusion, utilise exclude pour retirer les outils dangereux tout en gardant le reste.

3. Désactiver le sampling si tu n’en as pas besoin

Le sampling MCP permet à un serveur de demander à Hermes de générer du texte via un LLM. C’est activé par défaut.

Si tu installes un MCP pour des opérations simples (lire des fichiers, lister des issues), tu n’as probablement pas besoin que ce serveur puisse déclencher des appels LLM. Désactive-le :

mcp_servers:
  untrusted_server:
    url: "https://mcp.example.com"
    sampling:
      enabled: false

C’est un levier de plus pour limiter la surface de ce qu’un MCP peut faire.

Ce que le catalogue n’est pas (et pourquoi c’est important de le savoir)

Le catalogue MCP de Hermes est un registre curé, pas un store audité. La différence est importante :

• Un registre curé vérifie que l’entrée est légitime, cohérente et documentée.
• Un store audité vérifierait que le code est sûr, que les dépendances sont scannées, et que le comportement à l’exécution est conforme à ce qui est annoncé.

Hermes ne prétend pas faire le deuxième. La doc est transparente : la revue porte sur le manifeste, pas sur le code du dépôt source.

C’est un choix d’architecture cohérent avec la philosophie de Hermes : te donner le contrôle, pas décider à ta place. Le catalogue te dit « cette entrée a été vérifiée comme légitime par Nous », pas « cette entrée est garantie sans risque ».

Trois vérifications rapides avant d’installer un MCP

Si tu veux une checklist simple à appliquer avant chaque installation :

1. Ouvre le dépôt source. Le lien est dans le manifeste, affiché dans le picker et sur le dashboard. Regarde l’activité récente, le nombre de contributeurs, la date du dernier commit.
2. Vérifie les dépendances. Les commandes de bootstrap sont listées dans le manifeste. Un pip install ou npm install va chercher des paquets. Est-ce que la liste est raisonnable ?
3. Décoche les outils inutiles. Pendant l’installation, Hermes te montre la liste complète des outils. Garde seulement ceux dont tu as vraiment besoin.

Ces trois vérifications prennent moins de deux minutes. Elles ne remplacent pas un audit, mais elles couvrent l’essentiel de ce que la revue catalogue ne couvre pas.

Le vrai risque n’est pas le catalogue, c’est l’installation aveugle

Le catalogue MCP de Hermes est bien conçu. Les entrées sont revues, désactivées par défaut, et tu choisis les outils que tu exposes. Le problème n’est pas l’outil, c’est l’usage : installer sans lire, activer sans filtrer, faire confiance sans vérifier.

La revue par Nous Research est un signal utile. Elle te dit que le manifeste est cohérent et que la source est identifiée. Elle ne te dit pas que le code est sûr, que les dépendances sont propres, ou que le dépôt n’a pas été modifié depuis la revue.

Ces vérifications-là sont les tiennes.

Si tu veux aller plus loin sur la sécurité de ton installation Hermes, j’ai écrit un article dédié sur la configuration de sécurité pour un usage en solo : sécuriser son installation Hermes quand on est solopreneur. Et si tu veux apprendre à configurer tes MCP proprement, la formation Hermes Agent couvre l’installation, le filtrage et les bonnes pratiques pour construire un système d’agents fiable.

Tu peux aussi faire une demande d’accès directement sur la page de la formation.