Chromate MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHROMATE_GRID_STEP | No | Screenshot grid spacing. | 100 |
| CHROMATE_LOG_LEVEL | No | Log level: silent, error, info, or debug. | info |
| CHROMATE_AUTO_CONNECT | No | Read Chrome 144+ DevToolsActivePort metadata before scanning ports. | true |
| CHROMATE_CDP_ENDPOINT | No | CDP HTTP or WebSocket endpoint. If omitted, Chromate auto-discovers local CDP. | |
| CHROMATE_SETTLE_DELAY_MS | No | Wait after auto actions in milliseconds. | 500 |
| CHROMATE_ACTION_TIMEOUT_MS | No | Command timeout in milliseconds. | 30000 |
| CHROMATE_CONNECT_TIMEOUT_MS | No | Connection timeout in milliseconds. | 10000 |
| CHROMATE_CDP_DISCOVERY_PORTS | No | Comma-separated local ports to scan. | 9222,9223,9224,9333 |
| CHROMATE_AUTO_CONNECT_CHANNEL | No | Chrome channel for default profile lookup: stable, beta, dev, or canary. | stable |
| CHROMATE_DISCOVERY_TIMEOUT_MS | No | Per-port discovery timeout in milliseconds. | 350 |
| CHROMATE_AUTO_CONNECT_USER_DATA_DIR | No | Explicit Chrome user data directory containing DevToolsActivePort. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tabsC | List Chrome tabs available through the configured CDP endpoint. |
| select_tabB | Select the active tab for subsequent Chromate tools. |
| page_infoB | Return information about the currently selected page and viewport. |
| screenshotC | Capture the selected tab viewport using CSS viewport pixel coordinates. |
| clickA | Click at CSS viewport coordinates in the selected tab, then wait and return an after screenshot. |
| scrollB | Dispatch a mouse wheel event in the selected tab. |
| type_textA | Insert text into the focused element in the selected tab. |
| press_keyB | Dispatch a keyDown/keyUp pair to the selected tab. |
| waitB | Wait for page stability or for visible body text to appear. |
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 9 tools
Each tool targets a distinct browser automation action: tab management, page info, screenshots, clicking, scrolling, typing, key presses, and waiting. There is no overlap or ambiguity in their intended purposes.
Most tools follow a verb-first snake_case pattern (list_tabs, select_tab, screenshot, click, scroll, type_text, press_key, wait), but page_info is a noun phrase and slightly breaks the pattern. Overall the naming is predictable and readable.
Nine tools is well within the ideal range for a browser automation server. Each tool covers a necessary action without being redundant or overwhelming.
The set covers tab selection, page inspection, screenshots, input actions, and waiting—core browser interactions. The most obvious gap is navigation (e.g., goto_url) and richer page content access, but agents can work around these limitations by relying on existing tabs.