Browser Automation

@mindstone/mcp-server-browser-automation

Browser control you can watch: open pages, sign in, click around, fill forms, take screenshots, and keep a reusable browser session.

*Best for practical web tasks where the user needs to see, approve, or reuse browser state instead of running a full browser-testing stack.*

Status

• Version: 0.2.6 · npm
• Auth: None (server.json)
• Tools: 21 (navigation, observation, interaction, sessions, files)
• Surface: browser-automation
• Machine-readable: STATUS.json

Why this exists

Microsoft's Playwright MCP is a strong choice for broad browser automation and testing. This connector is deliberately smaller and more visible.

Use it when an assistant needs to work through ordinary websites in a way a person can follow: open a real browser, let the user complete a login, click through admin screens, fill forms, take screenshots, and come back to the same session later. The point is trust and day-to-day usefulness, not exposing every browser-testing capability.

Example interaction

"Open https://example.com, tell me the page title, and take a screenshot."

Tools the host calls:

1. browser_navigate — opens the URL in the configured browser session.
2. browser_get_page_info — returns the current URL and page title.
3. browser_screenshot — captures a PNG screenshot.

Response (trimmed):

{

"ok": true, "url": "https://example.com/", "title": "Example Domain" }

Requirements

• Node.js 20+
• npm
• Nothing else to install for the CLI: the server ships agent-browser as a dependency.

One-click install

After clicking the button, your host will prompt you to fill: AGENT_BROWSER_SESSION_NAME, AGENT_BROWSER_SHOW_WINDOW.

Manual config for Claude Desktop / Claude Code / Goose / Continue.dev (Browser Automation)

{

"mcpServers": { "Browser Automation": { "command": "npx", "args": [ "-y", "@mindstone/mcp-server-browser-automation" ], "env": { "AGENT_BROWSER_SESSION_NAME": "mcp", "AGENT_BROWSER_SHOW_WINDOW": "true" } } } }

Quick Start

npx

npx -y @mindstone/mcp-server-browser-automation

Or install globally:

npm install -g @mindstone/mcp-server-browser-automation

mcp-server-browser-automation

This server uses the agent-browser CLI to control the browser.

Installing agent-browser

Nothing to do: installing this server installs agent-browser with it (pinned to 0.33.2), and the server always runs that copy's native binary directly. No shell and no npx are involved, so this works the same on Windows, macOS and Linux. An agent-browser on your PATH is not used.

Configuration

No API keys or credentials are required. The server communicates with the browser via the agent-browser CLI.

MCP Host Configuration

{

"mcpServers": { "browser-automation": { "command": "npx", "args": ["-y", "@mindstone/mcp-server-browser-automation"] } } }

Available Tools (21)

Navigation

• browser_navigate — Navigate to a URL
• browser_back — Navigate back in browser history
• browser_forward — Navigate forward in browser history
• browser_wait — Wait for an element to appear or a specified time

Observation

• browser_snapshot — Get the page accessibility tree with interactive element references
• browser_screenshot — Take a screenshot of the current page
• browser_get_page_info — Get the current page URL and title
• browser_get_text — Get the text content of the page or a single element
• browser_pdf — Save the current page as a PDF inside the workspace directory (refuses to overwrite existing files unless overwrite: true)

Interaction

• browser_click — Click an element using @ref or CSS selector
• browser_fill — Clear a field and fill it with text
• browser_type — Type text character by character (real keystrokes)
• browser_press_key — Press a keyboard key
• browser_scroll — Scroll the page in a direction
• browser_select — Select an option from a dropdown
• browser_hover — Hover over an element
• browser_upload — Upload workspace files to a file input (regular files only, staged privately before upload)
• browser_evaluate — Execute JavaScript in the page context (on by default; destructiveHint: true so hosts can require confirmation — see Security notes)

Session Management

• browser_tabs — List open tabs or switch to a tab
• browser_close — Close the browser session
• browser_authenticate — Open a visible browser for manual login

The browser stays open between calls. When the host stops this server (it closes the server's stdin, or sends SIGTERM or SIGINT), a separate process closes the browser and its agent-browser background process, saving the session first, so the host never waits for it. If a close cannot get through within 8 seconds (a page is hanging, say), that process force-stops them, which cannot save the session. The server declares the experimental MCP capability super-mcp/keep-alive, which asks a host that stops idle servers (such as super-mcp) to keep it running until the host itself stops, so an idle pause doesn't close the browser.

Workflow

The typical workflow uses accessibility snapshots for reliable element targeting:

1. browser_navigate → open a page
2. browser_snapshot → see interactive elements with @ref IDs
3. browser_click / browser_fill → interact using @ref references
4. browser_screenshot → visual verification

Security notes

Browser automation has a large attack surface: the agent-browser CLI controls a real headless browser that loads URLs you pass it, runs page-side JavaScript, and persists cookies and session state across runs. Read this section before deploying.

browser_evaluate runs by default — host confirmation is the gate

browser_evaluate lets the model execute arbitrary JavaScript inside the page context — the security equivalent of giving the model a shell on whatever site it has just navigated to. The tool is registered unconditionally (capability-first); the safeguard is the host's tool-approval layer. The tool is marked destructiveHint: true, so MCP hosts SHOULD require explicit user confirmation before each invocation. Do not configure a host to auto-approve this tool.

URL scheme deny-list

browser_navigate and browser_authenticate accept only http: and https: URLs (plus the special about:blank). Other URL schemes are refused before the underlying agent-browser CLI is invoked:

• file: — would let pages read local filesystem paths
• chrome: and chrome-extension: — internal browser pages and installed extensions
• javascript: — equivalent to eval() against the current document
• data: — inlined attacker-controlled HTML/JS payloads
• view-source: — defeats the same-origin policy on rendered content
• about: — privileged internal pages (about:config, about:cache, about:debugging, …); only about:blank is permitted

Cookie and session persistence

The connector tells agent-browser to use a named, persistent session via AGENT_BROWSER_SESSION_NAME (default value: mcp). All cookies, localStorage data, and any logins performed via browser_authenticate are stored on disk under that session name and reused across runs. Anyone who can read the session storage — the local user, other tools running as the same user, or backups — can also use those logged-in sessions.

To override the session name (for example, to keep separate profiles per project) set AGENT_BROWSER_SESSION_NAME explicitly in the host's MCP server config. To wipe state, close the browser via browser_close and remove the session directory managed by agent-browser.

Recommended deployment posture

• Run the connector against a separate browser profile — a dedicated AGENT_BROWSER_SESSION_NAME per MCP host. Do not reuse your daily browser profile: the connector reads and overwrites cookies in whichever profile it is pointed at, and a malicious page can ride the existing session of any site you are logged into.
• Require host confirmation for `browser_evaluate` — it runs by default; every call executes arbitrary JavaScript in the page context.
• Require host confirmation for browser_authenticate and any flow that may navigate to authenticated sites — otherwise prompt injection in fetched content can drive the browser at sites the user is logged into.
• Returned page content is enveloped as untrusted — accessibility snapshots, page text, titles, URLs, tab lists, and browser_evaluate outputs come from arbitrary websites and may contain prompt-injection attempts. The connector wraps them in envelopes (with close-tag breakout escaping) so hosts and models treat them as data, not instructions. Keep that treatment on your side: don't strip the envelopes, and don't let page text alone tri