/ 目錄 / 演練場 / Chrome DevTools
● 官方 ChromeDevTools ⚡ 即開即用

Chrome DevTools

作者 ChromeDevTools · ChromeDevTools/chrome-devtools-mcp

讓 Claude 擁有與 DevTools 相同的視野——效能追蹤、網路、主控台、即時 DOM。由 Chrome 團隊官方維護。

官方 Chrome DevTools MCP。底層驅動真實的 Chromium,提供頁面導覽、DOM 檢查、網路記錄、主控台讀取、效能追蹤與 JS 執行。讓代理程式能除錯網頁,並驗證剛完成的建置結果。

為什麼要用

核心特性

即時演示

實際使用效果

chrome-devtools.replay ▶ 就緒
0/0

安裝

選擇你的客戶端

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp"
      ]
    }
  }
}

開啟 Claude Desktop → Settings → Developer → Edit Config。儲存後重啟應用。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp"
      ]
    }
  }
}

Cursor 使用與 Claude Desktop 相同的 mcpServers 格式。專案級設定優先於全域。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp"
      ]
    }
  }
}

點擊 Cline 側欄中的 MCP Servers 圖示,然後選 "Edit Configuration"。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp"
      ]
    }
  }
}

格式與 Claude Desktop 相同。重啟 Windsurf 生效。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "chrome-devtools",
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp"
      ]
    }
  ]
}

Continue 使用伺服器物件陣列,而非映射。

~/.config/zed/settings.json
{
  "context_servers": {
    "chrome-devtools": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "chrome-devtools-mcp"
        ]
      }
    }
  }
}

加入 context_servers。Zed 儲存後熱重載。

claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp

一行命令搞定。用 claude mcp list 驗證,claude mcp remove 移除。

使用場景

實戰用法: Chrome DevTools

透過 Lighthouse 風格的追蹤診斷頁面緩慢原因

👤 前端工程師與效能工程師 ⏱ ~20 min intermediate

何時使用: 頁面反應遲緩,你希望 Claude 執行追蹤並直接指出實際瓶頸,而非憑空猜測。

前置條件
  • 目標 URL 可在未登入狀態下載入(或先行處理驗證) — 使用 navigate_page 搭配 URL;若頁面需要登入,請先透過 chrome-devtools 的點擊/輸入工具完成登入
步驟
  1. 執行效能追蹤
    開啟 https://example.com/product/123。以 4 倍 CPU 節流與 slow-3G 網路設定檔執行效能追蹤。告訴我 LCP、CLS 和 TBT 的數值。✓ 已複製
    → 三項指標數值加上追蹤摘要
  2. 找出最主要的問題根源
    哪個資源或腳本對 LCP 延遲的貢獻最大?請顯示請求時序。✓ 已複製
    → 指出具體 URL,並附上時序分解(DNS/連線/TTFB/下載)
  3. 提出具體的修復方案
    最低成本的修復方式是什麼,能讓 LCP 降至 2.5 秒以內?請提出一項變更(preconnect、preload、defer、lazy 或 bundle-split),並附上要加入的具體程式碼行。✓ 已複製
    → 可執行的 HTML/JS 差異,而非泛泛的清單

結果: 找出效能衰退的具名原因與具體修復方案,並可在套用修復後重新執行追蹤來驗證。

注意事項
  • 追蹤結果每次執行都有差異——單次數據容易誤導 — 執行追蹤 3 次並取中位數,再下結論
  • 本機/開發版建置與正式環境不同 — 針對正式環境 URL 或經 CDN 提供的預覽版本進行追蹤,而非未開啟壓縮的 localhost
搭配使用: filesystem · github

驗證 Claude 剛撰寫的功能在瀏覽器中確實正常運作

👤 使用 AI 輔助開發並需要完成驗證閉環的開發者 ⏱ ~10 min beginner

何時使用: Claude 剛修改了部分前端程式碼。在說「完成」之前,你希望它開啟頁面、點擊按鈕,並確認功能正常。

前置條件
  • 開發伺服器已啟動 — 在另一個終端機執行 npm run dev;記下 URL
