chrome-web-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CW_CHROME | No | Explicit Chrome/Chromium executable path. | |
| CW_CONFIG | No | Path to an optional JSON config file for window on/off and tool defaults. When unset, ~/.config/chrome-web-mcp/config.json is used if it exists. | |
| CW_LOCK_PATH | No | Explicit lock-file path when CW_PROFILE_DIR is set. | |
| CW_MAX_DELAY | No | Randomized gap (seconds) between Google search starts. Default 2.5. | 2.5 |
| CW_MIN_DELAY | No | Randomized gap (seconds) between Google search starts. Default 1.0. | 1.0 |
| CW_PROFILE_DIR | No | Explicit browser profile directory. By default, each server process uses an isolated per-PID temporary profile. | |
| CW_XPRA_EXPOSE | No | Set to '1' to re-enable automatic Xpra attach when a CAPTCHA appears. Off by default. | |
| CW_DISPLAY_MODE | No | Advanced environment override for show_browser: 'xvfb' runs Chrome on a private, fully hidden display, while 'xephyr' runs Chrome inside a nested Xephyr window titled 'chrome-web-mcp' on your desktop. | |
| CW_RATE_LIMIT_DB | No | Shared SQLite path for the Google-search start-slot queue. Default is /tmp/chrome-web-mcp/search-rate-limit.sqlite3. | /tmp/chrome-web-mcp/search-rate-limit.sqlite3 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| google_searchA | Search Google in a JavaScript-rendering Chrome browser running non-headless inside Xvfb. Returns structured search results. Workflow: first google_search, then fetch_url on interesting result URLs for full text. Pace calls: bursts of 15+ searches per minute raise a pace_warning and risk a Google CAPTCHA. |
| fetch_urlA | Fetch a public HTTP(S) URL with JavaScript rendering (Xvfb Chrome) and return shaped readable markdown plus requested/final URLs, redirect flag, and total_chars. The markdown is shaped (boilerplate removed, extraction method reported); if content looks missing, retry with format:text for the full rendered text. Use after google_search on result URLs, or for pages that need JS to render (SPAs, paywalled-after-consent layouts, etc.). Parallel calls are safe; each fetch uses its own tab. char_limit caps the returned text. |
| health_checkA | Report server health: display mode, browser/process liveness, search rate-limiter queue, and last CAPTCHA time. No arguments. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: searching the web, fetching a specific URL, and reporting server health. There is no functional overlap or ambiguity between them.
All tool names follow a consistent snake_case verb_noun pattern: google_search, fetch_url, health_check. The naming clearly communicates both the action and the target.
Three tools is a well-scoped set for a browser-based search-and-fetch server. Each tool earns its place and covers a distinct step in the intended workflow.
The core workflow is complete: search Google, fetch result URLs, and check server health. There are no obvious dead ends or missing operations for the stated purpose.