No way to add web search or other third-party MCP servers to a desktop-managed agent

**Motivation**

A user asked whether Buzz agents can do web search — they get it automatically with Codex or Grok but have no clear path with a desktop-managed Buzz agent. The agent architecture supports it (ACP sessions accept multiple MCP servers, and the agent has a shell), but the desktop flow only ever passes one MCP server (`buzz-dev-mcp`), with no way to add a second. So the user has to choose between shell/file tools and any domain MCP — they cannot have both.

This is the same root gap described in #2899 and #4976, approached from the user-facing side. A concrete worked example (Tavily web search) makes the gap easier to evaluate.

**What works today (no code changes)**

The agent already has `shell`, so it can call any search REST API via `curl`. A skill (`.agents/skills/web-search/SKILL.md`) wrapping the [Tavily REST API](https://docs.tavily.com) gives the agent search, extract, crawl, and map commands using only `curl` and `jq` — no additional MCP server needed. The API key is stored in a local env file (`~/.buzz/.config/tavily.env`) or as a per-agent env var in the Desktop config. This is the practical workaround right now.

What this does **not** give you: structured MCP tool calls. The agent has to parse JSON from `curl` output rather than calling a typed `tavily_search` tool. It works, but it is more fragile and uses more context tokens than a native MCP integration.

**Proposed solution**

Let `build_mcp_servers()` in `crates/buzz-acp/src/lib.rs` accept additional MCP server definitions alongside the built-in `buzz-dev-mcp`. Three options, listed from smallest to most complete:

1. **Env var (smallest change).** Add `BUZZ_ACP_EXTRA_MCP_COMMANDS` — a comma-separated list of additional MCP commands. `build_mcp_servers()` appends each as a separate `McpServer` entry. Defaults unchanged: a single value behaves exactly as today. This matches how `BUZZ_ACP_AGENT_ARGS` already works one line above.

2. **Config file.** Let `buzz-acp` read a JSON/TOML file (e.g. `~/.buzz/mcp-servers.json`) listing additional MCP server definitions with command, args, and env. The desktop could eventually generate this from the UI.

3. **Desktop UI.** A per-agent "Additional MCP servers" panel in the Desktop agent config that stores definitions and passes them through to `buzz-acp` at spawn time. This is the most user-friendly but the largest change.

The Tavily MCP server works as a concrete test case. It initializes cleanly via `npx -y mcp-remote https://mcp.tavily.com/mcp/?tavilyApiKey=...` and exposes five tools (`tavily_search`, `tavily_extract`, `tavily_crawl`, `tavily_map`, `tavily_research`). The protocol layer is not the blocker — the plumbing is.

**Alternatives considered**

- **Shell + curl skill (current workaround).** Works today, no code changes, but the agent parses raw JSON instead of calling typed tools. Higher token cost and more fragile.
- **Provider-native web search (#4914).** Let `buzz-agent` expose Anthropic/OpenRouter hosted search tools. Solves web search specifically but not the general multi-MCP gap. Complementary, not a substitute.
- **`.mcp.json` discovery (#4852).** Let agents read `.mcp.json` from the working directory. Another valid path that does not require desktop UI changes.

**Related issues**

- #2899 — core "one MCP server per agent" limitation (3 comments, open)
- #4976 — desktop ignores configured `mcp_command` for managed agents
- #4852 — `.mcp.json` servers not visible to agent sessions
- #4550 — no per-agent MCP injection for preset/custom ACP runtimes
- #4515 — docs request for connecting external MCP servers
- #4914 — provider-native web search tools

Searched open issues first: the above are the closest matches. This issue adds the user-facing web-search use case and a concrete worked example to the existing discussion.

Start in crates/buzz-acp/src/lib.rs at build_mcp_servers() and compare its current handling of the built-in buzz-dev-mcp with BUZZ_ACP_AGENT_ARGS. Review the related issues and the three proposed configuration approaches before choosing a scope. Done means desktop-managed agents can retain the built-in server while also receiving additional MCP servers, with the Tavily MCP server as the concrete test case.

Written by the indexing model from the issue text.