步驟
  1. 開啟功能頁面並截圖
    開啟 http://localhost:3000/new-feature。截一張圖。描述你看到的內容——是否符合預期?✓ 已複製
    → 截圖加上如實描述(可能會標出「按鈕渲染在畫面外」等問題)
  2. 測試互動流程
    用測試資料 {email: '[email protected]'} 點擊「Submit」按鈕。擷取送出的網路請求與回應。✓ 已複製
    → 顯示 200 回應與對應 payload 的網路條目
  3. 檢查主控台是否有錯誤
    該流程中主控台有沒有錯誤或警告?包括 React hydration 警告或 missing-key 警告。✓ 已複製
    → 主控台乾淨,或針對發現的警告提供具體修復方式

結果: 附有截圖與網路追蹤佐證的自測功能。填補「AI 寫的程式碼實際上不能運作」的落差。

注意事項
  • 截圖看起來正常,但互動功能壞了 — 務必執行使用者操作流程(點擊/輸入),而非只做視覺檢查
  • HMR 與 Claude 截圖之間存在競態條件 — 導覽後等待 networkidle 再進行任何斷言
搭配使用: filesystem · github

除錯前端 API 呼叫失敗的原因

👤 追查「本機沒問題」的 4xx/5xx 錯誤的全端開發者 ⏱ ~15 min intermediate

何時使用: 瀏覽器主控台顯示 fetch 失敗,而你不確定實際送出的 headers/body 內容是什麼。

步驟
  1. 觸發失敗的呼叫
    開啟頁面,執行會觸發失敗的操作。擷取失敗請求的完整 URL、method、headers 與 body。✓ 已複製
    → 確切的請求 payload 一覽無遺——不需猜測
  2. 與預期內容比對
    後端預期包含 X-Client-Id header 以及帶有 user_id 欄位的 JSON body。實際送出的是什麼?列出差異。✓ 已複製
    → 指出具體缺少或錯誤的欄位
  3. 修復並重新驗證
    修改原始程式碼使請求符合預期。然後重新載入頁面,確認呼叫現在回傳 200。✓ 已複製
    → 最終網路條目顯示 200,而非原本的錯誤

結果: 已修復的 API 呼叫,並附有網路面板佐證——不再有「我本機沒問題」的問題。

注意事項
  • Session cookie 或 CORS preflight 掩蓋了真正的請求 — 不要只看失敗的請求——也要檢查 preflight OPTIONS 及 Set-Cookie 歷程
搭配使用: filesystem · postgres

CSS 重構後找出視覺上的迴歸問題

👤 進行設計系統遷移的前端開發者 ⏱ ~20 min intermediate

何時使用: 你重構了 CSS/設計 token。你想在合併前找出「按鈕變成粉紅色」之類的問題。

步驟
  1. 在 main 分支截取關鍵頁面快照
    在 http://localhost:3000(main 分支)上,截取 /、/pricing、/dashboard 的截圖。儲存至 /tmp/visual/main/。✓ 已複製
    → 3 張截圖已儲存
  2. 在你的分支截取相同頁面快照
    切換至 'css-refactor' 分支並重新啟動開發伺服器。將相同的 3 個頁面截圖儲存至 /tmp/visual/branch/。✓ 已複製
    → 3 張對應路徑的截圖已儲存
  3. 比對並描述差異
    針對每對截圖,進行視覺比對並描述任何變化。忽略像素級的反鋸齒差異;標記任何設計師會注意到的改變。✓ 已複製
    → 每頁的差異摘要,而非「看起來一樣」

結果: 可供審閱的差異報告,能捕捉到非預期的視覺變更。

注意事項
  • 動態內容(日期、隨機問候語)在截圖之間會發生變化 — 固定時間與亂數種子,或裁切掉這些區域
搭配使用: filesystem · github

組合

與其他 MCP 搭配,撬動十倍槓桿

chrome-devtools + filesystem

編輯原始碼 → 重新載入頁面 → 驗證,形成緊密循環

開啟 localhost:3000/checkout。表單的送出按鈕顏色不對。在 src/ 中找到相關 CSS 並修正,然後重新載入並截圖確認。✓ 已複製
chrome-devtools + github

重現 issue 中的 bug、驗證修復,並開附截圖的 PR

Issue #482 回報 /pricing 頁面在 375px 寬度下有版面錯誤。用 chrome-devtools 重現(在 375px 下截圖),修復 CSS,並開一個包含修復前後截圖的 PR。✓ 已複製
chrome-devtools + sentry

