chrome-devtools-mcp makes dashboard work via ha-mcp dramatically better — sharing in case it's useful

[whoamiTM]

Hey — thanks for ha-mcp. It's been the backbone of my Claude Code + Home Assistant setup for several months.

Not opening a PR or asking for anything — just sharing in case it's useful to you or other users.

After a lot of dashboard work through ha-mcp, I've concluded it's next to impossible to do well without also giving the
assistant access to https://github.com/ChromeDevTools/chrome-devtools-mcp. Writing dashboard YAML blind — no way to see the
rendered result — turns every iteration into "write and hope, then human-verify." Pairing the two MCPs lets the assistant
write config, screenshot the dashboard, see what actually rendered, and iterate without me in the loop.

A few real examples from my own setup where the visual loop made the difference:

• button-card shadow-DOM min-width causing horizontal scrollbars in panel mode. Standard CSS on the wrapper card does
  nothing — the constraint is inside the card's shadow DOM. Iterating on card_mod selectors blind is brutal; with DevTools
  you can see exactly which shadow node is enforcing the width and write the right !important override.
• hui-input-datetime-entity-row overflowing on mobile. The native is three shadow-DOM levels deep and
  has a hard intrinsic minimum width. I spent a session trying to override it via card_mod with deep selectors, blind, before
  settling on a workaround. With Chrome DevTools I'd have seen in 30 seconds that the native input wasn't going to shrink no
  matter what CSS I threw at it.
• Glassmorphism backdrop-filter: blur() doing nothing on a dark-only theme. The CSS is "correct" — it just has no
  background image to blur, so the effect is invisible. Looking at a screenshot makes this obvious instantly; reading the
  YAML doesn't.
• expander-card silently stripping HTML from a markdown title-card. Jinja2 evaluates fine, values appear, but every

//style= is gone. No errors — just unstyled text. Without seeing the rendered output, the assistant assumes the config worked.

The pattern across all of these: the failure modes are visual or DOM-level, and the model literally cannot diagnose them
from config alone. The quality difference is large enough that I think most people doing dashboard work via ha-mcp will
eventually hit the same wall — figured it was worth surfacing somewhere searchable so the next person finds it faster than
I did.

Setup is cross-platform (Chrome on macOS, Windows, native Linux, and WSL via WSLg all work), each with slightly different
launch flags and persistent-profile handling. Happy to share my notes if anyone wants them — just didn't want to assume
you'd want that material in the repo itself.

[sergeykad]

Creating a feedback loop is one of the most effective ways to improve LLM output.

You can also use the Claude Chrome extension instead of the dedicated MCP for easier installation.

[th3Wheel]

The only thing is the e Claude Chrome extension does not work with a free plan.

[kingpanther13]

This is a great idea, I wonder if it'll be possible to implement something like that within our dashboard tools. I'm going to open an issue and investigate it in the future. If we could find a way to visually render the dashboard in a way that the llm can see it this will greatly improve dashboard creation.