Chrome DevTools MCP gives agents real CSS. Not a design system
By The WAALEE Team · · 4 min read
Chrome DevTools MCP hit its 1.0 stable release in May 2026, Google's own MCP server that hands Claude Code, Cursor, Antigravity, and Copilot direct control of a live Chrome tab: navigating, clicking, profiling, and, per a documentation update that landed this month, reading an element's exact CSS. That last part is worth pausing on, because it's tempting to read "an agent can now inspect real CSS on any page" as "an agent can now extract a design system from any page." It can't, and the gap between those two claims is worth being precise about.
What get_css_styles actually returns
The new tool, documented in the project's tool reference, takes a `uid` from a prior `take_snapshot` call and returns the full cascade behind that one element: matched CSS rules, inline styles, inherited styles, custom properties, and any `@layer`, `@media`, `@container`, or `@scope` wrappers, ordered from highest to lowest precedence, with overridden declarations tagged `[overloaded]`. That's a meaningfully better answer than the workaround agents used before, calling `evaluate_script` to run `getComputedStyle` by hand, because it shows the whole cascade an agent can reason about, not just the single resolved value a script would return. The project's own skill docs now tell agents to prefer it over scripting a computed-styles read themselves.
One element, one call, every time
Here's the boundary. Every call is scoped to one `uid` from one snapshot. Ask what a specific button's color resolves to and which rule is winning, and the answer is precise and complete. Ask "what's this site's actual color palette" and there's no tool for that question, an agent would have to snapshot the whole page, call `get_css_styles` once per element it cares about, and then write its own logic to de-duplicate the resulting hex values into a palette, decide which one is the accent, and work out where a type scale actually steps. That aggregation logic doesn't ship with the server, because Chrome DevTools MCP is a debugging tool that got precise enough to be tempting to misuse as an extraction tool, not the other way around.
- get_css_styles answers "why is this element this color," with the full cascade and source line numbers, not "what are this site's colors."
- There's no built-in step that walks every element on a page and rolls the results into a palette, a type scale, or a spacing rhythm.
- Two agents, or the same agent an hour apart, can produce a different "extracted palette" from the same site, since the aggregation is improvised fresh each time.
- It's a genuine upgrade for fixing one wrong shade mid-build. It was never built to answer the question you'd ask before the build starts.
Other tools already do the aggregation
The part Chrome DevTools MCP leaves undone is the actual product of a handful of other tools built for exactly that job. MiroMiro, a browser extension and MCP server, walks a live page and hands back a brand kit, colors, fonts, and design tokens, plus paste-ready component code, rather than a per-element cascade dump. It plugs into the same clients, Claude, Cursor, Windsurf, Codex, as a connector, so an agent gets a finished palette in one call instead of assembling one from dozens of `get_css_styles` results. Either approach still leaves the question of exact W3C-format tokens, ready for a codebase rather than a chat window, as a separate step.
Use each tool for the question it actually answers
The two aren't competitors, they sit at different points in the same build. Pull the real palette, type scale, and spacing once, before an agent writes the first line, so the first draft starts from your brand instead of a coding agent's defaults. Then reach for Chrome DevTools MCP's `get_css_styles` mid-build, when one specific card or button isn't rendering the shade it should and you need the exact winning rule, not another pass over the whole system. Asking a debugging tool to do an extractor's job just means writing the aggregation logic yourself, badly, under deadline.
Three tools that touch a live page's CSS, and what each one actually hands back:
- Chrome DevTools MCP: get_css_styles returns the full cascade for one element, per call, with source lines and overridden rules marked. No built-in way to aggregate that into a palette or token set.
- MiroMiro: Browser extension and MCP server that extracts a brand kit, colors, fonts, and component code from a live page in one pass. Closer to a finished palette, not a per-element debug view.
- WAALEE: Paste a live URL and get the real colors, type scale, spacing, and radii back as exact W3C tokens plus AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt, no agent session or snapshot loop required.
None of this is a knock on what Google shipped. A tool that hands an agent the real, winning CSS rule behind any element, instead of a guess from `evaluate_script`, is a genuine debugging upgrade, and it's the right instinct to expose the actual cascade rather than a flattened value. The gap is just the one this space keeps drawing in the same place: reading CSS precisely and reading a whole design system are different jobs, and a tool built for the first one doesn't quietly become the second just because it got good at what it does.