|
1 | | -## Inspector MCP |
| 1 | +# Chrome Inspector MCP |
2 | 2 |
|
3 | | -The DevTools MCP for inspecting DOM elements and CSS rules |
| 3 | +This gives agents DOM Elements, CSS Rules, and Computed Style, the tools that `chrome-devtools-mcp` doesn't provide. |
4 | 4 |
|
5 | | -This gives agents DOM Elements, CSS Rules, and Computed Style, the bread and butter for frontend development. |
| 5 | +This redesign of DevTools MCP aims to enable agents to take over DevTools for complex debugging. Any suggestions are welcomed. Current directions includes: |
6 | 6 |
|
7 | | -Most Chrome DevTools Protocol (CDP) logics are in [chrome-inspector](https://github.com/devtoolcss/chrome-inspector), a programming interface wrapping CDP to DOM methods. This MCP aims to explore the optimal interface for LLMs to control DevTools for complex debugging. |
| 7 | +- Agent Ergonomics: Building directly on [Chrome DevTools Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/), designing for agent needs, not library constraints |
| 8 | +- Extensibility: Making it easy for users (and agents?) to hack and customize their own toolsets |
8 | 9 |
|
9 | | -### Tools |
| 10 | +## Demo |
10 | 11 |
|
11 | | -5 tools |
| 12 | +## Installation |
12 | 13 |
|
13 | | -- `getTabs` |
14 | | -- `getNodes` |
15 | | - - document, $0, or uid as variable (.getElementById) |
16 | | - - querySelector, parent, children[0], etc |
17 | | - - return uids |
18 | | -- `getMatchedStyles` (optionally filter by selector, properties, appliedOnly) |
19 | | -- `getComputedStyle` (must specify wanted attr array) |
20 | | -- `getOuterHTML` (with depth/line lenght control) |
| 14 | +1. Install the extension from [Releases](https://github.com/devtoolcss/chrome-inspector-mcp/releases) |
21 | 15 |
|
22 | | -**TODO** |
| 16 | +2. Add the following config to your MCP client: |
23 | 17 |
|
24 | | -- auto detach, better config panel |
| 18 | +```json |
| 19 | +{ |
| 20 | + "mcpServers": { |
| 21 | + "chrome-devtools": { |
| 22 | + "command": "npx", |
| 23 | + "args": ["-y", "chrome-inspector-mcp@latest"] |
| 24 | + } |
| 25 | + } |
| 26 | +} |
| 27 | +``` |
25 | 28 |
|
26 | | ---- |
| 29 | +## Tools |
27 | 30 |
|
28 | | -- console js & message |
29 | | -- device emulation |
30 | | - |
31 | | -### Guidelines: |
32 | | - |
33 | | -1. Generalization (best to allow programmatic expression. best to only explain rules instead of full functionality.) |
34 | | -2. Filtering (If raw output can be too large, we should have predefined filtering logic. This way, the tool's value is like a lib function that doesn't require LLM implement everytime) |
35 | | -3. Minimal (Less is more. Less unneeded description, better response and longer use.) |
| 31 | +- [`getTabs`](./tools.md#gettabs) |
| 32 | +- [`selectTab`](./tools.md#selecttabs) |
| 33 | +- [`getNodes`](./tools.md#getnodes) |
| 34 | +- [`getMatchedStyles`](./tools.md#getmatchedstyles) |
| 35 | +- [`getComputedStyle`](./tools.md#getcomputedstyle) |
| 36 | +- [`getOuterHTML`](./tools.md#getouterhtml) |
36 | 37 |
|
37 | | -## Archtecture |
| 38 | +### TODO |
38 | 39 |
|
39 | | -chrome extension (ws polling) + stateful inspectors + lazy init |
40 | | - |
41 | | -### Connection |
| 40 | +- console js & message |
| 41 | +- device emulation |
42 | 42 |
|
43 | | -comparison between Extension API vs Remote Debugging Port |
| 43 | +### Guidelines |
44 | 44 |
|
45 | | -used by: |
46 | | -browser devtools access: |
47 | | -avaliable sites: except chrome:// |
48 | | -profile: |
49 | | -XXX is debugging your browser |
| 45 | +1. **Generalization**: Prefer taking programmatic expression. Let models code. |
50 | 46 |
|
51 | | -in theory, Remote Debugging Port gives the most power, but its setup is also more inconvenient |
| 47 | +2. **Filtering**: When raw output could be large, provide built-in filtering logic. |
52 | 48 |
|
53 | | ---- |
| 49 | +## How it works |
54 | 50 |
|
55 | | -For Chrome Extensions, there are two ways to communicate with local process: ws+polling (extension as client) vs native messaging (server) |
| 51 | +When Chrome starts, the extension's background worker polls a specific port every few seconds. When the MCP server starts at the address they connect. By manifest v3, one background worker serves one profile, so the MCP server can access all its tabs (TODO: filtering). |
56 | 52 |
|
57 | | -Unlike [hangwin/mcp-chrome](https://github.com/hangwin/mcp-chrome), we opt for http polling + ws for easier maintaince. The polling usage should be marginal, you can also manually turn on/off. |
| 53 | +Currently, the extension handles all DevTools logic and the MCP server is just a relay. Yet Chrome extension has many restrictions, so I planed to forward `chrome` API and keep things in MCP's Nodejs runtime following [playwright-mcp's design](https://github.com/microsoft/playwright-mcp/tree/main/extension). |
58 | 54 |
|
59 | | -one profile is not intended for multiple persons to use simultaneously, so following chrome-extension design, one mcp per profile is good. for multi agent use, each agent can config its extension and mcp port. |
| 55 | +The inspection logic is implemented in [chrome-inspector](https://github.com/devtoolcss/chrome-inspector), a programming interface wrapping [CDP](https://chromedevtools.github.io/devtools-protocol/) to DOM methods. |
0 commit comments