buzz-acp: one MCP server per agent forces a choice between the shell and any domain server

[ArgussLabs]

Summary

buzz-acp accepts a single MCP binary (--mcp-command / BUZZ_ACP_MCP_COMMAND), so an agent gets exactly one MCP server. Because a Buzz agent acts in Buzz by shelling out to the buzz CLI — and that shell tool comes from buzz-dev-mcp — the single slot is an either/or rather than a preference:

• slot = buzz-dev-mcp → the agent can post, but has no domain tools
• slot = a domain MCP server → the agent has domain tools, but no way to post

Reproduction

Run buzz-acp with BUZZ_ACP_MCP_COMMAND pointing at any external stdio MCP server (--agent-command buzz-agent), add the agent to a channel, and ask it something its domain server can answer.

Actual behavior

The agent answers internally and never posts. In my run it was offered 61 tools — 60 from the domain server plus load_skill — and zero shell or buzz tools. default_heartbeat_prompt (and the reply guidance around crates/buzz-acp/src/lib.rs:3621) instructs the agent to run buzz messages send --reply-to <event-id>, which it has no tool to do.

Expected behavior

An operator can give an agent buzz-dev-mcp and their own MCP server(s) at once.

Notes

PersonaConfig.mcp_servers is already a Vec<McpServerConfig>, and buzz-persona parses, merges (merge_mcp_servers), and validates it — buzz pack describe even prints the count. It is simply never plumbed to the runtime, which uses one mcp_command per agent record. So the multi-server intent seems to already be there in the persona layer.

The narrowest fix is at the harness: make --mcp-command repeatable and the env var comma-separated, matching the agent_args field directly above it in Args. Defaults unchanged; a single value behaves exactly as today. Happy to be redirected if you would rather solve this at the persona/runtime layer instead.

I have that change working with tests and will open a PR referencing this issue.

Searched open issues/PRs first: nothing found for multiple MCP servers. Closest adjacent ones are #2883 (keeping BUZZ_PRIVATE_KEY out of agent-controlled processes) and #2368 (adding an ACP runtime), neither overlapping.

Environment: block/buzz @ c0d7b52, macOS, buzz-agent runtime.

[wolfyy970]

I found two related paths:

• build_mcp_servers returns zero or one server, although session_new_full accepts Vec<McpServer>.
• Desktop derives the companion MCP only from KNOWN_ACP_RUNTIMES. Preset harnesses such as omp and hermes-acp therefore receive an empty BUZZ_ACP_MCP_COMMAND. [Bug] Custom/BYOH ACP harness receives no authenticated Buzz reply tool, so completed turns cannot post #3385 confirms the Hermes reply failure.

PR #1785 implemented structured configuration and layering, but was limited to buzz-agent and closed for inactivity. My analytics MCP also needs arguments and environment variables, so repeatable command strings alone would not cover it.

Would maintainers prefer a small harness PR that accepts a structured server list and passes it through ACP, followed by a separate Desktop configuration PR based on #1785?

[MohsinHashmi-DataInn]

Confirming this from the Buzz Desktop side, and adding a case that I think is narrower than the one described — in case it's useful when shaping the fix.

Your diagnosis matches exactly what I hit building a pack for a remote MCP server: buzz pack inspect cheerfully reports MCP servers: 1 while the agent receives none. The persona layer parses, merges and validates; nothing downstream reads it.

Through Desktop with the claude runtime there is no slot at all — not one.

Against 63496cc1:

• desktop/src-tauri/src/managed_agents/runtime.rs:527-529 derives the value from the runtime registry constant, never from the agent record:

  let effective_mcp_command = known_acp_runtime(effective_command)
      .and_then(|r| r.mcp_command)
      .unwrap_or("");

• desktop/src-tauri/src/managed_agents/discovery.rs:113 — the claude entry is hard-coded mcp_command: None, where codex gets Some("buzz-dev-mcp").

• desktop/src-tauri/src/managed_agents/env_vars.rs:73 — BUZZ_ACP_MCP_COMMAND is in RESERVED_ENV_KEYS, so the Edit-agent Environment variables field can't supply it either. That looks deliberate (code-execution surface) and I'm not suggesting it change.

Empirically: setting mcp_command on the agent record in managed-agents.json and restarting leaves the spawned harness with BUZZ_ACP_MCP_COMMAND= empty, and build_mcp_servers() returns vec![].

So making --mcp-command repeatable would fix the either/or for runtimes that already have a slot — buzz-agent, codex — but a Desktop user on the claude runtime would go from zero to zero. Worth knowing before the harness-level fix is called done.

That's an argument for the persona/runtime option you offered as the alternative: plumbing PersonaConfig.mcp_servers through would cover both cases at once, since the parsing and merging already exist. The harness change would still be worth having on its own — it just wouldn't close this particular gap.

Happy to file the Claude-runtime piece as its own issue if you'd rather keep this one focused on the harness. Context: I was attaching a remote Streamable HTTP MCP server to a Desktop agent, which also needs an stdio bridge since McpServerConfig carries no url/transport — but that's a separate matter and I don't want to widen this thread.