# Using Atlas with Chrome DevTools in 2026 > The Chrome DevTools MCP server gives Atlas performance traces, network requests, console messages, and DOM inspection, so it debugs what the browser actually did. Atlas connects to Chrome DevTools through the Chrome DevTools MCP server, maintained by the Chrome DevTools team, which gives Atlas performance traces, network requests, console messages, and DOM inspection, so it debugs what the browser actually did. Setup is one command: atlas mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest. It needs Node LTS and current stable Chrome, runs headless by default, and involves no auth or API key at all. ## What the Atlas and Chrome DevTools integration does The Chrome DevTools MCP server, maintained by the Chrome DevTools team, gives Atlas performance traces, network requests, console messages, and DOM inspection. In 2026 that means Atlas debugs what the browser actually did, rather than reasoning about what your source code implies the browser should have done. Front-end bugs are runtime facts, and source code is only evidence about them. A layout shift, a slow main thread task, a failing preflight request, or a console error thrown deep inside a dependency all live in the browser, not in the repository. The Chrome DevTools MCP server hands those runtime facts to Atlas as tool output. Chrome remains the browser and the observer of truth; Atlas is the terminal agent that reads its observations and writes the fix. ## Adding the Chrome DevTools MCP server in one command Add the Chrome DevTools MCP server with 1 command: atlas mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest. That is the entire installation. The package is chrome-devtools-mcp, it runs over stdio through npx, and @latest keeps you on the current release without a separate upgrade step. The double dash separates the Atlas registration from the command Atlas will run to start the server. npx -y skips the install prompt, which matters for a non-interactive agent process. Because the server is fetched through npx rather than installed globally, there is nothing to uninstall later and no version pinned into your system that drifts out of date, though you can pin an explicit version instead of @latest if reproducibility matters more than currency. ## Requirements: Node LTS, stable Chrome, and no API key The Chrome DevTools MCP server needs Node LTS and current stable Chrome, runs headless by default, and involves 0 auth steps and no API key. Those 2 runtime dependencies are the whole prerequisite list: there is no token to mint, no OAuth flow, and no secret to keep out of your config. Two runtime dependencies are the whole prerequisite list. Node LTS runs the server process that npx fetches. Current stable Chrome is the browser it drives. Headless is the default, so Atlas can use it in a terminal-only session or over SSH with no display attached. The absence of authentication follows from the architecture: the server drives a browser on your own machine, so there is no remote service to authenticate against in the first place. ## Profiling a page: recording a trace and naming the longest task Ask Atlas to record a performance trace of your local page and name the longest task in the main-thread flamechart. In 2026 that phrasing matters, because forcing Atlas to name the longest task rather than suggest optimizations keeps the answer grounded in a real trace instead of generic advice. Performance work goes wrong when the fix precedes the measurement. An agent asked to make a page faster will produce plausible advice about bundle size and lazy loading. An agent asked to record a trace and name the longest main-thread task must actually look. Chrome DevTools MCP gives Atlas the performance trace to look at, so the resulting recommendation points at a function you can find, in a file you own, that took a number of milliseconds you can verify. ## Debugging a failing network request end to end Have Atlas read the failing network request and fix the CORS header in your server code. That bug spans 2 codebases, and the Chrome DevTools MCP server exposes network requests and console messages, so Atlas sees the actual preflight response and traces it back to the handler that produced it. A CORS failure is the clearest example of a bug that spans two codebases. The browser reports it, the server causes it, and the developer has to hold both halves in mind at once. Atlas can hold both: it reads the failing request through the Chrome DevTools MCP server, identifies which header the browser rejected or found missing, and then edits the server code that sets that header. The loop closes in one terminal session, and the browser confirms the fix. ## Reusing a logged-in browser profile with --userDataDir Pass --userDataDir when Atlas needs to reuse a logged-in browser profile instead of an isolated one. That 1 flag matters because the Chrome DevTools MCP server runs Chrome headless with a clean profile by default, so every session starts logged out and cannot reach a page behind authentication. Most real bugs live behind a login, which makes --userDataDir the flag that turns a demo into a working setup. Pointing the server at a profile directory that already holds a session lets Atlas load the authenticated page, record the trace on the screen that is actually slow, and read the console errors your users actually hit. Use an isolated profile when you want clean-room reproduction, and --userDataDir when the bug only exists once you are signed in. ## Setup 1. Add the Chrome DevTools MCP server with atlas mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest 2. Confirm the requirements: it needs Node LTS and current stable Chrome, runs headless by default, and involves no auth or API key at all. 3. Verify the tool surface: Atlas gets performance traces, network requests, console messages, and DOM inspection, so it reads what the browser did rather than guessing. 4. Ask Atlas to record a performance trace of your local page and name the longest task in the main-thread flamechart. 5. Have Atlas read the failing network request and fix the CORS header in your server code. 6. Pass --userDataDir when Atlas needs to reuse a logged-in browser profile instead of an isolated one. ## FAQ ### how do I connect Atlas to Chrome DevTools Add the Chrome DevTools MCP server with atlas mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest. It needs Node LTS and current stable Chrome, and involves no auth or API key at all. ### does the Chrome DevTools MCP server need an API key No. It involves no auth or API key at all, because it drives a browser on your own machine rather than calling a remote service. ### can an AI agent profile my web page performance Yes. Ask Atlas to record a performance trace of your local page and name the longest task in the main-thread flamechart. The MCP server supplies the real trace. ### how do I let an AI agent debug a CORS error Have Atlas read the failing network request through the Chrome DevTools MCP server and fix the CORS header in your server code. Atlas sees the actual response the browser received. ### how do I use a logged-in Chrome profile with an AI agent Pass --userDataDir when Atlas needs to reuse a logged-in browser profile instead of an isolated one. Without it, Chrome runs headless with a clean, logged-out profile. ### who maintains the Chrome DevTools MCP server The Chrome DevTools team maintains it. The server gives Atlas performance traces, network requests, console messages, and DOM inspection. ### what can Atlas see in the browser with Chrome DevTools MCP Performance traces, network requests, console messages, and DOM inspection, so it reads what the browser did rather than guessing from the source code. --- Canonical HTML: https://runatlas.sh/resources/integrations/chrome-devtools Source of truth: aeo_pages row `/resources/integrations/chrome-devtools` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.