Le Model Context Protocol (MCP) est la taille étroite entre votre passerelle OpenClaw et les outils qui touchent réellement disque, shell et API. En 2026, beaucoup d'équipes hésitent encore entre le transport stdio (processus enfant longue durée avec tuyaux) et le transport Streamable HTTP (sessions HTTP étatful pouvant traverser plusieurs machines). Les modes d'échec diffèrent : le stdio se manifeste souvent par un stdin bloqué ou une EOF lorsque l'enfant se termine ; le HTTP par des blocages façon 408/504 lorsque les intermédiaires ou les délais client ne s'alignent pas sur le budget outil côté serveur. Cette note propose un modèle mental reproductible, un drill de timeout collable dans un runbook et une liste de contrôle ENOENT calquée sur ce que l'on voit sur des workers macOS distants.
Pour un pont Linux, systemd, WSL2 et la migration HTTP avec les mêmes classes d'erreurs, enchaînez avec OpenClaw 2026 sur Linux (systemd), WSL2, MCP Streamable HTTP et ENOENT — flux Mac distant élastique.
1. stdio contre Streamable HTTP : ce qui change en production
Le stdio convient lorsque le serveur MCP est colocalisé avec la passerelle : fork/exec, pas de TLS au milieu, annulation par fermeture du tuyau. Le prix est un couplage opérationnel (session utilisateur, PATH, cwd) — d'où les shims shell qui figent HOME ou font un cd vers le dépôt. Le Streamable HTTP sert lorsque le serveur est sur un autre hôte, derrière un ingress, ou pour scaler et isoler les sondes de santé. Vous payez des doubles timeouts (client, proxy, serveur) et du tamponnage possible sur gros flux. L'authentification devient explicite (jetons, mTLS) alors que le stdio hérite implicitement de l'identité OS — négliger la surface HTTP expose souvent des points MCP internes.
2. Drill reproductible sur les délais d'outils
Choisissez un outil volontairement lent et exécutez-le via les deux transports. Notez échéance client, budget passerelle et timeout serveur MCP ; réduisez volontairement la couche du milieu pour obtenir un échec déterministe avec identifiant de requête, puis élargissez seulement la couche fautive. Rejouez après chaque changement de proxy ou d'image. Pour le HTTP, testez avec le chunked streaming désactivé sur le proxy — beaucoup de « mystères » sont du tamponnage. Pour le stdio, vérifiez SIGTERM en fin de session et l'absence de processus orphelins qui épuisent les descripteurs. Si le client supporte des résultats partiels, notez si le timeout arrive avant ou après le premier fragment d'outil.
Rejouez le drill derrière chaque profil d'équilibreur (idle TCP, lecture du corps, WAF) : les délais mesurés en direct vers le pod diffèrent souvent de la production.
3. ENOENT : cinq contrôles qui closent la plupart des tickets
ENOENT signifie rarement « MCP est cassé » ; le chemin ou l'exécutable n'existe pas depuis le compte qui a lancé le serveur. Vérifiez : (1) chemin absolu ou relatif au cwd du service ; (2) PATH launchd versus shell interactif ; (3) chemins conteneur versus chemins natifs sur Mac distant ; (4) casse sur volumes partagés ; (5) binaire Rosetta attendu sur une pile arm64-only. Journalisez une fois argv et getcwd() à l'invocation. Sous launchd, étiquettes dupliquées et plists obsolètes produisent la même famille de symptômes ; croisez avec
2026 — Manuel de stabilité launchd pour la passerelle OpenClaw : triade doctor/status/journaux, ports occupés et conflits de doubles LaunchAgent — procédures reproductibles sur Mac distant toujours allumé.
4. Fiche de choix du transport
Avant de modifier le code, répondez sur papier à quatre questions : le serveur MCP doit-il survivre indépendamment aux redémarrages de passerelle ? Le trafic traverse-t-il un proxy d'entreprise qui met en tampon le SSE ? Les outils lancent-ils GUI ou AppleScript exigeant une session Aqua ? Acceptez-vous d'épingler un seul utilisateur OS pour le stdio, ou avez-vous besoin d'une auth par jeton au bord HTTP ? Si les deux semblent viables, restez en stdio jusqu'à avoir une raison concrète de payer la taxe des systèmes distribués.
5. Checklist terrain pour l'astreinte
- Noter les trois délais (client, passerelle, serveur) pour l'identifiant de trace en échec.
- En HTTP, confirmer le chunked encoding de bout en bout et désactiver le tamponnage de réponse sur le saut le plus proche du client.
- En stdio, confirmer que le stderr de l'enfant est dupliqué vers un journal durable — les plantages silencieux imitent des timeouts.
- Sur
ENOENT, journaliser argv, cwd, uid et comparer à un shell interactif connu bon sur le même hôte. - Après correctifs, relancer le drill outil lent pour que l'incident suivant compare des pommes à des pommes.
Pourquoi un Mac mini Apple Silicon silencieux reste pertinent pour les passerelles MCP
Les passerelles qui ventilent des outils MCP sont sensibles à la latence et aux E/S plus qu'à un concours de CPU brut. Un Mac mini sur Apple Silicon associe NVMe local rapide à un comportement thermique prévisible pour des démons toujours actifs, tandis que macOS offre une pile unique pour launchd, le codesigning et la boîte à outils développeur. Gatekeeper, SIP et FileVault donnent aussi un récit plus simple aux revues sécurité qu'un durcissement Linux ad hoc sur mesure.
Si vous consolidez passerelles et charges Xcode sur un même socle, le Mac mini M4 reste un bon compromis : faible consommation au repos, silence de bureau et mémoire unifiée suffisante pour plusieurs serveurs stdio. Pour du Mac cloud dédié sans long cycle d'achat, ouvrez la page d'accueil Macstripe pour aligner région et bande passante avec votre charge MCP. Si vous voulez exécuter ce tutoriel sur le matériel le plus fluide pour démarrer, le Mac mini M4 est aujourd'hui l'un des points d'entrée les plus équilibrés pour un nœud passerelle silencieux.