在本機瀏覽器中重現 Sentry 記錄到的真實使用者錯誤

Sentry issue WEB-3a91 的麵包屑顯示使用者導覽至 /cart 後點擊了「Checkout」。用 chrome-devtools 重現該流程,並擷取實際發生錯誤的位置。✓ 已複製

工具

此 MCP 暴露的能力

工具輸入參數何時呼叫成本
navigate_page url: str, wait_for?: 'load'|'networkidle' 開始任何頁面互動時使用 free
take_screenshot fullPage?: bool, selector?: str 導覽或互動後進行視覺確認 free
take_snapshot none 以文字形式取得結構化頁面內容——比截圖更利於 Claude 推理分析 free
click selector: str | uid: str 透過 CSS selector 或快照 UID 點擊元素 free
fill selector: str, value: str 在輸入欄位中輸入文字 free
evaluate_script script: str 在頁面環境中執行任意 JS 以進行檢查 free
list_console_messages none 讀取頁面的主控台日誌與錯誤 free
list_network_requests filter?: str 檢查所有已發生的 XHR/fetch 請求 free
get_network_request requestId: str 取得單一請求的完整 headers 與 body free
performance_start_trace reload?: bool, cpu_throttle?: number, network?: 'slow3g'|'fast3g' 開始效能錄製 free
performance_stop_trace none 停止並分析執行中的效能追蹤 free
emulate_cpu rate: number 模擬低階裝置(4x = 中階行動裝置) free
emulate_network profile: 'slow3g'|'fast3g'|'offline' 在受限網路條件下進行測試 free
new_page / close_page / select_page various 管理多個分頁 free

成本與限制

運行它的成本

API 配額
無——在本機執行瀏覽器
每次呼叫 Token 數
快照與網路 dump 可能較大(5–30k tokens);take_snapshot 通常比完整截圖加 DOM dump 更節省 token
費用
免費
提示
優先使用 take_snapshot 而非 take_screenshot 讓 Claude 分析結構——快照體積小且以文字為基礎。截圖留給人工審閱使用。

安全

權限、密鑰、影響範圍

憑證儲存: MCP 層級不儲存任何憑證;若你在工作階段中登入某個網站,Cookie 會保留在 Chromium 設定檔中,直到關閉為止
資料出站: Chromium 代表你瀏覽公開網路——目標網站會收到你的 IP。除了 Chromium 預設行為外,不會有額外的遙測資料傳送至 Google。
切勿授予: never point at your real browser profile containing saved logins/passwords

故障排查

常見錯誤與修復

Chromium won't launch — missing dependencies on Linux

安裝缺少的系統函式庫:sudo apt-get install -y libnss3 libatk1.0-0 libatk-bridge2.0-0 libxkbcommon0 libasound2。MCP 已內建 Chromium,但不包含所有執行期相依套件。

驗證: 執行 `npx chrome-devtools-mcp --version`——錯誤訊息會指出缺少的函式庫
navigate_page times out on slow page

改傳 wait_for: 'load' 而非預設的 networkidle;或在客戶端的 MCP 設定中增加逾時時間。

click fails: element not found

Selector 已過期或元素被隱藏。先重新呼叫 take_snapshot,並使用快照中最新的 UID。

Performance trace is empty

追蹤期間必須重新載入頁面(reload: true)或與頁面互動——閒置的分頁不會產生任何時間軸資料。

替代方案

Chrome DevTools 對比其他方案

替代方案何時用它替代權衡
Playwright MCP你需要跨瀏覽器測試(Firefox、WebKit),或偏好 Playwright 的 API 介面功能相近;chrome-devtools 效能追蹤較深入,playwright 自動化覆蓋範圍較廣
Puppeteer MCP你希望使用較底層的 Puppeteer API僅支援 Chrome,與 chrome-devtools MCP 高度重疊
browser-tools MCP你想透過 DevTools Protocol 擴充功能連線至現有的 Chrome沒有乾淨的沙盒環境——使用你真實的瀏覽器工作階段,包含其已登入的狀態

更多

資源

📖 閱讀 GitHub 上的官方 README

🐙 查看未解決的 issue

🔍 瀏覽全部 400+ MCP 伺服器和 Skills