relevance to WebMCP

[elf-pavlik]

I've seen some recent work on https://webmachinelearning.github.io/webmcp/

As I understand at this moment agent using WebMCP would be either bundled together with a web browser or provided as a browser extension. I'm wondering if the web browser itself could act as an ACP client and then maybe something like MCP-over-ACP: MCP Transport via ACP Channels could expose WebMCP to the agent.

[jo32]

A browser-owned execution bridge is one workable arrangement. In DeepDeck, which I maintain, an Electron browser discovers the page's WebMCP tools while the agent runs in DeepSeek Harness. The browser handles page execution; the agent receives tool descriptions and results. Calls are bound to a tab, frame, document, and generated-tool revision so a navigation or replacement invalidates the affected operation.

The implementation overview and screenshots are here. We use a local Host/browser bridge, not ACP, so this does not establish MCP-over-ACP compatibility. For the proposed ACP design, the page identity and tool lifetime would need to remain explicit across that transport.

[rhkiswani]

We went the other way in Mars (a from-scratch browser I work on). The browser owns the tool list instead of finding it on the page. 16 MCP tools, fixed, nothing else.

The overlap with what jo32 said is invalidation. Every call carries an epoch and the page/node revision it was computed from. If the person takes over, closes the tab, or the agent disconnects, in-flight calls die. A call against a node that moved on gets a stale-target error instead of hitting whatever is there now.

So if the browser is the ACP client I think it has to export that state too, not just the tools. Who owns the tab right now, and which revision a result came from. Otherwise the agent can't tell stale from fresh. No idea if WebMCP has anything like that yet.