MCP-over-ACP Draft: What Agent App Teams Need to Know

MCP-over-ACP is a draft proposal, not a broadly available feature. It describes how an app could supply tools to an embedded AI agent over the Agent Client Protocol (ACP) connection the two already use, instead of opening a separate MCP process or network endpoint. For teams building agent-enabled software, the immediate value is an architecture to evaluate—not a migration to schedule today.

The proposal is timely because many products now combine a user interface, an agent and tools that act on app data. A recent first-person account of a personal Mini browser built with Rust and Swift illustrates this pattern: its author says the app talks to a local fx agent over ACP, while fx manages browser functions through MCP. That account does not establish that Mini uses the proposed MCP-over-ACP transport, nor does it provide independent performance or security measurements.

What are ACP and MCP doing in the same app?

ACP is the connection between an agent and its client—the editor, desktop app or other user-facing host. It covers initialization, sessions, prompts, updates and client interactions. MCP is a separate protocol for exposing tools, resources and prompts to an agent.

In a typical embedded setup, the app talks to the agent over ACP, while the agent reaches tools through an MCP server. The app may also own useful capabilities, such as searching its current project or reading a selected record. Making those client-owned capabilities available to the agent can require another local process or HTTP listener.

The draft MCP-over-ACP RFD proposes carrying those MCP requests over the existing ACP channel. The client would declare a tool provider using type: "acp"; an agent that advertises support could address that provider by serverId and send operations inside an mcp/message envelope. The draft targets the MCP 2026-07-28 revision and explicitly does not emulate older MCP versions.

What would change for an app team?

The potential gain is a clearer integration boundary for tools the client itself owns. Consider an internal operations app with an agent assistant. The app could offer a narrowly scoped tool to look up the currently selected customer record, using its own permission checks, without deploying an additional MCP listener just for that client-owned action.

That is a proposed design, not a guarantee of lower latency or simpler operations in every product. The draft still requires capability negotiation, registration ownership, per-request context, error handling, cancellation and bounded resource use. Existing MCP transports remain relevant for remote services and agents that do not support this binding.

The RFD also distinguishes three IDs: the serverId identifies the provider registration, a logical requestId identifies one MCP operation, and the outer ACP JSON-RPC ID belongs to a particular transport hop. This matters when requests cross proxies or are cancelled; implementations must not treat those IDs as interchangeable.

Does this make agent tools safer?

Not by itself. Keeping client-owned tool calls on an existing authorized channel may remove one communication path, but a shorter path is not a security policy. The proposal says IDs are not credentials and calls for provider authorization, request-scoped capabilities, consent, bounded queues and access controls for any HTTP adapter.

For business software, the more important questions are which records an agent can read, which actions it can take, how the user approves consequential changes and what happens when a tool fails or the agent is uncertain. A read-only search tool and a tool that sends customer messages need different safeguards even if both use the same transport.

What does the Mini browser example actually show?

In the first-person account supplied with this story, the author says they moved a personal Mini browser from Electron and Bun to Rust and Swift, used a Rust CEF crate for Chromium, and embedded an agent through fx acp. The fx ACP documentation and fx MCP documentation support the general connection pattern: fx can serve ACP clients and use configured MCP servers.

The author's statements that Mini boots faster, feels more native and is more secure are observations about their project. We found no public Mini benchmark, security assessment or release record that would let us compare those claims independently. More importantly, ACP plus MCP today is not the same as MCP-over-ACP: the draft proposes a direct binding between them that should not be presented as already shipped in Mini or fx.

Should you adopt MCP-over-ACP now?

For most teams, design for it, but do not depend on the draft yet. The RFD is explicitly marked Draft. Support has to be advertised by the agent, and the proposal may change before stabilization. A production integration should use transport and SDK combinations the selected agent actually supports, while keeping tool contracts sufficiently isolated to change the transport later.

A sensible pilot would:

1. Pick one bounded task, such as retrieving a selected record or summarizing an internal document.
2. Define tool inputs, outputs, permissions and error behavior independently of ACP or MCP transport details.
3. Start with read-only access and log what the agent requested and what the tool returned, subject to the organization's data rules.
4. Require explicit user approval before any write, send, purchase or publication action.
5. Check the chosen agent and SDK for actual protocol support before testing the draft binding.
6. Compare reliability and operational complexity against an established MCP transport rather than assuming the new route wins.

Oplix perspective

The useful lesson is architectural separation. A good agent-enabled product has a clear client experience, a well-defined agent role and tightly scoped tools connected to real business systems. Protocols can simplify the wiring, but they do not replace workflow design, permissions, evaluation or human review.

Oplix can help businesses identify a narrow agent use case, build the surrounding application and API, connect approved tools, and test an automation flow before expanding its authority. If your team is considering an agent inside a portal, internal tool or desktop application, start with the job and its control points; choose the transport after those are clear.