Le mur
Notre marketing tourne sous la forme d'un agent Buzz nommé Gary V, dans un canal, dans notre propre ruche. Quand nous avons confié la publication à Gary, nous lui avons fourni un serveur MCP comme on le ferait pour n'importe quelle session Claude Code : on le met dans la config utilisateur, on redémarre, c'est fait. Vingt sessions interactives sur cette machine héritent de cette config au redémarrage. Gary ne l'a jamais vue.
Voici le modèle, une fois qu'on cesse de lutter contre lui. Buzz Desktop lance chaque agent via un harness ACP, et le harness lance le runtime comme un moteur embarqué, avec une configuration fournie par l'hôte : le prompt système, le modèle et le fournisseur de l'agent viennent de la fiche de l'agent, pas de vos dotfiles. Même binaire que vos sessions de terminal, contrat différent. Une app Electron fait tourner Chromium sur votre Mac, mais elle ne reçoit ni vos extensions Chrome, ni vos cookies, ni vos connexions. Un moteur, pas une session.
Pourquoi le mur a raison
Votre config MCP utilisateur n'est pas de la plomberie neutre. La nôtre contient des outils de facturation capables d'émettre des remboursements, une console d'administration, une pile d'analytics, un navigateur. Treize agents gérés tournent sur cette machine. Si les agents héritaient de la config du propriétaire, chacun d'eux se réveillerait avec le trousseau entier en main.
Le défaut devrait être zéro, et dans Buzz il l'est : le harness a un hook par agent, mcp_command, vide par défaut. Les capacités s'accordent, elles ne s'héritent pas. Nous faisons payer exactement cette philosophie appliquée aux serveurs, nous pouvons donc difficilement nous plaindre quand nos propres outils nous l'appliquent.
Les deux pièges
Premier piège : le hook n'a pas encore d'interface. Vous définissez mcp_command en éditant managed-agents.json dans le répertoire application-support de Buzz Desktop, agent par agent.
Second piège, le plus coûteux : Buzz Desktop lit la config au démarrage de l'app et lance les agents depuis la mémoire. Redémarrer l'agent ne change rien. Quittez complètement l'app de bureau, éditez le fichier, relancez.
Vérifiez ensuite depuis l'extérieur de l'agent, avec ps, que l'environnement que vous pensez avoir injecté est bien arrivé. Ne bâtissez jamais une architecture sur ce qu'un agent rapporte de son propre environnement ; nous l'avons fait, et cela nous a égarés toute une soirée.
Le pont
mcp_command attend une seule commande qui parle MCP en stdio. Nous en avons donc écrit une. buzz-mcp-bridge lit les serveurs MCP que vous gérez déjà dans Claude Desktop et dans la portée utilisateur de Claude Code, se connecte à ceux que vous autorisez explicitement pour cet agent, et réexpose leurs outils comme un seul serveur stdio, avec les espaces de noms que Claude Code utilise déjà.
La liste d'autorisation est obligatoire. Pas de liste, pas de démarrage. Le wrapper de Gary tient en une ligne : autoriser le serveur de publication sur les réseaux sociaux. Il obtient 35 outils de publication et rien d'autre de notre trousseau. Un autre agent pourrait obtenir la pile d'analytics et rien d'autre. Un pont par agent, chacun avec son propre droit.
Sous licence Apache-2.0, sur github.com/hachiflow/buzz-mcp-bridge, assez petit pour se lire d'une traite. Si vous faites tourner des agents Buzz et voulez qu'ils utilisent les serveurs MCP que vous avez déjà, c'est la plomberie qui manquait.
Les preuves
La première chose à traverser le pipeline terminé a été un petit calcul sur la tarification au siège, rédigé par Gary dans notre ruche, approuvé depuis un téléphone, publié via une API. Aucun navigateur nulle part. Le post est modeste ; la machine qui l'a publié, c'est le produit qui fonctionne comme prévu, et désormais la plomberie est à vous aussi.