600 points by xnx 8 days ago | 235 comments on HN
| Moderate positive
Contested
Low agreement (3 models)
Editorial · v3.7· 2026-03-15 22:39:21 0
Summary Digital Access & Education Advocates
This Chrome developer blog post describes new DevTools MCP debugging capabilities for browser sessions. The content demonstrates strong advocacy for digital access, education, and participation in technical culture through free, public developer documentation. While navigation tracking presents minor privacy concerns, the overall structural and editorial approach strongly enables freedom of expression, association, and participation in technical/scientific enterprise.
Rights Tensions1 pair
Art 12 ↔ Art 19 —Navigation tracking via metadata attributes enables monitoring of user behavior (Article 12 privacy) to improve expression and information access infrastructure (Article 19), creating tension between privacy protection and service improvement.
For example, I use codex to manage a local music library, and it was able to use the skill to open a YT Music tab in my browser, search for each album, and get the URL to pass to yt-dlp.
Do note that it only works for Chrome browsers rn, so you have to edit the script to point to a different Chromium browser's binary (e.g. I use Helium) but it's simple enough
Interesting. MCP APIs can be useful for humans too.
Chrome's dev tools already had an API [1], but perhaps the new MCP one is more user friendly, as one main requirement of MCP APIs is to be understood and used correctly by current gen AI agents.
Been using this one for a while, mostly with codex on opencode. It's more reliable and token efficient than other devtools protocol MCPs i've tried.
Favourite unexpected use case for me was telling gemini to use it as a SVG editing repl, where it was able to produce some fantastic looking custom icons for me after 3-4 generate/refresh/screenshot iterations.
Also works very nicely with electron apps, both reverse engineering and extending.
I don’t do any serious web development and haven’t for 25 years aside from recently vibe coding internal web admin portals for back end cloud + app dev projects. But I did recently have to implement a web crawler for a customer’s site for a RAG project using Chromium + Playwrite in a Docker container deployed to Lambda.
I ran the Docker container locally for testing. Could a web developer test using Claude + Chromium in a Docker container without using their real Chrome instance?
Very cool. I do something like this but with Playwright. It used to be a real token hog though, and got expensive fast. So much so that I built a wrapper to dump results to disk first then let the agent query instead. https://uisnap.dev/
Will check this out to see if they’ve solved the token burn problem.
I've been using the DevTools MCP for months now, but it's extremely token heavy. Is there an alternative that provides the same amount of detail when it comes to reading back network requests?
Google is so far behind agentic cli coding. Gemini CLI is awful. So bad in fact that it’s clear none of their team use it. Also MCP is very obviously dead, as any of us doing heavy agentic coding know. Why permanently sacrifice that chunk of your context window when you can just use CLI tools which are also faster and more flexible and many are already trained in. Playwright with headless Chromium or headed chrome is what anyone serious is using and we get all the dev and inspection tools already. And it works perfectly. This only has appeal to those starting out and confused into thinking this is the way. The answer is almost never MCP.
I use Playwright to intercept all requests and responses and have Claude Code navigate to a website like YouTube and click and interact with all the elements and inputs while recording all the requests and responses associated with each interaction. Then it creates a detailed strongly typed API to interact with any website using the underlying API.
Yes, I know it likely breaks everybody's terms of service but at the same time I'm not loading gigabytes of ads, images, markup, to accomplish things.
If anyone is interested I can take some time and publish it this week.
Great news to all of us keenly aware of MCP's wild token costs. ;)
The CLI hasn't been announced yet (sorry guys!), but it is shipping in the latest v0.20.0 release. (Disclaimer: I used to work on the DevTools team. And I still do, too)
Been using MCP tooling heavily for a few months and browser debugging integration is one of those things that sounds gimmicky until you actually try it. The real question is whether it handles flaky async state reliably or just hallucinates what it thinks the DOM looks like?
The thing I am working on is improving at the moment agentic tool usage success rates for my research and I use this as a proxy to access everything with the cookies I allow in the session.
I've been using TideWave[1] for the last few months and it has this built-in. It started off as an Elixir/LiveView thing but now they support popular JavaScript frameworks and RoR as well. For those who like this, check it out. It even takes it further and has access to the runtime of your app (not just the browser).
The agent basically is living inside your running app with access to databases, endpoints etc. It's awesome.
On one hand, cool demo, on the other, this is horrifying in more ways than I can begin to describe. You're literally one prompt injection away from someone having unlimited access to all of your everything.
Unfortunately there are like a billion competitors to this right now (including Playwright MCP, Playwright CLI, the new baked-in Playwright feature in Codex /experimental, Claude Code for Chrome...) and I can never quite decide if or when I should try to switch. I'm still just using the ordinary Playwright MCP server in both Codex and Claude Code, for the time being.
It's probably not fully optimized and could be compacted more with just some effort, and further with clever techniques, but browser state/session data will always use up a ton of tokens because it's a ton of data. There's not really a way around that. AI's have a surprising "intuition" about problems that often help them guess at solutions based on insufficient information (and they guess correctly more often than I expect they should). But when their intuition isn't enough and you need to feed them the real logs/data...it's always gonna use a bunch of tokens.
This is one place where human intuition helps a ton today. If you can find the most relevant snippets and give the AI just the right context, it does a much better job.
To be clear, this isn't a skill for the devtools mcp, but an independent project. It doesn't look bad, but obviously browser automation + agents is a very busy space with lots of parallel efforts.
DevTools MCP and its new CLI are maintained by the team behind Chrome DevTools & Puppeteer and it certainly has a more comprehensive feature set. I'd expect it to be more reliable, but.. hey open source competition breeds innovation and I love that. :)
(I used to work on the DevTools team. And I still do, too)
Some people will push back on this. They are holding out hope that the recent improvements Anthropic has made in this regard have improved the context rot problem with MCP. Anthropic's changes improve things a little. But it is akin to putting lipstick on a pig. It helps, but not much.
The reason MCP is dying/dead is because MCP servers, once configured, bloat up context even when they are not being used. Why would anybody want that?
Use agent skills. And say goodbye to MCP. We need to move on from MCP.
i'm experimenting with a different approach (no CDP/ARIA trees, just Chrome extension messaging that returns a numbered list of interactive elements).
Way lighter on tokens and undetectable but still very experimental : https://github.com/DimitriBouriez/navagent-mcp
my workaround for this was to make a wrapper mcp server which uses claude haiku to summarize the page snapshot returned in the response of each playwright mcp call, and that has worked pretty well for me: https://github.com/jsdf/playwright-slim-mcp
> Also MCP is very obviously dead, as any of us doing heavy agentic coding know.
As someone that does heavy agentic coding (using basically all the tools), this is so far from the truth. People claiming this have probably never worked in large enterprise environments where things like authentication, RBAC, rate limiting, abuse detection, centralized management/updates/ops, etc. are a huge part of the development and deployment workflow.
In these situations you can't just use skills and cli tools without a gigantic amount of retooling and increased operational and security complexity. MCP is really useful here, and allows centralized eng and ops teams to manage their services in a way that aligns with the organizations overall posture, policies, and infrastructure.
> Google is so far behind agentic cli coding. Gemini CLI is awful.
This part I totally agree. It's really hard to express how bad it is (and it's really disappointing.)
I also do this. My primary use case is for reproducing page layout and styling at any given tree in the dom. So, capturing various states of a component etc.
I also use it to automatically retrieve page responsiveness behavior in complex web apps. It uses playwright to adjust the width and monitor entire trees for exact changes which it writes structured data that includes the complete cascade of styles relevant with screenshots to support the snapshots.
There are tools you can buy that let you do this kind of inspection manually, but they are designed for humans. So, lots of clickety-clackety and human speed results.
---
My first reaction to seeing this FP was why are people still releasing MCPs? So far I've managed to completely avoid that hype loop and went straight to building custom CLIs even before skills were a thing.
I think people are still not realizing the power and efficiency of direct access to things you want and skills to guide the AI in using the access effectively.
Maybe I'm missing something in this particular use case?
I love how HN is loving this idea when it's the exact same thing Anthropic and OpenAi (and every other llm maker) did.
It's God's gift to them when it lets them bypass ads and dl copyrighted material. But it's Satan's curse on humanity when the Zuck does it to train his llm and dl copyrighted material.
Yes, running Chromium in a Docker container works well for this. There are prebuilt images like https://hub.docker.com/r/browserless/chrome that give you a headless instance you can connect to via CDP (Playwright, Puppeteer). Keeps everything isolated from your actual browser profile and credentials.
FYI: Gemini Cli is used internally at Google. It's actually more popular than Antigravity. Google uses MCP services internally for code search (since everything is in a mono-repo you don't want to waste time grepping billions of files), accessing docs and bugs, and also accessing project specific RAG databases for expertise grounding.
MCP is dead? Which cli tool should we use to instruct Chrome to open a page and click the Open button? And to read what appears in the console after clicking?
MCP permanently sacrifice a chunk of the context window? And a skill for you cli is free?
Blog post and developer documentation strongly advocate for Article 26 right to education and technical development. Content demonstrates comprehensive educational resources for developers at all levels, free and publicly accessible. The blog post itself serves educational function describing new technical capabilities.
FW Ratio: 63%
Observable Facts
Page belongs to 'Chrome for Developers' blog explicitly framed for developer education.
Navigation includes 'Blog' section with ongoing technical education content.
Docs section provides comprehensive documentation accessible without authentication or payment.
'Learn how Chrome works' tagline appears in navigation, explicitly supporting educational mission.
Blog post directly addresses Article 27 right to participate in cultural and scientific life. Technical development is modern cultural and scientific participation. Description of Chrome DevTools MCP demonstrates participation in shared technical and scientific enterprise. Content celebrates developer contribution to technical culture.
FW Ratio: 57%
Observable Facts
Blog post describes technical innovation (Chrome DevTools MCP) representing participation in modern scientific/technical culture.
Navigation includes 'Chrome Web Store' enabling developers to create and share cultural artifacts (web applications).
Multiple libraries and tools listed (Workbox, Puppeteer) support scientific investigation and technical development.
'Origin trials' referenced, enabling developers to participate in evolving web platform scientific standards.
Inferences
The focus on enabling developer innovation directly supports participation in technical culture and scientific enterprise.
Chrome Web Store and Extensions infrastructure provide mechanisms for developers to create and share cultural works.
Open standards participation through origin trials enables broad stakeholder involvement in scientific/technical culture evolution.
Blog post and associated documentation strongly support Article 25 right to adequate standard of living through technical enablement. Chrome DevTools enables debugging and optimization, directly supporting digital health and adequate living standards in increasingly digital society. Educational resources throughout documentation support health and welfare.
FW Ratio: 57%
Observable Facts
Navigation prominently features 'Accessibility' category with dedicated resources.
Chrome UX Report is listed as a core productivity tool, measuring performance and user experience standards.
'Performance' category appears in Experience section, supporting optimization for adequate user experience.
DevTools functionality enables debugging to ensure proper system operation and user welfare.
Inferences
The emphasis on accessibility and performance tools demonstrates organizational commitment to enabling adequate digital standards of living.
Chrome UX Report and Performance resources empower developers to ensure their systems meet human welfare standards.
DevTools debugging capability directly supports creation of systems that function adequately for end users.
Blog post demonstrates freedom of expression through technical journalism, describing new Chrome DevTools MCP feature. Content presents information about developer tools without apparent censorship or editorial suppression. Advocacy for open developer documentation and transparency.
FW Ratio: 50%
Observable Facts
Blog post published openly on public domain without login or subscription requirement.
Navigation menu displays multiple technical documentation topics including DevTools, Lighthouse, Accessibility, and Web Platform.
Content describes Chrome DevTools MCP feature with technical explanation of functionality and use cases.
Inferences
Public accessibility of technical documentation represents affirmative support for freedom to express and receive information.
Breadth of documented topics suggests organizational commitment to transparent disclosure of technical capabilities.
Absence of content warnings or editorial interference suggests editorial freedom in technical communication.
Blog post implicitly supports freedom of association through technical tools enabling collaborative development. Chrome DevTools and MCP features facilitate connection and coordination among developers. Content does not explicitly address association rights but tool functionality enables association.
FW Ratio: 50%
Observable Facts
Blog post describes Chrome DevTools MCP, enabling agents to debug browser sessions collaboratively.
Navigation menu includes 'Chrome Web Store' and 'Extensions' categories, supporting developer ecosystem participation.
Documentation structure facilitates developer community engagement and knowledge exchange.
Inferences
The described MCP debugging feature enables developers to collaborate and associate through shared technical capability.
The Chrome Web Store reference demonstrates structural support for voluntary developer association and marketplace participation.
Open technical documentation supports freedom of developers to associate through shared knowledge and tool usage.
Blog post implicitly supports democratic participation in technical governance by describing open developer tools. Participation in technical decision-making through DevTools and open standards participation (origin trials referenced) enables stakeholder voice.
FW Ratio: 50%
Observable Facts
Navigation menu includes 'Origin trials' reference, indicating participatory technical standards development process.
Developer documentation is publicly accessible, enabling broad participation in technical discourse.
Blog post presents technical features openly for community feedback and adoption.
Inferences
Origin trials enable developers to participate in shaping web platform standards, supporting Article 21 democratic participation.
Blog post does not explicitly discuss privacy protections. However, Chrome DevTools MCP enables debugging sessions, which could raise privacy implications regarding browser state inspection. Content does not substantively advocate for or against privacy safeguards in this context.
FW Ratio: 50%
Observable Facts
Navigation elements display tracking metadata attributes including track-type, track-metadata-eventdetail, track-metadata-position, and track-metadata-module.
No explicit privacy policy or data handling disclosure appears in the provided page content.
Page title references 'Chrome DevTools' which relates to browser debugging capabilities.
Inferences
The tracking attributes suggest user navigation is monitored for analytics purposes, which represents a structural limitation on privacy.
The absence of privacy disclosure regarding DevTools debugging scope suggests potential gaps in user consent regarding session inspection.
Developer-focused documentation may have lower privacy expectations, moderating the negative impact.
Preamble focuses on human dignity and equal rights; provided content is a technical blog post about Chrome DevTools MCP feature, not substantively addressed.
Page content insufficient to evaluate domain-level privacy policies. Navigation elements visible but privacy/data handling practices not substantively addressed in provided content.
Terms of Service
—
Terms of service not accessible from provided content. Cannot assess domain-level TOS impact on user rights.
Identity & Mission
Mission
+0.10
Article 27
Chrome for Developers domain mission centers on building tools and capabilities for developers, supporting technical participation and knowledge-sharing. Minor positive modifier for Article 27 (participation in cultural/technical life).
Editorial Code
—
No explicit editorial code of conduct visible in page content. Cannot assess.
Ownership
—
Google-owned domain. Ownership structure not directly relevant to content evaluation without specific corporate rights concerns surfaced in provided content.
Access & Distribution
Access Model
+0.10
Article 19 Article 26
Developer documentation published openly without paywall or signup requirement (public access visible). Supports free information access and education. Modest positive modifier.
Ad/Tracking
-0.05
Article 12
Navigation tracking attributes visible (track-type, track-metadata fields) indicating analytics collection. Minor negative modifier for privacy/interference concerns, though practice commonplace in tech industry.
Accessibility
+0.15
Article 25 Article 26
Developer documentation domain provides technical accessibility guidance (DevTools, Lighthouse) and accessibility resources in navigation, indicating institutional commitment to accessible technology. Modest positive modifier applied to digital access and education articles.
Developer documentation includes dedicated Accessibility navigation category and Chrome UX Report, directly supporting standards for adequate living in digital environment. Structure facilitates developers building accessible, performant systems that meet human needs.
Site structure is fundamentally educational: navigation includes Docs, Blog, Learn sections. Free, public access to technical education without paywall. Resources span from foundational concepts to advanced capabilities, supporting education access for all.
Site structure facilitates participation in technical culture: Extensions enable creating new cultural artifacts (web applications), Workbox and Puppeteer enable scientific investigation, Open standards (Origin trials) enable participation in shaping cultural evolution.
Public, unsecured blog post accessible without paywall or authentication. Navigation structure permits free information discovery across multiple topics (Docs, DevTools, Lighthouse, etc.). No apparent content filtering or expression restrictions imposed.
Developer documentation structure creates infrastructure for community participation, knowledge-sharing, and collaborative coding. Navigation includes Extensions and Chrome Web Store references, which facilitate developer ecosystems and peer association.
Site structure includes 'Origin trials' navigation item, indicating Google Chrome's commitment to participatory technical standards development. Public documentation enables developers to participate in shaping web platform evolution.
Site navigation contains tracking attributes (track-type, track-metadata-eventdetail, track-metadata-position, track-metadata-module) indicating analytics collection. This contradicts privacy protections by collecting user behavior data. However, this is baseline practice in tech documentation sites.