Chrome DevTools MCP：由 Chrome 官方團隊維護的 MCP Server，讓任何支援 MCP 的 AI（Claude Desktop、VSCode MCP 插件等）透過 DevTools Protocol 直接控制真實的 Chrome。

額外說明 MCP：
MCP（Model Context Protocol，模型上下文協議）：一種讓 AI 模型能與外部工具安全交換資料、執行命令的通用協議。你可以把它想成 AI 的 USB 插槽——插上不同的裝置，AI 就多一種能力。

整條鏈路長這樣：

AI  ↔  MCP Server  ↔  Chrome DevTools Protocol  ↔  真實的 Chrome

講白話就是：讓 AI 能像真人一樣打開瀏覽器、搜尋、點擊，而且還能看到 DevTools 裡的東西。

Chrome DevTools MCP 能做到什麼

（以下 Chrome DevTools MCP 簡稱 CDP）

官方把工具分成十幾類，這裡挑 QA 最常用的：

其他還有記憶體分析、Chrome 擴充套件管理、PWA 等工具，這篇用不到，有興趣可以看官方工具清單。

環境準備

前提檢查

node --version    # 要有 Node.js
npm --version
npx --version

任何一個顯示 command not found，就先去 nodejs.org 抓 LTS 版本裝起來。

另外兩個版本要求：VSCode 要 1.102 以上、Chrome 要 144 以上。

測試套件能不能跑

npx chrome-devtools-mcp@latest --help

兩種用法設定

方式 A（Claude Desktop）怎麼設定

設定檔位置：~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest"]
    }
  }
}

重啟後，看到 chrome-devtools 有啟用就表示成功了。

方式 B （VSCode）怎麼設定

Step 1：裝 VSCode MCP 擴充套件

擴充套件市場（Cmd/Ctrl + Shift + X）搜尋 @mcp Chrome Devtools，點「Enable」開啟 MCP 搜尋市場後安裝。

Step 2：設定 mcp.json

{
  "servers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--autoConnect", "--channel=stable"]
    }
  }
}

Step 3：開 Chrome 的遠端偵錯

前往 chrome://inspect/#remote-debugging，把「Allow remote … instance」打勾。

Step 4：重新載入 VSCode，開 AI 聊天功能，把測試步驟貼進去就會開始跑了。

重點來了：Prompt 要怎麼寫

我實際在用的範本長這樣：

# 角色定位
你是一位精通 Web 自動化測試的 QA，會依照測試步驟執行且彙整測試結果。

規則：
- 統一用中文回覆我
- 請 "完全依照測試步驟" 依序執行
- 若測試步驟中有 "檢查" 的文字則表示一定要進行驗證是否正確
- 若測試失敗時，可以重複自我修復最多 3 次，達 3 次就直接中斷測試並返回錯誤原因
- 若發現測試步驟與實際頁面有不符合的文案、功能，請幫我額外標記
- 最後執行後，請附上完整的執行結果
- 最後結束時都需要關閉所有瀏覽器
---
## Test Case
### 購物車移除商品後結帳
Test Step:
1. 前往 https://www.saucedemo.com
2. 帳號輸入 "standard_user"、密碼輸入 "secret_sauce"，點擊 "Login"
3. 商品排序選 "Price (low to high)"
4. 將 "Sauce Labs Onesie"、"Sauce Labs Bolt T-Shirt"、"Sauce Labs Backpack" 加入購物車
5. 點擊右上角購物車圖示，進入購物車頁
6. 在購物車頁點擊 "Sauce Labs Bolt T-Shirt" 的 "Remove"
7. 點擊 "Checkout"，填入 First Name: QA、Last Name: Tester、Zip: 100，點擊 "Continue"
8. 在結帳確認頁點擊 "Finish"

Expect Result:
1. 檢查排序後第一個商品為 "Sauce Labs Onesie"（$7.99）
2. 檢查結帳確認頁只有 "Sauce Labs Onesie"、"Sauce Labs Backpack" 兩項
3. 檢查金額顯示 Item total: $37.98、Tax: $3.04、Total: $41.02
4. 檢查出現 "Thank you for your order!"
5. 檢查右上角購物車圖示不再顯示數字

真正的價值：把 Network API 變成驗證條件

CDP 厲害的地方，是它拿得到 Network 跟 Console。

這代表你的測試步驟可以這樣寫：

SauceDemo 是純前端的網站，不會打 API，所以這裡改用另一個公開練習網站 Toolshop。

