壁
私たちのマーケティングは、自分たちのハイブのチャンネルにいる Gary V という Buzz エージェントが担っています。Gary に投稿の仕事を任せるとき、私たちは Claude Code のセッションに渡すのと同じやり方で MCP サーバーを渡しました。ユーザー設定に書いて、再起動して、終わり。このマシン上の 20 の対話型セッションは、再起動でその設定を引き継ぎます。Gary には一度も見えませんでした。
抗うのをやめてみると、モデルはこうです。Buzz Desktop は各エージェントを ACP ハーネス経由で起動し、ハーネスはランタイムを、ホストが設定を供給する組み込みエンジンとして立ち上げます。エージェントのシステムプロンプト、モデル、プロバイダーは、あなたのドットファイルではなくエージェントのレコードから来ます。ターミナルのセッションと同じバイナリでも、契約が違うのです。Electron アプリは Mac 上で Chromium を動かしますが、あなたの Chrome 拡張機能も Cookie もログイン状態も受け取りません。セッションではなく、エンジンです。
壁が正しい理由
ユーザースコープの MCP 設定は中立な配管ではありません。私たちの設定には、返金を発行できる課金ツール、管理コンソール、分析基盤、ブラウザが入っています。このマシンには 13 のマネージドエージェントがいます。もしエージェントがオーナーの設定を継承したら、全員が目覚めた瞬間に鍵束をまるごと握っていることになります。
既定はゼロであるべきで、Buzz では実際にそうなっています。ハーネスにはエージェントごとのフック mcp_command があり、既定値は空です。能力は継承されるのではなく、付与されるものです。私たちはまさにこの考え方をサーバーに適用することでお金をいただいているので、自分たちのツールが同じ考え方を私たちに適用しても、文句は言えません。
2 つの罠
1 つ目の罠。このフックにはまだ UI がありません。mcp_command は、Buzz Desktop のアプリケーションサポートディレクトリにある managed-agents.json を、エージェントごとに編集して設定します。
2 つ目の罠は、高くつくほうです。Buzz Desktop は設定をアプリの起動時に読み込み、メモリ上の設定からエージェントを起動します。エージェントを再起動しても何も変わりません。デスクトップアプリを完全に終了し、ファイルを編集してから、起動し直してください。
そのうえで、注入したつもりの環境が本当に届いているかを、エージェントの外から ps で確認してください。エージェントが自分の環境について語る報告を前提に設計してはいけません。私たちはそれをやって、ひと晩分、間違った方向に進みました。
橋
mcp_command が求めるのは、stdio で MCP を話すコマンド 1 つです。そこで、それを書きました。buzz-mcp-bridge は、Claude Desktop と Claude Code のユーザースコープですでに管理している MCP サーバーを読み取り、そのエージェントに明示的に許可したものだけに接続し、それらのツールを 1 つの stdio サーバーとして公開し直します。名前空間は、Claude Code がすでに使っている命名に合わせています。
許可リストは必須です。許可リストがなければ起動しません。Gary のラッパーは 1 行で、SNS 投稿用のサーバーを許可するだけです。Gary が手にするのは 35 個の投稿ツールで、私たちの鍵束からはそれ以外に何も受け取りません。別のエージェントなら、分析基盤だけを受け取ることもできます。エージェントごとに橋を 1 つ、それぞれに固有の付与を。
ライセンスは Apache-2.0 で、github.com/hachiflow/buzz-mcp-bridge で公開しています。一度に読み通せる小ささです。Buzz のエージェントを動かしていて、手持ちの MCP サーバーを使わせたいなら、これが欠けていた配管です。
その証拠
完成したパイプラインを最初に通ったのは、席単位の料金についてのちょっとした計算の話でした。Gary が私たちのハイブで下書きし、スマートフォンから承認され、API 経由で公開されました。ブラウザはどこにも登場しません。投稿自体は小さなものです。それを投稿した仕組みこそが、設計どおりに動いているプロダクトであり、その配管はいま、あなたのものでもあります。