Skip to main content
If you have not set BrowserTools up yet, start with the installation page. Open Chrome DevTools on the page you want to inspect, then talk to your agent normally. It decides which tools to call.

​
Debugging what just broke

”Can you check console and network logs to see what went wrong?”
Your agent will reach for getConsoleErrors and getNetworkErrors first, then widen to getConsoleLogs and getNetworkLogs if it needs surrounding context. Every log tool takes keyword filters and paging, so an agent can narrow instead of dumping everything into its context window:
Results come back newest-first and always report total alongside returned, so your agent knows when it is only seeing part of the picture.
”Enter debugger mode”
debuggerMode is an MCP prompt — pick it from your client’s prompt menu (in Cursor and Claude Code, type /). It walks your agent through a systematic reproduce-then-diagnose loop instead of guessing.
Network capture starts when DevTools opens. Reload the page to capture a full page load — requests that finished before DevTools was open are not recorded.
”Wipe the logs”
wipeLogs clears captured telemetry so you get a clean slate before reproducing a bug.

​
Working on the UI

”Something doesn’t look right in the UI. Can you take a screenshot?”
takeScreenshot returns the image itself to your agent, so it can look at your page directly. No dragging files into chat, and no auto-paste step. The file is also saved to ~/Downloads/mcp-screenshots (configurable) and linked as a resource.
”Can you edit the currently selected element to do x, y and z?”
Use the DevTools element picker to select any component, then ask. getSelectedElement returns what you picked, which makes finding that component in a large codebase much faster.
”What page am I on, and is the extension actually connected?”
getPageInfo and getConnectionStatus answer both, and are how an agent orients itself before doing anything else.

​
Auditing performance, accessibility and SEO

”I need to improve SEO and performance… enter audit mode”
Four Lighthouse audits run against the page you are on: runPerformanceAudit, runAccessibilityAudit, runSEOAudit and runBestPracticesAudit. Each returns a score, a pass/fail summary and the failing audits ordered heaviest-first, with Core Web Vitals for performance. auditMode and nextjsSeoAudit are prompts that run them as a sequence and turn the results into a prioritised work list.
Audits launch a separate browser and take up to a minute. Any Chromium-based browser works — run --doctor to see which one will be used.

​
Working across several tabs

Every tab with DevTools open is tracked separately, and telemetry is attributed to the tab that produced it. Tools act on the current tab — the one you most recently opened DevTools on. Every result reports its tabId and url, plus otherTabs, so a wrong-tab answer is visible rather than silent.
”List the browser tabs, then check the console on the checkout one”
listBrowserTabs returns each tab and the id to address it by. Pass that tabId to any tool, or allTabs: true on a log tool to read across every tab at once.

​
Keeping large data out of the context window

Whole-history payloads are exposed as MCP resources rather than inlined, and tools link to them so your agent fetches them only when it decides to: The HAR resource is worth knowing about directly: it opens in Chrome’s own Network panel and in most HTTP tooling, so you can hand a captured session to something else entirely.

​
Next steps