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
- 01Add the Chrome DevTools MCP server with atlas mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
- 02Confirm the requirements: it needs Node LTS and current stable Chrome, runs headless by default, and involves no auth or API key at all.
- 03Verify the tool surface: Atlas gets performance traces, network requests, console messages, and DOM inspection, so it reads what the browser did rather than guessing.
- 04Ask Atlas to record a performance trace of your local page and name the longest task in the main-thread flamechart.
- 05Have Atlas read the failing network request and fix the CORS header in your server code.
- 06Pass --userDataDir when Atlas needs to reuse a logged-in browser profile instead of an isolated one.
Frequently asked questions
- 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.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas vs Warp: Choosing Your AI Coding Agent in 2026
Compare Atlas, the terminal-native AI coding agent, with Warp, a smart terminal with AI Agent Mode, for developers in 2026. Evaluate features, privacy, and workflow.
Atlas with GPT-OSS 120B (hosted): picking the right host in 2026
Run Atlas on GPT-OSS 120B (hosted) in 2026. Identical Apache weights cost $0.037 per Mtok on DeepInfra and $0.35 on Cerebras, a 9.5x input spread. Full host guide.
Atlas with Code Llama (local via Ollama): a Fill-in-the-Middle Baseline in 2026
Code Llama runs free and local via Ollama at 7b, 13b, 34b, and 70b with a 16,384 token context. Strong at infilling, but too small and too old for Atlas agent work.
Atlas with Mistral Nemo 12B (local via Ollama): The 12GB GPU Pick for 2026
Mistral Nemo 12B (local via Ollama) in Atlas for 2026: a 7.1GB pull, Free (self-hosted), Tekken tokenizer, and why the KV cache, not the weights, caps context.
Atlas with DeepSeek-R1 (local via Ollama): Visible Reasoning at Every Size in 2026
DeepSeek-R1 runs locally from 1.5B to 671B under one Ollama tag, with a 128K to 164K context, free self-hosted, or $1.35 / $5.40 per Mtok via Bedrock. Atlas setup.
Atlas with Kimi K2 0711: The Original Trillion-Parameter Preview in 2026
Run Atlas on Kimi K2 0711 in 2026. Moonshot's original K2 preview costs $0.60 per Mtok input, $2.50 per Mtok output, with a 128K tokens (131,072) context.
Atlas vs Bolt.new in 2026: Terminal Agent or In-Browser WebContainer Builder
Atlas is a free, open source terminal-native AI coding agent. Bolt.new runs npm install and your dev server in-browser via WebContainers. Compared for 2026.
Atlas with AI21 Jamba Large 1.7 in 2026
AI21 Jamba Large 1.7 in Atlas, 2026: a hybrid SSM-Transformer with 256,000 tokens of context at $2.00/$8.00 per Mtok, capped at 4,096 tokens of output.