Specialized

MCP Server

chrome-use mcp starts a stdio Model Context Protocol server for hosts that only speak MCP and can't run a shell command — Claude Desktop, ChatGPT connectors, n8n, Dify. Shell-capable coding agents (Claude Code, Cursor, Codex) should keep using the skill + CLI: it's lighter, calling the binary directly instead of going through an extra protocol layer. MCP exists specifically for hosts that speak MCP but won't shell out.

ℹ️ Which one to use

For agents that can run terminal commands (Claude Code, Cursor, Codex, your own scripts) — install the CLI + skill and run commands like chrome-use snapshot -i directly. For hosts that only integrate over the MCP protocol and have no shell (Claude Desktop, a ChatGPT connector, an n8n/Dify MCP node) — use chrome-use mcp on this page.

The 12 core tools

The MCP server exposes a lean core profile: 12 typed tools covering opening pages, reading, snapshotting, interacting, and navigation. Every tool call is forwarded to the same chrome-use binary running in --json mode — the underlying capability is identical to the CLI.

Tool	What it does
`chrome_use_open`	Open a URL / new tab
`chrome_use_read`	Read the active tab or a URL as agent-readable text
`chrome_use_snapshot`	Pull a structured accessibility snapshot with `@ref`s
`chrome_use_click`	Click by selector / `@ref`
`chrome_use_fill`	Clear and fill a form field
`chrome_use_type`	Type, appending after existing content
`chrome_use_press`	Press a key or key combo
`chrome_use_eval`	Run JavaScript on the page
`chrome_use_wait`	Wait for a condition or timeout
`chrome_use_back`	Go back one page
`chrome_use_forward`	Go forward one page
`chrome_use_reload`	Reload the current page

Extended profile: --tools all

The default 12 tools cover most tasks. When a host needs more, add --tools all to expand the profile from 12 to 24 tools — the core 12 plus the ones below (still not full CLI parity):

Tool	What it does
`chrome_use_hover`	Hover the pointer over an element
`chrome_use_select`	Pick an option in a `<select>` dropdown
`chrome_use_screenshot`	Capture a screenshot (output only, not for reading)
`chrome_use_scroll`	Scroll the page or a container
`chrome_use_tabs`	List / switch this session's tabs
`chrome_use_extract`	Scrape the page into structured JSON by schema
`chrome_use_expect`	Assert a condition, erroring if it fails
`chrome_use_find`	Locate an element or tab by text / URL
`chrome_use_network_route`	Intercept / rewrite network requests
`chrome_use_site`	Run a community site adapter for structured extraction
`chrome_use_upload`	Upload a file to a file input
`chrome_use_download`	Trigger and capture a download

bash

# 24-tool extended profile
$ chrome-use mcp --tools all

Starting the server

mcp is a subcommand of chrome-use, available on PATH alongside every other command.

bash

# start a stdio MCP server (the host spawns this process for you)
$ chrome-use mcp

Setting it up in Claude Desktop

Edit Claude Desktop's MCP config file and add a chrome-use server:

json · claude_desktop_config.json

{
  "mcpServers": {
    "chrome-use": {
      "command": "chrome-use",
      "args": ["mcp"]
    }
  }
}

✅ chrome-use command not found?

If chrome-use isn't on the PATH Claude Desktop sees at launch, swap command for the binary's absolute path (the output of which chrome-use). Restart Claude Desktop after editing the config for it to take effect.

⚠️ Know your transport: stdio vs HTTP

chrome-use mcp speaks stdio only — the host spawns the process and talks to it over stdin/stdout. Hosts that can launch a local process from a command + args (Claude Desktop, n8n) wire it up directly. But ChatGPT connectors and Dify only accept a remote HTTP/SSE MCP endpoint — they won't spawn a local process, so they can't reach a bare stdio server. You bridge stdio to HTTP/SSE first (below).

Wiring up n8n

n8n's MCP Client node can launch a stdio server by command, configured just like Claude Desktop — set the command to chrome-use (or its absolute path) and the arguments to mcp:

n8n · MCP Client (STDIO)

# Command
chrome-use
# Arguments (use "mcp --tools all" for the extended profile)
mcp

Wiring up ChatGPT connectors / Dify (needs an HTTP bridge)

These hosts only accept a URL to a remote MCP endpoint; they don't spawn a local process. Run a stdio→SSE bridge (such as supergateway) to wrap chrome-use mcp as an HTTP/SSE endpoint, then paste that URL into the host's MCP / connector config:

bash

# expose the stdio server as a local SSE endpoint
$ npx -y supergateway --stdio "chrome-use mcp" --port 8000
# endpoint: http://localhost:8000/sse — paste into the connector / Dify MCP config

ℹ️ The bridge isn't part of chrome-use

supergateway is a third-party general-purpose tool; chrome-use doesn't bundle it. ChatGPT connectors also require the endpoint to be publicly reachable (tunnel the local address first), and the machine running the bridge must be able to reach your real Chrome — the actual work still happens through the local extension + native-messaging path.

How it works

The MCP server is hand-rolled JSON-RPC over stdio, with no extra dependency pulled in. Each tool call is translated into a call to the same chrome-use binary in --json mode, and the result is wrapped back into an MCP response. Installation, the browser extension connection, and everything about driving a real Chrome stay exactly the same — MCP just swaps in a different protocol shell.

⚠️ You still need to connect a real Chrome first

chrome-use mcp doesn't solve "how do I connect to my browser" by itself — that part still runs through the browser extension covered in Install & Setup. Get the extension working there and confirm chrome-use snapshot -i runs, then wire the MCP server into your host.

Session isolation: the session argument

Every tool takes an optional session argument that maps to the CLI's --session <name>. Omit it and every call shares one default session — successive calls from the same host reuse one background daemon and one set of tabs, so a navigation or login from an earlier call is still there on the next. To run parallel, non-interfering flows, pass a distinct session name per flow; each gets its own daemon and tab group. A daemon auto-exits after 10 minutes idle and closes the tabs it created (AGENT_BROWSER_IDLE_TIMEOUT_MS overrides, 0 disables).

🪜 Don't drive multi-step flows one action per round-trip

Over MCP, every tool call costs a model inference, so driving one verb at a time is the most expensive way to run a multi-step flow. A fixed sequence collapses into one round-trip with batch; passing values between steps plus loops and conditions is what single-pass scripting (script) adds — it's currently a CLI verb, not yet an MCP tool, but inside MCP you can push multi-step logic into one call with chrome_use_eval running JavaScript on the page. See Single-pass Scripting for the reasoning.

📦 Install & Setup

Set up the CLI and browser extension — the MCP server reuses the same connection.

🌐 Real Chrome (Extension)

What the MCP tools connect through under the hood: extension + native messaging.

📚 Command Reference

The MCP server's 12 tools are a lean profile of the full command set.

MCP Server

The 12 core tools

Extended profile: --tools all

Starting the server

Setting it up in Claude Desktop

Wiring up n8n

Wiring up ChatGPT connectors / Dify (needs an HTTP bridge)

How it works

Session isolation: the session argument

Related pages