Drive your real Chrome browser over MCP — real logins, real cookies. A stdio MCP server (CLI) plus an MV3 extension, driving Chrome via chrome.scripting/chrome.tabs. Multi-tab batch automation, accessibility snapshots, deny-all security by default.
chrome-mcp demonstrates strong definition quality with 17 well-named tools covering browser automation tasks. Nearly all tools have clear, descriptive names starting with action verbs (tabs_list, tab_select, navigate, click, type). Descriptions are detailed and explain use cases (e.g., tab_new contrasts with navigate: 'Prefer this over `navigate` when the user says "open"/"go to" a site'). Parameter schemas are comprehensive with zod types and descriptions. However, there are gaps: some parameters lack descriptions, schema documentation of return types is minimal/implicit, and error handling guidance could be more explicit. No tool has toolAnnotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. Tool composition is sound, each tool has one clear responsibility and outputs chain-compatible IDs (tabId for follow-up calls). Output envelope helpers exist (imageResult, textResult, errorResult) but are not formally documented in tool definitions themselves.
Go back in history.
Click an element. Target by selector, a snapshot ref, or role+name (e.g. role:"button", name:"Sign in") - the locator needs no snapshot first. trusted=true uses real OS-level input.
Go forward in history.
Get HTML of the page or an element.
Get visible text of the page or an element.
Hover over an element.
Navigate a tab to a URL, REPLACING its current page. Acts on the active tab unless tabId is given — to open a site without losing the current page, use `tab_new` instead.
Missing tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk classifications. Source data shows tab manipulation as WRITE and navigation as WRITE, but these hints are not exposed in tool definitions via annotation fields.
Output schemas are implicit/undocumented in tool definitions. While envelope helpers (imageResult, jsonResult, textResult, errorResult) exist in code, there is no formal schema documentation of what each tool returns, LLMs cannot predict response shape without seeing actual examples or code.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | <=2025-11-25 | v2 |
Press a key (with optional modifiers).
Reload the active (or given) tab.
Capture a screenshot (page or element). Default is JPEG (quality 70) at CSS-pixel size, which is several times smaller than PNG and reads fine. Pass format:"png" for lossless, quality 1-100 for JPEG, scale 2 for device pixels on a Retina display or 0.5 to shrink.
Scroll the page or to an element.
Select option(s) of a <select> by value or visible label.
Close a tab by tabId.
Open a NEW tab (optionally at a URL) and focus it. Prefer this over `navigate` when the user says "open"/"go to" a site — `navigate` REPLACES the current tab. Pass active:false to open in the background (used by parallel batches).
Make a tab active by tabId.
List open browser tabs.
Type text into an element (target by selector, ref, or role+name). trusted=true sends real keystrokes (works on React/Vue controlled inputs).
Some parameter descriptions are incomplete or vague. E.g., 'frameId: Frame id from frames_list' does not explain what a frame is or when to use allFrames vs frameId. 'scroll: Scroll the page or to an element' lacks detail on coordinate systems (absolute vs relative).
Error handling responses are not documented in tool descriptions. Tools reference '[AUTH_REQUIRED]' errors and 'failOnAuthWall' flags but do not explain how errors are returned or what recovery guidance the LLM should follow.
Parameter validation rules and constraints are not formally declared in schemas. E.g., 'quality: 1-100' for JPEG is mentioned in the description but not as min/max in the schema. 'nth: 0-based index' could be clearer with minProperties/maxProperties constraints.