Open MCP Server

Most browser automation work still happens through a UI a human drives. Open MCP server moves it into the conversation instead. Model-agnostic computer-use MCP: screenshot, safety-gated actions, Windows UIA targeting.

The short version

The MCP client is the reasoner (no API key, model-agnostic): it calls capture to see the screen, then acts with do / click_name / invoke. This is the keyless Mode-A loop of open-compute, but as native tool-calls.

The tools it exposes

The server publishes 14 tools. What each one is for:

• capture — Screenshot the screen → returned as an image (optionally a single window)
• tree — List UI elements via Windows UIA (name/role/center_norm)
• click_name — Resolve an element by name and click it
• invoke — Click-free activation of an element via UIA patterns
• list_windows — List open windows with exact titles, rects and normalized centers (read-only)
• get_screen_size — Virtual-desktop geometry + per-monitor breakdown (read-only)
• watch_dir — Watch directories for file-system changes
• push_status — Feed-manager status (read-only)
• rec_replay — Replay a .clirec macro (needs the optional clirec package)
• signal_show — Show the screen-usage signal overlay: glowing border + cursor ring colored per mode (control=red, observe=blue, …); persists in the server process
• signal_hide — Hide the signal overlay
• signal_status — Overlay state + collect a pending abort-hotkey message (consumed on read)

What it needs from you

Configuration is passed through the environment: OC_SAFETY_MODE. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

• Python 3.10+ and uv on the host. The default launch uses uvx to fetch open-compute (with the mcp extra) from GitHub on first run — the mcp extra tracks the GitHub repo, so this works regardless of PyPI release timing. - Windows for real capture/input (mss + UIA). Other platforms import the tools but cannot drive a desktop.

Getting it running

Because this one is hosted, setup is mostly authentication — you point your client at the endpoint and approve access. Nothing runs on your machine, so there is no runtime to keep patched.

How it compares

Plenty of browser automation servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Open's toolset — capture, tree, click_name and 11 more — is a fair guide to whether it matches your workflow. It is maintained by lukisch; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Things to watch

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch Open.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.