Vous faites déjà tourner OpenClaw Gateway ; l’étape suivante est souvent d’intégrer des outils Model Context Protocol (MCP) dans le flux de l’agent : parcourir des dépôts, appeler des API internes, exécuter des commandes contrôlées. Les frictions réelles se concentrent sur trois familles — découverte des outils et dérive de version, liste blanche côté Gateway et moindre privilège, et en production les cas échec de handshake, timeout, sous-processus bloqué. Cet article précise le partage des rôles avec nos textes installation, durcissement, modelRouting et observabilité, propose un tableau stdio vs MCP distant, une checklist de mise en ligne en six étapes et un tableau de symptômes pour traiter MCP comme une chaîne d’outils auditable, et non comme un greffon provisoire.
MCP élève l’appel d’outil au-dessus du script ponctuel : chaque outil ajoute un chemin de données et un cycle de vie de sous-processus. Si l’on avance comme pour un « ça marche en local », la Gateway subit vite explosion de l’énumération, mises à jour implicites, absence de timeout, absence de liste blanche. Les sept points suivants servent de grille en revue ; évitez de recopier une config de démo en production.
Lorsque trois réponses ou plus sont « oui », traitez MCP comme une supply chain gouvernée : enregistrement explicite, versions épinglées, observabilité et rollback — pas comme un brouillon dans openclaw.json.
L’inventaire d’outils dérive-t-il à chaque redémarrage : si le nombre et les noms changent sans contrôle, la découverte n’est pas versionnée ni ancrée dans un répertoire de travail — le diagnostic devient « qu’est-ce qui a été énuméré aujourd’hui ».
Manque-t-on de liste blanche explicite : tout ouvert par défaut va vite en démo et mal en prod : tout prompt peut se mapper sur une capacité système arbitraire ; croisez avec dmPolicy et la politique d’approbation d’exécution.
Les sous-processus stdio ont-ils un timeout dur : une attente illimitée sature files et files d’attente Gateway quand un MCP se fige — le modèle répond encore mais l’outil ne revient jamais.
Le MCP distant contourne-t-il la politique de sortie : HTTP/SSE hors champ networkPolicy ouvre une nouvelle sortie derrière la Gateway et contredit l’hypothèse de l’article sécurité.
Les secrets passent-ils par un environnement global : des jetons dans l’environnement partagé par tous les outils multiplient l’impact d’une fuite ; segmentez la configuration et prévoyez la rotation.
Y a-t-il conflit avec modelRouting : gros contexte sur un modèle coûteux, petites tâches sur un modèle léger — les échecs d’outil et les nouvelles tentatives peuvent se répéter sur plusieurs modèles ; limitez en concert routage et couche outil.
L’observabilité ne regarde-t-elle que la Gateway : sans paramètres de lancement et code de sortie des sous-processus MCP, l’exploitation se résume à « on redémarre » — alignez-vous sur les champs de journaux de l’article observabilité.
En résumé : brancher MCP = resserrer en parallèle configuration, processus, réseau et permissions. Le tableau suivant fige stdio contre MCP distant, puis la checklist en six étapes.
Division des rôles avec le blog : les guides d’installation et systemd/Docker couvrent « comment la Gateway reste un service » ; le durcissement couvre « qui se connecte et où elle sort » ; modelRouting couvre « découpage des modèles et coût » ; ce texte couvre « d’où viennent les outils, comment on les autorise et comment on dépanne » — ensemble, cela forme une topologie de production auditable.
Ce tableau sert à la revue d’architecture : le même besoin métier peut souvent se faire des deux côtés, mais le modèle de menace et les modes de panne diffèrent ; ne choisissez pas seulement « le moins verbeux en config ».
| Dimension | stdio (sous-processus local) | MCP distant (HTTP/SSE, etc.) |
|---|---|---|
| Frontière processus | Même utilisateur et même hôte que la Gateway ; hérite des variables d’environnement et des droits fichiers | Autre machine ; TLS, authentification et sondes de santé à gérer séparément |
| Exposition réseau | Pas d’écoute supplémentaire par défaut ; risque d’injection de commande et de chemin | Nouveaux points de terminaison et dépendances sortantes ; à inscrire dans networkPolicy |
| Mise à niveau et reproductibilité | Dépend des binaires locaux et du gestionnaire de paquets ; épingler versions et empreintes | Publication centralisée possible ; gérer déploiements progressifs et matrice de compatibilité |
| Pannes typiques | PATH, droits, interpréteur : sortie immédiate au démarrage | DNS, TLS, timeouts reverse-proxy et chaîne 401/403 |
| Leviers d’observabilité | PID, code de sortie, extrait stderr | Statut HTTP, courbe de retry, quantiles de latence de bout en bout |
MCP n’est pas « un plugin de plus » mais une supply chain exécutable supplémentaire ; choisir stdio ou distant, c’est décider de placer le risque sur la frontière machine ou sur la frontière réseau.
Lorsque des builds lourds ou une chaîne réservée à macOS vivent sur un plan d’exécution distant, la topologie courante est : Gateway sur Linux/VPS, Mac distant dédié pour xcodebuild et la signature, retour des journaux et artefacts par canal contrôlé. MCP doit plutôt exposer une couche d’orchestration légère que des tâches longues dans le même processus ; CPU et disque restent sur des nœuds contractuels.
Exécutez dans l’ordre : l’objectif est de passer de « l’outil fonctionne » à « la modification est auditable, l’échec est localisable, le retour arrière est tracé ».
Identité d’outil : nom stable, provenance de version (paquet, commit, digest) et propriétaire ; pas de script anonyme qui dérive avec le dépôt.
Paramètres de lancement au moindre privilège : stdio avec chemins absolus et répertoire de travail dédié ; MCP distant avec TLS explicite, timeouts et plafond de tentatives, sans proxy système implicite.
Validation de configuration : après changement, openclaw config:validate puis openclaw doctor ; les erreurs deviennent critère de fusion.
Alignement liste blanche : croisez l’ensemble d’outils autorisés avec dmPolicy et l’approbation d’exécution pour éviter « désactivé en config mais le modèle devine encore un chemin ».
Canal progressif : activez d’abord le nouvel outil sur un faible trafic, gardez l’ancien une semaine en parallèle ; enregistrez taux d’échec, latence P95 et redémarrages de sous-processus.
Kit de rollback : sauvegardez la précédente openclaw.json et le digest d’image ; en incident, revenez d’abord à config et image, puis isolez l’outil.
{
"mcpServers": {
"internal-git": {
"command": "/opt/mcp/git-mcp",
"args": ["--config", "/etc/mcp/git.prod.json"],
"env": { "MCP_LOG_LEVEL": "info" }
}
}
}
Rappel : ce fragment illustre la structure ; les noms de clés et l’imbrication exacte suivent la documentation de votre version OpenClaw. Avant une montée de version majeure, rejouez la même paire validate/doctor sur le cluster de préproduction.
Le durcissement insiste sur l’écoute, les jetons, dmPolicy et networkPolicy ; avec MCP, l’appel d’outil est un nouvel exutoire d’exécution — placez l’ensemble d’outils autorisés et les cibles aval autorisées sur la même grille de revue. En pratique, par famille d’outils : concurrence max, timeout par appel, budget journalier et stratégie de disjoncteur après échec.
Quand le modèle « appelle un outil » mais que l’interface reste en chargement, vérifiez d’abord trois causes : sous-processus non démarré (chemin, droits), handshake incomplet (version de protocole, auth), blocage aval (réseau ou API métier). Sans code de sortie ni stderr, ne redémarrez pas la Gateway en boucle : vous transformez une panne intermittente en incident prolongé.
Avec l’observabilité, corrélez démarrage et destruction MCP au même identifiant de journal pour enchaîner « requête modèle → appel outil → sortie sous-processus ».
Attention : ne laissez pas des journaux « énumération d’outils en mode debug » en production sans masquage ; les paramètres contiennent souvent chemins de dépôt, noms d’hôtes internes et fragments de jetons.
Ces entrées servent aux astreintes et aux post-mortems ; complétez avec vos propres SLO et métriques.
Empiler MCP sur un portable sans gouvernance Gateway ni plan d’exécution stable se heurte vite au sommeil, au disque et aux sessions partagées ; charger la Gateway de tâches lourdes élargit aussi le rayon d’explosion. Pour une chaîne d’outils auditable, disque fiable et capacité 7×7, une combinaison réaliste est : OpenClaw Gateway pour session et politiques, nœud Mac distant dédié pour builds iOS/macOS et tâches longues, MCP comme interface étroite. Pour la gouvernance des outils et le coût de la capacité, la location cloud de Mac Mini NodeMini convient comme socle d’exécution : découpler l’orchestration MCP sur la Gateway des builds et de la signature sur le Mac cloud, tout en appliquant la checklist versions, liste blanche et timeouts de cet article.
Commencez par openclaw config:validate, puis openclaw doctor ; pour corriger des clés invalides connues, doctor --fix avec prudence et trace dans le changement. Pour la connectivité et les commandes liées au cloud Mac, voir le centre d’aide cloud Mac.
stdio pour même machine et frontière nette ; HTTP/SSE pour multi-hôtes avec TLS, auth et networkPolicy. Croisez avec la catégorie OpenClaw (notamment l’article sécurité), pas avec une décision isolée.
La Gateway garde dialogue et politique d’outils ; la charge lourde va sur un Mac distant dédié. Parcourez la rubrique OpenClaw, les tarifs de location Mac mini et le centre d’aide pour séparer orchestration MCP et nœud d’exécution.