Protocol support
BMO supports several client and server protocols for editor and agent integration.
Summary
Section titled “Summary”| Protocol | Role | Entrypoint | Doc link |
|---|---|---|---|
| MCP client | Connect to MCP servers | cfg.MCP, cfg.Extensions in config | MCP Client |
| MCP server | Expose BMO tools | bmo serve-mcp | MCP Server |
| ACP server | Zed Agent Client Protocol | bmo acp | Zed |
| A2A | Client and server | invoke_a2a tool; bmo serve with A2A enabled | A2A |
Three planes (do not conflate)
Section titled “Three planes (do not conflate)”BMO uses three integration planes. Each has a different job; mixing them causes confused routing or missing editor updates.
| Plane | Role | BMO entry | Not this |
|---|---|---|---|
| MCP | Tool and resource access to external servers | [mcp.*], bmo serve-mcp | Remote agent task execution |
| A2A | Agent-to-agent Task execution (AgentCard, task_id, lifecycle) | invoke_a2a, bmo serve + [options.a2a] | Editor session streaming |
| ACP | Editor client ↔ BMO session UX | bmo acp | Mesh discovery or A2A routing |
Mesh is not a fourth protocol: it is discovery and routing before A2A. mesh_resolve lists candidates; invoke_a2a awards and runs the remote task. Editor session/update (ACP) may mirror handoff visibility after invoke_a2a; it does not route mesh or A2A.
Live vs durable vs aggregate task views
Section titled “Live vs durable vs aggregate task views”| View | Question it answers | Inspect |
|---|---|---|
| Task execution bus (in-process) | What agent work is running in this process now? | bmo config show-task-execution, TUI /task-bus, GET /v1/task-execution, MCP bmo_get_task_execution_snapshot |
| Agent runs ledger (durable) | What runs happened and what state are they in? | agent_runs APIs, run history UI |
| Task aggregate read model (composed) | What task-shaped work exists across workstreams/teams/A2A? | GET /v1/task-aggregate, get_task_aggregate |
The execution bus is process-scoped memory only; it does not replace durable run history or the unified aggregate read model. See Task execution bus.
Maintainer routing map: multi-agent orchestration surface. Canonical client/server role matrix (includes LSP live analyzer and substrate readout): protocol role clarity. Monorepo handoff-plane detail: docs/meta-design/a2a-mesh-handoff-plane.md in an agent-cli parent checkout when present.
MCP client: two config surfaces
Section titled “MCP client: two config surfaces”External MCP servers can be configured in two ways:
- [mcp.*] — Full MCP: tools, prompts, and resources. Transports: stdio, SSE, HTTP. Use when you need prompts or resources from the server. You can also set
tools_only = trueon a[mcp.*]block for the same tools-only (circuit-breaker) path that legacy[extensions.*]used — preferred for new config. - [extensions.*] — Legacy tools-only spelling; still supported. To migrate, run
bmo config suggest-mcp-migration(prints suggested[mcp.*]TOML withtools_only) and remove[extensions.*]when satisfied.
See MCP Client and MCP Server for configuration and usage.
One list, two spellings (MCP clients)
Section titled “One list, two spellings (MCP clients)”BMO’s internal read model (connectionview in the codebase) treats “external tool servers” as a single list. Each entry is either full MCP (from [mcp.*], tools + prompts + resources) or tools only (from [extensions.*], with the circuit-breaker client). The list is tagged mode (full vs tools) so you do not have to map rows back to TOML section names by memory.
Interactive TUI (visibility and reconnect)
Section titled “Interactive TUI (visibility and reconnect)”In the full-screen chat TUI, the same unified list is available as:
- Session → Protocols — opens the Protocols & integrations dialog: scrollable rows, read-only HTTP/ACP policy lines from config, and r / Enter to reconnect a selected full
[mcp.*]client or start extension tools-only reconnect when the coordinator is wired. - Slash:
/protocols,/integrations, and/mcpopen that dialog. - Sidebar (bottom) — Integrations — compact view of the same rows (and live tool/prompt counts for connected full-MCP clients when the runtime has published them). Visible integration rows are clickable shortcuts into the same dialog, focused on that row.
options.openai_compat and options.mcp_server stay separate from the MCP client lists; the dialog and sidebar summarize them, while reconnect/config changes remain in the established dialog and tool surfaces.
| TOML section | Mode | You get |
|---|---|---|
[mcp.<name>] (default) | Full | Tools, resources, and prompts; roots and mission-control features as configured. |
[mcp.<name>] with tools_only = true | Tools only | Same runtime path as legacy [extensions.*]; prefer this over [extensions.*] for new files. |
[extensions.*] | Tools only (legacy) | Same as tools_only MCP; a load-time note may suggest migration. |
ACP server
Section titled “ACP server”bmo acp runs BMO as a JSON-RPC-over-stdio Agent Client Protocol server for Zed and other ACP clients. It is a full agent endpoint, not just a tool server: clients can create/load sessions, submit prompts, cancel runs, change the session model, receive tool/model/runtime events, receive staged workflow plan updates, and list/resolve pending operator questions.
The ACP prompt method supports legacy string content plus additive content_parts for text, image, and file-backed resource_link inputs. Resource files are resolved under the configured BMO working directory and use the same attachment safety checks as other BMO prompts. ACP records client FS capabilities (read_text_file, write_text_file) for protocol compatibility, but the current BMO runtime still performs agent file I/O on local disk rather than routing view/edit/write through editor-backed ACP FS requests.
ACP also bridges BMO permission questions to upstream session/request_permission client prompts when the client supports them. Unsupported clients still receive the normal question notification and can answer through question/resolve. Custom commands are exposed in live available_commands_update notifications, and prompts may use BMO’s canonical /run <command-name-or-id> [args] syntax to expand a custom command before the request reaches the coordinator.
Related
Section titled “Related”- MCP Client - connect external servers to BMO.
- MCP Server - expose BMO’s tools to editors and agents.
- A2A - agent-to-agent transport and server mode.
- Zed - editor integration examples for MCP and ACP.
- bmo-implementation-orchestration.md — default operator stack (A2A → ACP → MCP → CLI) and BMO process bar for in-repo work.