The wall
Our marketing runs as a Buzz agent named Gary V, in a channel, in our own hive. When we gave Gary posting duty, we handed him an MCP server the way you would hand it to any Claude Code session: put it in user config, restart, done. Twenty interactive sessions on this machine inherit that config on restart. Gary never saw it.
Here is the model, once you stop fighting it. Buzz Desktop spawns each agent through an ACP harness, and the harness launches the runtime as an embedded engine with host-supplied configuration: the agent's system prompt, model and provider come from the agent record, not your dotfiles. Same binary as your terminal sessions, different contract. An Electron app runs Chromium on your Mac, but it does not get your Chrome extensions, cookies, or logins. Engine, not session.
Why the wall is right
Your user-scope MCP config is not neutral plumbing. Ours holds billing tools that can issue refunds, an admin console, an analytics stack, a browser. There are thirteen managed agents on this machine. If agents inherited the owner's config, every one of them would wake up holding the whole keyring.
The default should be zero, and in Buzz it is: the harness has a per-agent hook, mcp_command, and it defaults to empty. Capabilities are granted, not inherited. We charge money for exactly this philosophy applied to servers, so we can hardly complain when our own tools apply it to us.
The two traps
First trap: the hook has no UI yet. You set mcp_command by editing managed-agents.json in Buzz Desktop's application-support directory, per agent.
Second trap, the expensive one: Buzz Desktop reads config at app startup and spawns agents from memory. Restarting the agent changes nothing. Quit the desktop app fully, edit the file, relaunch.
Then verify from outside the agent, with ps, that the environment you think you injected actually arrived. Never architect on an agent's report of its own environment; we did, and it steered us wrong for an evening.
The bridge
mcp_command wants one command that speaks stdio MCP. So we wrote one. buzz-mcp-bridge reads the MCP servers you already manage in Claude Desktop and Claude Code user scope, connects to the ones you explicitly allow for this agent, and re-exposes their tools as a single stdio server, namespaced the way Claude Code already names them.
The allowlist is required. No allowlist, no startup. Gary's wrapper is one line: allow the social posting server. He gets 35 posting tools and nothing else from our keyring. Another agent could get the analytics stack and nothing else. One bridge per agent, each with its own grant.
Apache-2.0, at github.com/hachiflow/buzz-mcp-bridge, small enough to read in one sitting. If you run Buzz agents and want them using the MCP servers you already have, it is the missing plumbing.
The receipts
The first thing that traveled the finished pipeline was a piece of arithmetic about seat pricing, drafted by Gary in our hive, approved from a phone, published through an API. No browser anywhere. The post is small; the machine that posted it is the product working as designed, and now the plumbing is yours too.