MCP stdio ou HTTP dans Hermes : choisir le transport selon le système déjà en place

Tu as un serveur MCP à connecter à Hermes. La doc te parle de deux transports : stdio et HTTP. Tu te demandes lequel choisir.

La réponse n’est pas une question de performance ou de préférence personnelle. Elle dépend d’un seul critère : où tourne le service que tu veux exposer.

Si le service est déjà sur la même machine qu’Hermes, tu prends stdio. S’il est déjà exposé en HTTP, tu prends HTTP. C’est le système en place qui dicte le transport, pas l’inverse.

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 fait MCP dans Hermes

MCP, c’est le protocole qui permet à Hermes de se raccorder à des serveurs d’outils externes. Un serveur MCP expose des outils, Hermes les découvre et les utilise comme s’ils étaient natifs.

Concrètement, quand tu ajoutes un serveur MCP dans ~/.hermes/config.yaml, Hermes se connecte au serveur, liste les outils disponibles, et les enregistre avec un préfixe mcp_<nom_serveur>_<nom_outil>. Tu n’as pas besoin d’appeler ces outils manuellement : Hermes les choisit pendant son raisonnement normal.

Deux types de connexion existent. Le choix entre les deux est plus simple qu’il n’y paraît.

Stdio : le serveur tourne en local

Un serveur stdio est un sous-processus lancé par Hermes sur la même machine. La communication passe par stdin/stdout, sans réseau.

Voici la config type pour un serveur filesystem local :

mcp_servers:
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projets"]

Hermes exécute la commande, maintient le processus en vie, et lui parle via les flux standard. Pas de port à ouvrir, pas d’URL à exposer, pas de certificat à gérer.

Quand utiliser stdio :

Le service est un outil en ligne de commande (npx, python, un binaire local).
Le service n’a pas besoin d’être partagé entre plusieurs instances Hermes.
Tu veux le setup le plus simple possible, sans couche réseau.
Les données manipulées restent sur la machine locale.

Un cas fréquent : tu as un script Python qui interroge ta base de données interne. Tu l’enveloppes dans un serveur MCP stdio, tu le déclares dans la config, et Hermes peut l’appeler directement. Le script ne quitte jamais la machine.

Côté limites : un serveur stdio ne peut pas être appelé depuis une autre machine. Si tu as plusieurs instances Hermes sur des serveurs différents, chacune doit lancer son propre processus. Et si le processus consomme beaucoup de mémoire, tu peux configurer un recyclage automatique avec idle_timeout_seconds ou max_lifetime_seconds.

HTTP : le serveur est déjà un endpoint

Un serveur HTTP MCP est un endpoint distant. Hermes s’y connecte comme à n’importe quelle API.

Config type :

mcp_servers:
  api_interne:
    url: "https://mcp.internal.example.com"
    headers:
      Authorization: "Bearer ***"

Pas de commande à lancer, pas de processus local. Hermes appelle l’URL, négocie la connexion, et utilise les outils exposés.

Quand utiliser HTTP :

Le service est déjà un endpoint HTTP (API interne, service managé, SaaS).
Le service doit être partagé entre plusieurs instances Hermes.
Le service tourne sur une machine différente, potentiellement dans un autre datacenter.
L’infrastructure réseau est déjà en place (DNS, certificats, pare-feu).

Un cas typique : ton entreprise a une API interne qui expose les données CRM. Cette API est déjà sécurisée, monitorée, et accessible via HTTPS. Tu la connectes en HTTP, et toutes les instances Hermes autorisées peuvent l’utiliser sans dupliquer le service.

Authentification : ce que chaque transport supporte

Le transport dicte aussi les options d’authentification disponibles.

En stdio, l’auth est implicite : le processus tourne sur la machine, avec les droits de l’utilisateur qui lance Hermes. Tu passes les tokens ou secrets via les variables d’environnement dans le bloc env :

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"

En HTTP, tu as trois mécanismes :

Bearer token statique : un header Authorization: "Bearer ***" dans la config.
OAuth 2.1 : pour les serveurs hébergés (Linear, Sentry, Atlassian). Tu mets auth: oauth et Hermes gère la découverte, le PKCE, l’échange de token et le refresh. Les tokens sont stockés dans ~/.hermes/mcp-tokens/<serveur>.json.
mTLS / certificats clients : pour les environnements qui exigent une authentification par certificat. Tu fournis le chemin du certificat dans client_cert.

Le choix d’auth est une conséquence du transport, pas un critère indépendant. Si ton service est en HTTP, tu utilises l’auth que le endpoint exige. Si ton service est en stdio, l’auth passe par l’environnement local.

Test : vérifier que la connexion fonctionne

Quel que soit le transport choisi, tu peux tester la connexion en deux étapes.

D’abord, vérifie que le serveur est bien listé. Lance hermes mcp pour voir le statut de chaque serveur configuré. Un serveur stdio apparaît avec sa commande, un serveur HTTP avec son URL.

Ensuite, demande à Hermes d’utiliser un outil du serveur. Par exemple, si tu as configuré un serveur filesystem, demande « Liste les fichiers dans /home/user/projets ». Si Hermes répond avec le contenu du dossier, la connexion fonctionne.

Pour les serveurs HTTP avec OAuth, lance hermes mcp login <nom_serveur> depuis un terminal séparé. Hermes ouvre le navigateur, tu autorises l’accès, et le token est stocké pour les appels suivants.

Si la connexion échoue, vérifie :

En stdio : la commande est-elle sur le PATH ? Les arguments sont-ils corrects ? Le processus a-t-il les droits nécessaires ?
En HTTP : l’URL est-elle accessible depuis la machine d’Hermes ? Le header d’auth est-il valide ? Le certificat est-il à jour ?

Comment décider en une minute

Voici le critère unique : regarde où tourne le service aujourd’hui.

Situation	Transport	Config type
Le service est un CLI ou un script local	stdio	command + args
Le service est déjà un endpoint HTTP	HTTP	url + headers
Le service doit être partagé entre plusieurs instances Hermes	HTTP	url + headers ou OAuth
Tu veux le setup le plus simple, sans réseau	stdio	command + args
Le service est un SaaS avec OAuth (Linear, Sentry, etc.)	HTTP	url + auth: oauth

Ce tableau n’est pas une checklist à cocher. C’est une correspondance directe entre ta situation et le transport. Tu n’as pas à choisir : le système déjà en place choisit pour toi.

Une précision importante : les deux transports ne sont pas mutuellement exclusifs dans ta config. Tu peux avoir trois serveurs stdio et deux serveurs HTTP dans le même mcp_servers. Hermes les gère côte à côte sans friction. La question « stdio ou HTTP » se pose par serveur, pas pour l’ensemble de ta configuration.

La limite honnête

stdio ne traverse pas le réseau. Si ton service doit être accessible depuis plusieurs machines, stdio n’est pas la solution, sauf à dupliquer le processus partout.

HTTP nécessite un endpoint accessible et de l’authentification. Si ton service n’est pas déjà exposé, tu dois le déployer, le sécuriser, et le maintenir. C’est du travail en plus par rapport à un simple processus local.

Aucun des deux transports n’est « meilleur » dans l’absolu. Le bon choix, c’est celui qui épouse l’infrastructure que tu as déjà.

Si tu veux comprendre l’architecture complète d’Hermes, comment les outils natifs et MCP s’articulent, et comment exposer tes propres services sans créer de faille de sécurité, la formation Hermes Agent couvre tout le cycle : de la première config au déploiement d’un système multi-agents. Tu peux faire une demande d’accès directement sur la page de la formation.

Trinity