MCP Apps Support in ACP sessions

[LucaButBoring]

What are you proposing?

Support for MCP Apps in ACP sessions.

Why does this matter?

Enables using MCP Apps servers like the draw.io or Excalidraw ones in ACP sessions in the agent panel directly. This allows for interaction patterns like doing tight iteration loops on a data flow visually before committing to it and letting the agent actually do the work in your workspace.

Are there any examples or context?

Official demo from the Excalidraw MCP server being used in claude.ai:

Possible approach

There are a couple of significant challenges to resolve here:

1. Zed doesn't yet support any form of webview in gpui - this has been requested in the context of extensions, but hasn't yet gone through. I interpret this as being more so for product-related reasons than technical ones, as supporting slower webview-based extensions risks impacting editor performance if that becomes ubiquitous.
2. Running MCP Apps over ACP is actually not something that has been done before as far as I can tell, and it introduces a big complication around who in the message flow needs to support what features in both MCP and ACP. Does the ACP client need to be aware of MCP Apps? Does the ACP server? Do we need to proxy data between them and the MCP server? Is any of this sound from a protocol conformance standpoint?

On the first point, I don't have much to add beyond noting that supporting webviews for MCP Apps would not imply supporting them in the extension API (unless the agent panel is actually an extension? that might get trickier if so). I think it should be possible to support webviews in the agent panel and only in the agent panel for now, which would give Zed an opportunity to incubate webviews in general for a single scoped feature before deciding whether or not to extend support to extensions after that. The webview would also only be active when the agent makes a tool call for it, meaning that in most cases there won't be any webview active at all (unless someone is a super heavy MCP Apps user).

On the second point, I believe this is possible under the current specifications in a way that is compliant with both protocols and does not impose any special requirements on ACP servers:

1. The Zed editor would run its own MCP client that connects directly to the upstream MCP server exposing MCP Apps.
2. Zed would also expose a sidecar MCP server of its own (passed via mcpServers to the ACP server during session initialization) that proxies calls to the upstream MCP Apps server and strips MCP Apps metadata from them.
3. When the agent behind the ACP server invokes an MCP Apps tool, that proxies the call through Zed's sidecar MCP server, triggering webview/iframe/view scaffolding in the agent panel.
4. When MCP Apps ui/message requests from the MCP Apps view come in, Zed intercepts them and sends an ACP session/prompt message to the ACP server, triggering another agent turn.

Effectively, this means that only Zed itself needs to act as an MCP Apps client, and it would intercept view-to-host MCP Apps messages via its own MCP client so that it can handle them appropriately in either the ACP session or in the webview in the agent panel.

Also shown as a sequence diagram for clarity:

sequenceDiagram
	participant Editor as Editor/Client (ACP client)
	participant UI as App UI (sandboxed iframe)
	participant Proxy as Sidecar MCP Server
	participant Agent as Agent (ACP Server)
	participant AppSrv as MCP Apps Server

	Editor->>Proxy: Create sidecar MCP server

	Note over Editor,Agent: ACP initialize
	Editor->>Agent: initialize
	Agent-->>Editor: initializeResult(agentCapabilities{ loadSession, promptCapabilities, mcpCapabilities })
	Note over Editor,Agent: Agent advertises it can accept client-provided mcpServers

	Note over Editor,Agent: ACP session/new -- client injects the sidecar server
	Editor->>Agent: session/new(cwd, mcpServers:[ sidecarServer ])

	Note over Agent,Proxy: MCP initialize
	Agent->>Proxy: initialize
	Proxy-->>Agent: initializeResult

	Note over Proxy,AppSrv: MCP initialize (Proxy is the MCP client)
	Proxy->>AppSrv: initialize
	AppSrv-->>Proxy: initializeResult

	Agent->>Proxy: tools/list
	Proxy->>AppSrv: tools/list
	AppSrv-->>Proxy: tools[ { name, _meta.ui.resourceUri: "ui://app/widget" }, ... ]
	Note over Proxy: Proxy strips/records the _meta.ui binding and<br/>re-exposes tools to Agent as plain shimmed tools
	Proxy-->>Agent: (shimmed) tools
	Agent-->>Editor: session/new result (session ready)

	Note over Agent: LLM decides to call an app-backed tool
	Agent->>Proxy: tools/call(name: widget, args)
	Proxy->>AppSrv: tools/call(name: widget, args)
	AppSrv-->>Proxy: result + _meta.ui.resourceUri: "ui://app/widget"

	Note over Proxy: UI binding intercepted here -- never forwarded to Agent
	Proxy->>AppSrv: resources/read("ui://app/widget")
	AppSrv-->>Proxy: HTML (+ bundled JS/CSS, _meta.ui.csp, permissions)
	Proxy->>UI: render in sandboxed iframe
	Proxy->>UI: ui/initialize + pass tool result as initial data

	Proxy-->>Agent: tools/call result (ui:// binding dropped)
	Note over Agent: Agent sees a normal tool result and<br/>continues reasoning, MCP-Apps-unaware

	Note over UI: User interacts with UI<br />triggering an agent turn
	UI->>Editor: ui/message
	Editor->>Agent: session/prompt

Loading