Playwright MCP server, then off the page

Playwright MCP is Microsoft's reference Model Context Protocol server for browser automation. It runs Playwright under the hood, exposes MCP tools like browser_navigate, browser_click, browser_type, browser_snapshot, browser_screenshot, and lets an LLM client (Claude Code, Cursor, VS Code) drive a real browser through structured accessibility snapshots instead of pixels. It is excellent at what it does. The catch is that the universe of what it can do ends at the browser tab. The moment your agent needs to open Excel, drag a file from Finder into a desktop app, or run a shell command, it is out of room and you need a second tool.

Same shape, larger surface. Both are MCP servers. Both expose typed tools the LLM discovers via list_tools. Both prefer accessibility-tree snapshots over screenshots so the model sees structured data instead of pixels. The difference is what the dispatch function calls into. Playwright MCP calls Playwright, which calls Chrome DevTools Protocol, which talks to a browser. Terminator's dispatch function (crates/terminator-mcp-agent/src/server.rs line 9953) calls into Windows UI Automation, macOS Accessibility, and (for the browser case) its own MV3 Chrome extension on ws://127.0.0.1:17373. So Terminator gives the same Playwright-shaped API for the entire desktop, and it ships browser support as one slice of a larger toolset.

Look at crates/terminator/browser-extension/manifest.json in the repo: it is an MV3 extension named "Terminator Bridge", currently version 0.24.32. The background service worker (worker.js) opens a WebSocket connection to ws://127.0.0.1:17373 the moment Chrome is started. The MCP server's execute_browser_script tool sends frames like { id, action: "eval", code, awaitPromise: true } down that socket; the extension uses Chrome's debugger permission to run the JS in the active tab via the DevTools Protocol and return the result. The point of the extension is that it lets the same MCP server that drives native Windows or macOS apps also reach into Chrome without launching a second browser instance via Playwright. You keep your real cookies, your real session, your real DOM.

For the browser-DOM case, yes, and through a different mechanism. Terminator's navigate_browser drives whatever browser is the user's default; execute_browser_script executes arbitrary JavaScript inside the active tab through the Terminator Bridge extension. You can scrape the DOM, fill forms via document queries, await promises, return JSON. What you do not get is Playwright's full test runner ergonomics (fixtures, expect, traces). Terminator is an automation framework, not a test framework. If your goal is end-to-end test authoring, use playwright-mcp. If your goal is an LLM agent that needs to do real work that crosses the browser boundary, use Terminator.

It is a single execute_sequence call with steps that interleave tool names. A real example from the repo's pattern: open_application excel.exe, then type_into_element to write a header row into the active sheet, then navigate_browser to an internal report, then execute_browser_script to scrape rows out of the page DOM (the result lands in env as rows_result), then type_into_element back into Excel pasting that string, then press_key_global Ctrl+S to save. One MCP server. One match block. Six dispatched tool calls. Two completely different surfaces. This is the workflow shape playwright-mcp cannot express because steps 1, 2, 5, and 6 happen outside the browser.

No. Terminator is a Rust crate that wraps the OS accessibility APIs directly (terminator-rs on crates.io). The browser-DOM evaluation path uses Chrome's own debugger protocol via a custom MV3 extension, not Playwright. There is no playwright dependency in the MCP agent. The architectural similarity is intentional: Playwright proved that an accessibility-tree-based, selector-driven, typed-action API is the right shape for LLMs to drive a UI. Terminator applies that same shape to the OS. The README phrases it as Playwright but for every app on your desktop. That is the lineage, not the dependency.

Thirty-one. The list is generated at compile time. crates/terminator-mcp-agent/build.rs reads server.rs, walks until it finds the line containing let result = match tool_name, collects every quoted name from the match arms, and bakes the comma-separated list into the binary as the MCP_TOOLS env var via rustc-env. crates/terminator-mcp-agent/src/prompt.rs reads env!("MCP_TOOLS") and pastes the names into the system prompt the server announces on initialize. So the LLM sees the same list the dispatch function dispatches against, automatically, every build. To see the list yourself: clone mediar-ai/terminator and run grep -n MCP_TOOLS crates/terminator-mcp-agent/build.rs crates/terminator-mcp-agent/src/prompt.rs, or open server.rs at line 9953 and read the arms.

One line for Claude Code: claude mcp add terminator "npx -y terminator-mcp-agent@latest" -s user. For Cursor and VS Code there are deep-link install buttons in the Terminator MCP Agent README. The agent is published as an npm package that wraps a Rust binary; it works over stdio by default (the editor spawns it as a child process) or over HTTP if you pass -t http (POST /mcp for calls, GET /status returns 503 when busy so a load balancer can drain). For the browser-DOM eval channel, additionally load the unpacked extension at crates/terminator/browser-extension/ in chrome://extensions with Developer Mode enabled.

The MCP server runs on macOS and Windows. Per the repo's README, the most complete coverage is on Windows (Windows UIA gives the richest accessibility tree); macOS has the AX adapter and works for many apps. Linux desktop support depends on AT-SPI and is best-effort. The Chrome extension portion (the part that overlaps with playwright-mcp) is browser-driven so it works the same everywhere Chrome runs. If your use case is purely browser-DOM and you need Linux, playwright-mcp is the safer bet. If your use case is Windows desktop automation specifically, Terminator is built for it.

Two real catches. First, accessibility trees are only as good as the apps that expose them. A well-built Win32 or UWP app gives you a clean tree; an Electron app or a custom-rendered canvas gives you mush, and you fall back to coordinate-based clicks or vision (Terminator has a gemini_computer_use tool for that, but it is slower and less reliable than tree-based selectors). Second, the Chrome extension requires loading an unpacked extension (developer mode) the first time, which is a manual step. If you cannot or will not enable developer extensions in Chrome, the navigate_browser path still works (it drives the OS-level browser window) but execute_browser_script does not have a DOM bridge. Most teams either enable developer extensions on the automation machine or use a headless Chrome path under run_command.