# 角色定位
你是一位精通 Web 自動化測試的 QA，會依照測試步驟執行且彙整測試結果。

規則：
- 統一用中文回覆我
- 請 "完全依照測試步驟" 依序執行
- 若測試步驟中有 "檢查" 的文字則表示一定要進行驗證是否正確
- 若測試失敗時，可以重複自我修復最多 3 次，達 3 次就直接中斷測試並返回錯誤原因
- 若發現測試步驟與實際頁面有不符合的文案、功能，請幫我額外標記
- 最後執行後，請附上完整的執行結果
- 最後結束時都需要關閉所有瀏覽器
- 測試步驟中有標記 "(API)" 就取得從 Network 中的 API 資料，
  若有空值則直接填寫 None 即可
- Netwrok API 範本: 
{
    "test_step": "xxx"
    "url": https://xxx
    "method": GET
    "status_code": 200
    "body":"{
        "xxx":"xxx",
    }"
    "response":{
        "data": [
            {
            "xxx1": "xxx",
            "xxx2": "xxxx",
            ...
        },
        ...
        ]
    }
}
... 以此類推，只要回傳有符合測試步驟的 API

## Test Case
### 搜尋商品結果正確
Test Step:
1. 前往 https://practicesoftwaretesting.com
2. 在搜尋框輸入 "hammer"，點擊 "Search"(API)

Expect Result:
1. 檢查搜尋結果列表有出現商品
2. 檢查搜尋結果的商品數量，與 API 回傳的 total 一致(API)

跑完之後，它會把對應的 API 完整吐出來：

{
    "test_step": "在搜尋框輸入 hammer，點擊 Search",
    "url": "https://api.practicesoftwaretesting.com/products/search",
    "method": "QUERY",
    "status_code": 200,
    "body": "{\"q\":\"hammer\"}",
    "response": {
        "current_page": 1,
        "from": 1,
        "last_page": 1,
        "per_page": 9,
        "to": 6,
        "total": 6,
        "data": [
            {
                "id": "01M3E4SVA6DCWSHQG4R7PZ73GX",
                "name": "Claw Hammer with Shock Reduction Grip",
                "price": 13.41,
                "in_stock": true,
                "category": "Hammer",
                "brand": "ForgeFlex Tools"
            },
            {
                "id": "01M3E4SVA9DJ99E703FAWKKBGS",
                "name": "Hammer",
                "price": 12.58,
                "in_stock": true,
                "category": "Hammer",
                "brand": "ForgeFlex Tools"
            },
            {
                "id": "01M3E4SVAD5EQ2CJ871RP9H7ZH",
                "name": "Claw Hammer",
                "price": 11.48,
                "in_stock": true,
                "category": "Hammer",
                "brand": "MightyCraft Hardware"
            },
            {
                "id": "01M3E4SVAJE3ZRWKK8JPJYXSE0",
                "name": "Thor Hammer",
                "price": 11.14,
                "in_stock": true,
                "category": "Hammer",
                "brand": "ForgeFlex Tools"
            },
            {
                "id": "01M3E4SVAR5CXJ7PRZYHCPFK3P",
                "name": "Claw Hammer with Fiberglass Handle",
                "price": 20.14,
                "in_stock": true,
                "category": "Hammer",
                "brand": "ForgeFlex Tools"
            },
            {
                "id": "01M3E4SVAVX3KXXFQAX86YFC1K",
                "name": "Court Hammer",
                "price": 18.63,
                "in_stock": true,
                "category": "Hammer",
                "brand": "ForgeFlex Tools"
            }
        ]
    }
}

這件事對 QA 的意義非常大。

因為傳統 UI 自動化只能驗「畫面上有沒有出現那個字」，但畫面對，不代表資料對。

有了 Network，驗證就從「看起來對」變成「資料真的對」

自我修復

「自我修復」，不是 CDP 本身的功能，因為這靠的是背後接的 AI 模型（ex. GPT、Claude）讓用戶自己判斷要不要重試、換個方式找元素。

對 QA 來說，最關鍵的是「網路請求」和「除錯」這兩類

總結

因為是 MCP
我最喜歡它的一點是它把 「執行層跟架構層分開」，這樣對於測試來說才能比較好控制流程
後續的章節也會再詳細說明其他細節

就目前而言，我更喜歡使用 Chrome Devtools MCP 執行方式

參考來源

• Chrome DevTools MCP GitHub