View source1 Why not a fresh browser
Most browser automation opens a clean profile and starts from nothing. For a scraper that is the right default. It is the wrong one for a tool meant to help with work already in progress, because the things that make such a task tractable are sitting in the profile the automation just declined to use: the session I am signed into, the tab already open, the form I half filled in. Before it can help me, that kind of tool asks me to rebuild the state I already had.
LiveMCP assumes the opposite. The browser is already correct, and the job is to reach it. Most of the design falls out of that. If you do not launch a browser you have to attach to one, and once you attach you do not own the page, so the tool has to coexist with whatever I am doing in the same window. The hard problem stops being how to recreate state and becomes who is allowed to touch it.
2 One hub, several clients
Attaching rather than launching creates a problem the fresh-profile design never has. I run more than one AI client. Claude Code and Cursor are both MCP clients and both want the same browser, so if each opens its own connection to the extension, the second one loses, and whichever got there first holds the browser until it exits.
So no client owns the connection. Each gets its own MCP session process speaking over standard input and output, every session registers with a single local hub through a Unix domain socket, and the hub holds the one WebSocket to the Manifest V3 extension while tracking which session issued each request. Tool definitions stay on the MCP side, routing stays in the hub, and page work stays in the extension, with a shared protocol naming the actions so one request can be followed across all three. The price is another process boundary to debug through, which I think is worth paying to stop a second client from being an error.
3 What it costs to borrow a live profile
Reusing an authenticated profile is the point of the tool and also its main risk. Every action carries the permissions of whoever is signed in, and there is no sandbox between a tool call and the account behind the tab. The hub settles which process owns the connection, but it does nothing about two clients deciding to edit the same page at once. That is why targeting a tab by URL or title matters more than acting on whatever happens to be focused, and why compound operations are worth having: fewer round trips leave fewer moments where the page can shift underneath a sequence.
Failure gets the same treatment. A tool spanning two processes and a browser has more ways to be unavailable than to be wrong, so it reports unavailability instead of letting the client infer it. Calls fail when the hub or extension is disconnected, in-flight operations time out, the extension reconnects with backoff, and the hub pushes connection-state changes to clients, so a dropped browser reads differently from an action that genuinely did not work. The extension keeps a log of recent calls for the same reason. The transport is a Unix domain socket, which ties the current design to Unix-like systems.