MCP server · Google Chrome DevTools team
Chrome DevTools MCP Server
Google's MCP server exposing Chrome DevTools to an agent: performance traces, network requests, console output and live page inspection.
What it is, and what it costs you
This server connects an agent to Chrome's debugging surface, which makes it unusually good at a specific job: diagnosing why a real page is slow or broken. Rather than reasoning about code in the abstract, the agent can record a performance trace, read actual network timings, inspect console errors, and verify that a fix changed the measurement. For front-end performance work that is a qualitative difference.
The debugging surface is also, by design, a surveillance surface. Network inspection sees request and response bodies — which includes bearer tokens in `Authorization` headers, session cookies, API keys in query strings, and whatever personal data the application moves. Console output frequently contains logged tokens and internal identifiers that nobody intended to expose. All of that becomes context, and context is retained wherever that session is retained.
This makes the choice of target page more consequential than it looks. Pointing the agent at a local development build is routine. Pointing it at a production application while authenticated as a real user means the credentials and data of that session pass through the model, and possibly through a vendor's logs.
As with any browser-driving server, the profile question applies: an agent inspecting pages in a profile with live sessions can read authenticated content across every service in it.
Capability profile
What this server can reach, and why a security team cares. These are capabilities the server has by design — derived from the publisher's documentation, not from a scan.
- network request inspection
Authorization headers, session cookies, API keys and response payloads are all visible and all end up in the context window.
- console and error access
Logged secrets, stack traces and internal identifiers — a routine source of accidental credential exposure.
- live page control
Navigation and interaction with whatever the browser can currently reach, including authenticated applications.
- performance tracing
Low direct risk; traces can embed URLs and parameters that reveal internal topology.
Restrict this before you roll it out
- Target development environments
Debug against local or staging builds where the data and tokens are not real.
- Use a clean browser profile
Prevents the agent from inspecting authenticated sessions unrelated to the task.
- Assume captured traffic is retained
Anything the agent reads may persist in session history and vendor logs. Rotate any credential that passes through.
Vincosha Assay assessment
not yet assessedWe have not published a scan verdict for Chrome DevTools MCP Server.
Everything above is a capability profile compiled by hand from the publisher's own public documentation on 2026-07-25. It describes what this artifact can reach and what to restrict before rolling it out. It is not a security verdict, and it should not be read as one.
When Vincosha Assaypublishes an assessment for this artifact it will appear here with a verdict, the findings behind it, and the date it ran. We would rather leave this space empty than fill it with a guess — inventing a security verdict about somebody else's software would be both wrong and dangerous.
What an assessment covers
- prompt-injection patterns in descriptions and instructions
- credential reads and outbound egress in bundled code
- over-scoped permissions and manifest claims
- typosquatted and impersonating names
- tool-manifest drift since the last approval
- content hash against the version you approved
Sources
This profile was compiled from the publisher's own documentation. Products change — verify against the source before making a decision that depends on a specific detail.