How to Connect Gemini CLI to Chrome DevTools MCP

Can Gemini CLI control a Chrome page?

Yes, when its configuration exposes the right browser tools. Gemini CLI is the MCP client. Chrome DevTools MCP starts or connects to a browser and exposes actions such as opening a URL and taking an accessibility snapshot. The model can use those actions when its account, client configuration and approval policy allow the call. The provider login and the browser connection are separate. If you see Connected from gemini mcp list, check a real page before concluding the setup works. One user reported that an older Gemini CLI installation could not connect to the DevTools MCP server even though another client could. That case shows where to start diagnosing a failed connection. GitHub #178

The browser version of Gemini is a separate interface. Gemini CLI also lists Chrome DevTools MCP in its extension directory. A project settings file lets you record the server version, tools and launch options alongside the project. Gemini CLI MCP guide Chrome DevTools agent setup

Key takeaways

• Register Chrome DevTools MCP in the project and start with an isolated Chrome profile.

• Use gemini mcp list to check the connection and /mcp desc inside Gemini CLI to inspect available tools.

• Run one small browser task and verify its final URL and heading against the tool result.

• Treat Gemini authentication, workspace trust, and approval for MCP tools as separate checks.

• Keep the first task to opening and reading a page you are allowed to inspect.

Search and browser control answer different questions

A search result can point you to a release announcement. It cannot identify which account a browser tab is using or show the state after a click. Conversely, a snapshot can confirm a page's title without telling you whether it is the current official source. Start with the question, then pick a tool that can return an observable result. See how web search differs from browser control and what an AI agent does.

Pin the CLI and server in a small project

The commands below are a configuration example based on the official docs. They pin Gemini CLI 0.67.0 and Chrome DevTools MCP 1.12.0 so the tool schema is identifiable. Check the server’s Node.js and Chrome prerequisites for your platform and keep the package lockfile. Chrome DevTools MCP v1.12.0

mkdir browser-mcp-check
cd browser-mcp-check
npm init -y
npm install --save-exact @google/gemini-cli@0.67.0 chrome-devtools-mcp@1.12.0
./node_modules/.bin/gemini --version
./node_modules/.bin/chrome-devtools-mcp --version

In that test project, add the following server entry to .gemini/settings.json. Replace the command with the absolute path to the project-local binary. If the file already contains settings, merge the new server entry instead of replacing the whole file.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "/absolute/path/browser-mcp-check/node_modules/.bin/chrome-devtools-mcp",
      "args": ["--headless", "--isolated", "--no-usage-statistics"],
      "includeTools": ["new_page", "take_snapshot", "list_pages", "close_page"],
      "trust": false
    }
  }
}

includeTools is a client tool filter. It does not limit the sites Chrome can reach. Start with a page you control or are permitted to inspect, and keep the isolated profile free of personal accounts. The --isolated option starts a temporary Chrome profile. If you later need an existing session, set that up separately and confirm the account before reading private data. See how agents connect to an existing browser.

Google's Codelab uses a larger UI test application. A small page is easier for checking startup because you already know what its title and key link should be. After the first run, you can add a click or a console check if your test actually needs it. Google's agentic UI testing Codelab

Workspace trust lets Gemini load the project configuration. The server’s trust: false leaves tool calls subject to the active policy. Start interactively so you can review the server name, action and URL if Gemini asks for approval. An ask_user rule denies the call in non-interactive mode. If the environment needs a URL allowlist, configure it separately in Chrome DevTools MCP. The server’s --allowed-url-pattern option requires Chrome 149 or later. Gemini CLI policy Chrome DevTools MCP configuration

Verify the connection, then the actual page

From the project folder, run ./node_modules/.bin/gemini mcp list. If the workspace is trusted, its project settings can supply the local server configuration. Start Gemini CLI interactively and use /mcp desc to inspect the exposed tools and their parameters. Set up model access separately with one of the supported authentication methods.

For a repeatable check, serve a small local fixture from a second terminal. Run these commands in the test project. The expected heading is “MCP browser check” and the expected link points to #details. Use the output of the tool to check both.

mkdir -p fixture
cat > fixture/index.html <<'HTML'
<!doctype html>
<meta charset="utf-8">
<title>MCP browser check</title>
<h1>MCP browser check</h1>
<a href="#details">Details</a>
<p id="details">Local fixture</p>
HTML
python3 -m http.server 8765 --bind 127.0.0.1 --directory fixture

In the pinned server version, pass the ID returned by new_page as pageId to take_snapshot. The URL can change after a redirect. Inspect the final URL and heading before deciding the check passed. Tool reference for v1.12.0

Use the chrome-devtools MCP server to open http://127.0.0.1:8765/. Return the page ID, final URL, main heading and one expected link. Take a snapshot of the returned page ID. If the browser cannot reach the page, report the tool error. Do not enter credentials, submit a form or modify anything.

Locate failures before changing settings

When the server connects but a browser action is slow, check which executable actually ran. A user on an Apple Silicon Mac reported that an Intel Node installation was on the path used to launch MCP. Correcting their PATH solved their own slowdown. Treat that as a diagnostic clue for that setup. Check the architecture before changing Node, Chrome or the model. Original r/mcp report

If new_page succeeds and the snapshot fails, inspect the tool schema and arguments. In a browser with multiple tabs, take the ID from the tool response. If the resulting URL or heading points to a sign-in page, report the handoff. Keep the task read-only until the right session and record can be verified. See checking a signed-in session for an example of that distinction in another client.

Keep a short receipt you can rerun

Save the two package versions, browser version, server scope, browser mode, allowed tools, final URL, page ID and expected result. Record any approval or failure at the step where it happened. Use the first browser-agent task checklist to decide what belongs in the record. If you need to choose between a fresh profile and an existing session, see how browser connections differ. For tasks that start with the tabs you already have open, the agentic browser guide explains the browser-first approach.

For a project that needs live Chrome state in a Gemini CLI session, start with the project-scoped server and a single known page. Once you can verify that result, keep the same evidence requirements when you add the next tool.

Secholar.L

Growth & Content at Tabbit

Secholar.L writes hands-on guides about AI browsers and agent workflows, comparing tools with real research and citing verifiable sources.