MCP servers that give coding agents a UI

"Give your coding agent a UI" turns out to mean two different things, and most tool lists mix them. One is an output surface: somewhere the agent can show you a diagram, a mockup, or a table, instead of describing it in the terminal. The other is browser control: eyes and hands on a real browser so the agent can open the app it just changed, click through it, and read what happened. The first is a display for you. The second is an instrument for the agent. You will know which one you are missing by where the pain is: "I can't see what it means" is the first, "it can't see what it built" is the second.

We build Sideshow, the output-surface entry below, so weigh our ranking accordingly. Every entry states what the server actually exposes, and this is the sister guide to our MCP servers for customer feedback roundup if that category is the one you meant.

The short version

1. Sideshow

Sideshow is an output surface: a small server with a browser viewer, and MCP tools (publish_post, update_post, wait_for_feedback, reply_to_user, upload_asset, get_design_guide) the agent uses to publish to it. Surfaces are typed parts, mermaid diagrams, sandboxed HTML mockups, syntax-highlighted diffs, terminal output, JSON trees, markdown, so the agent hands over content and the viewer supplies rendering and theme. Cards carry comment threads, and comments are delivered back to the agent exactly once, which makes it a steering loop rather than an export format. Built by our team at Modem; the core is MIT and runs locally with no account, with Cloudflare self-hosting and a hosted option when the agent and your browser are different machines.

Where it fits: design discussions, architecture reviews, "which direction?" moments with a terminal agent. Where it doesn't: it renders what the agent publishes; it cannot open your deployed app and look at it. That is browser control, below.

2. Playwright MCP

Playwright MCP is Microsoft's official server for driving a real browser through Playwright: navigate, click, type, read the page, take screenshots. Its signature design choice is operating on structured accessibility snapshots of the page rather than raw pixels, which keeps interactions fast and deterministic enough for an LLM to act on without a vision model. Apache-2.0, and effectively the default answer in this category, with the ecosystem adoption to match.

Where it fits: "open the app you just changed and verify the flow works." Where it doesn't: nothing it produces is aimed at you; you watch a browser be puppeted, not a curated result. Worth knowing: the project's own README now steers high-throughput coding agents toward its CLI-plus-skills sibling, playwright-cli, because MCP tool schemas and accessibility trees are heavy on context; the MCP server remains the fit for loops that need persistent browser state.

3. Chrome DevTools MCP

Chrome DevTools MCP is the Chrome team's server, and its pitch is inspection, not just control. Alongside driving the browser, it exposes what DevTools sees: network requests, console messages, performance traces, screenshots. That makes it the debugging entry: the agent does not just click the button, it reads the failed request and the console error that followed.

Where it fits: frontend debugging and performance work, where the agent needs the browser's internal state. Where it doesn't: Chrome only, and like Playwright MCP it gives you nothing to look at that you could not already see in a browser yourself.

4. Browserbase MCP

Browserbase's MCP server moves the browser to the cloud: sessions run on Browserbase's infrastructure, with Stagehand providing natural-language actions on top. The draw is operational, no local Chrome to manage, works from headless environments, sessions you can observe remotely. The trade is a hosted third-party service in your loop where the local options run entirely on your machine.

Where it fits: agents running in CI or on remote machines with no display. Where it doesn't: a laptop with Chrome already on it, where a local server is less moving parts.

5. mcp-ui

mcp-ui is in this list to mark the category boundary. It is not a server you install but an SDK and evolving spec for MCP servers to return interactive UI components that render inside the host application, product-style embedded interfaces in the chat itself. If you are building an MCP server and want it to answer with a working widget instead of text, this is the relevant project. It depends on the host app supporting embedded UI resources, and what your coding agent's harness renders today varies.

Where it fits: authors of MCP servers. Where it doesn't: it will not, by itself, give the agent in your terminal a screen.

What to look for

• A feedback loop, not just a display. The output-surface category is only useful if your reaction reaches the agent as data. Check for a wait-for-feedback mechanism and exactly-once delivery, or you are back to narrating in the chat.
• Sandboxing. Anything that renders agent-authored HTML should do it in a sandboxed frame with a restricted CSP; an agent writing markup that executes in your browser is agent output running with your cookies otherwise. Anything that drives a browser should make you think about which profile and which logged-in sessions it can reach.
• A plain-shell fallback. MCP support varies across harnesses, and tool schemas cost context. A tool that also works over a bare CLI or curl reaches every agent with a shell and spends fewer tokens doing it. Sideshow ships a zero-dependency CLI and plain-HTTP tier alongside MCP; on the browser side, both the Playwright project and Chrome DevTools MCP now offer CLI routes as the equivalent escape hatch.

Setup walkthrough

Sideshow, local, two commands:

npx sideshow serve --open    # viewer at http://localhost:8228
claude mcp add --scope user sideshow -- npx -y sideshow mcp

MCP-connected agents receive usage instructions automatically; ask for "sketch the auth flow on sideshow" and the card appears in the viewer. Playwright MCP is a one-liner too: claude mcp add playwright npx @playwright/mcp@latest, per its README.

How to choose

Start from which direction the pixels flow. If the agent needs to see and operate an app, take Playwright MCP by default, Chrome DevTools MCP when you need network and console internals, Browserbase when there is no local browser to drive. If you need to see what the agent means, mockups, diagrams, tradeoffs, that is the output-surface category, and it is the one a diff viewer and a browser-automation server both leave uncovered. The two categories compose fine; nothing stops a Tuesday where the agent verifies its change in Playwright and shows you the resulting architecture on a board. We wrote up the output-surface problem in more depth in getting diagrams and mockups out of a terminal coding agent.