Here's what I found on the page.
Console errors
missing-logo.pngfailed to load (ERR_FILE_NOT_FOUND). The "Brew & Co logo" image is broken.fetchofapi/plans.jsonwas blocked by CORS, because the page is opened fromfile://and the origin isnull. The page logged "Failed to load plans: Failed to fetch". That failure is most likely a side effect of opening the page fromfile://, so serving it overhttp://should clear it.- One DevTools issue: an input has no
autocompleteattribute. - There was also a plain
page loadedlog.
Network requests (3 total)
index.htmlreturned 200.missing-logo.pngfailed withERR_FILE_NOT_FOUND.api/plans.jsonfailed withERR_FAILED, the CORS block above.
Performance trace (reload)
- LCP was 194 ms. TTFB was 0.2 ms, and the other ~194 ms was render delay.
- CLS was 0.00.
- There is no CrUX field data for this page.
- The trace surfaced only the LCPBreakdown insight, so I didn't dig into further insights. The long render delay is the one thing worth a closer look.
Form submission
I entered [email protected], selected "Monthly" and clicked Subscribe. The page then showed this text below the form:
Subscribed [email protected] to Monthly
The email appears in uppercase in that message, although I typed it in lowercase. The page may be transforming it with JavaScript or CSS, which is worth checking if that wasn't intended. The form fields kept their values ([email protected], Monthly).
I only used this local page and visited no other sites.
How it was tried: I used Google's chrome-devtools-mcp (usage statistics and CrUX reporting turned off, run with `--isolated --headless` in a clean temporary browser so it never touches your everyday Chrome or logged-in sessions) and let the model operate only a local page I built. The page contained deliberate problems: a missing image, a request that fails, and submit logic that uppercases the email address. The model found all of them and correctly reported the page text shown after the form was submitted. Note: this Skill itself carries no safety prompt, and it can drive a real browser.
What it does
Gives the model a playbook for the chrome-devtools MCP server. Tools are grouped into four sets: page management (open, navigate, switch and close pages, wait for text), input (click, fill forms, hover, press keys, drag, upload files, handle dialogs), debugging (accessibility-tree snapshots, screenshots, console messages, run JavaScript in the page, inspect network requests) and emulation and performance (resize, throttle CPU or network, record and analyse performance traces for Core Web Vitals).
How it works
- Snapshot first: take a text snapshot to get element uids, then click or fill by uid, and re-snapshot after page changes.
- Troubleshoot: check console errors, failed network requests, then evaluate scripts for specific values.
- Profile: start a trace with reload, then analyse insights such as LCP and layout shifts.
Good for
Debugging a page, checking performance, and automating browser steps on your own development sites.
High risk: it lets the model drive a real, running Chrome. That browser may be logged in to your accounts; the model can click, fill and submit forms, upload files, run any JavaScript in the page and read network requests (which may hold tokens and personal data), so it could act as you or leak data. The skill itself has no safety guidance. Use a separate clean profile with no logins, avoid live and financial sites, and watch what it does. Test-run with Google's chrome-devtools-mcp in a clean `--isolated --headless` browser on one local page: console, network, performance trace and form submit all worked and matched the problems I planted. By default the MCP sends usage statistics to Google and trace URLs to the CrUX API, checks for updates, and keeps a persistent profile; disable these with `--usageStatistics=false`, `--performanceCrux=false`, `--isolated`.