Browser bridge
strado-preview is a stdio MCP server shipped inside the desktop app. It gives
an agent session control of the Browser preview belonging to its own worktree —
so the agent can change code, watch the page, and check whether it worked.
What the agent gets
Ten tools, all scoped to the calling worktree.
| Tool | What it does |
|---|---|
preview_tabs | List this worktree's open Browser tabs — id, url, title. |
preview_status | Current url and title of one tab. |
preview_screenshot | PNG of the page as the user sees it. |
preview_eval | Evaluate a JavaScript expression and return the result. Promises are awaited. |
preview_console | Recent console messages, replayed from the page's buffer. |
preview_network | Record requests for a while and report method, url, type and status. |
preview_click | Click a CSS selector with a real mouse event. |
preview_fill | Type into an input or textarea, replacing its value. |
preview_navigate | Navigate the page to a url. |
preview_reload | Reload the page. |
Every tool takes an optional tab argument, defaulting to tab 1, because a
worktree can have several Browser tabs. preview_network also takes reload
(default true, so page-load traffic is captured) and seconds (default 6,
capped at 30).
preview_click and preview_fill dispatch genuine input rather than
synthesising DOM events, so React and other frameworks see them as real user
interaction.
How the scoping works
Each session's process is given STRADO_WORKTREE — its own worktree's path —
and STRADO_SERVER, pointing at the Strado instance that launched it. The
bridge asks that server which preview tabs belong to that worktree and talks
only to those.
Heads up
The scoping is the point. Two agents in two worktrees each see only their own browser: one cannot screenshot, click, or read the console of the other's page, or of the Strado dashboard. Nothing in the tool surface takes a target outside the worktree it was launched in.
Because the instance is resolved from the environment rather than assumed, an agent running under a dev build drives the dev build's browser, not the installed app's.
Pointing an agent at it
The bridge is not registered for you — you add it to your agent as an ordinary stdio MCP server. Inside the packaged macOS app it lives at:
/Applications/Strado.app/Contents/Resources/bin/preview-mcp.cjs
It is a plain Node script, run as node <that path>. The packaged copy has its
WebSocket client bundled into it, so there is nothing to install alongside it.
Add it in the worktree, so the session that starts it inherits the environment
above.
What it needs to work
A Browser tab open in that worktree. With none open, every tool returns an error naming the worktree and listing which worktrees do have previews, rather than falling back to some other page.
For preview_screenshot only, that Browser tab must also be the visible hub
tab. A hidden preview produces no frames, and the tool times out with an
explanation instead of returning the wrong picture — an earlier fallback
handed an agent a screenshot of its own terminal.
CDP enabled on the instance, which is the default. Launched without it, the tools say so.
Runner-side agents have no browser
The preview browser is an Electron surface. A runner — a Linux box running Strado headless — does not have one, does not advertise the capability, shows no Browser tab, and does not ship the bridge at all. An agent session on a runner reads and writes code, runs commands, and cannot look at the page.
See remote worktrees for the rest of what differs there.