.mcp.json. Both Playwright MCP and Chrome DevTools are MCP servers that work in similar ways, they give MCP clients (agentic CLI tools) various tools that give the ability to browse web pages, click on buttons, read console logs and even “see” how the web page looks by allowing the client to take screenshots/snapshots. Playwright MCP is based on the Playwright framework for Web Testing and Automation, and is developed by Microsoft. Chrome DevTools MCP is based on the world’s most popular browser, and specifically its DevTools, and is developed by Google. Two big tech giants, which means these MCPs are well developed.
While Playwright MCP was working okay for me, I saw that Chrome DevTools was released after and wondered if it’s any better.
A comment from this thread (which I also linked in Cool MCP Servers) prompted me to try it: What MCPs are you using with Claude Code right now? : r/ClaudeCode
What’s the advantage of chrome devtools vs playwright mcp?
Faster, more capable. Reads the console logs, and can execute scripts. The long screenshots are great too
I used to use playwright but Chrome dev tools blew me away
At the project level, run:
claude mcp add --scope project chrome-devtools npx chrome-devtools-mcp@latestThis configures the following in the .mcp.json file:
{
"mcpServers": {
"chrome-devtools": {
"type": "stdio",
"command": "npx",
"args": [
"chrome-devtools-mcp@latest"
],
"env": {}
}
}
}Then simply open a new instance of claude and confirm that you trust the folder and MCP server. Run the /mcp slash command to verify that the MCP server appears as “✔ connected”.
To use the MCP server, I simply tell Claude something like “use chrome mcp to test and troubleshoot website x”. I would add more context depending on the specific task, but in general this is enough to let Claude know that it can use this MCP server.
The Codex CLI sandbox makes working with Chrome DevTools MCP more challenging, though I managed to make it work (Source: Connecting to a running Chrome instance | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents).
Run the following command:
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --browser-url="http://127.0.0.1:9222"In addition, if live websites need to be tested, allow network access by adding the following lines to the global Codex config:
[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]
[sandbox_workspace_write]
network_access = true Now, every time we want to use Codex CLI with Chrome DevTools MCP, we must first run this command in the background:
nohup /usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug-headful --no-first-run --disable-gpu about:blank >/tmp/chrome-launch.log 2>&1At the project level, run:
gemini mcp add chrome-devtools npx chrome-devtools-mcp@latestThis configures the following project settings:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest"
]
}
}
}Follow the instructions in MCP Client configuration | ChromeDevTools/chrome-devtools-mcp: Chrome DevTools for coding agents.
I will focus on Security in regards to how it works with agentic CLI tools and MCP servers.
Docker Blog wrote a series called MCP Horror Stories:
Unrelated to Docker, there’s also this article that features “Five Horror Stories That Actually Happened”: The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares
On 2025-09-25, Koi Blog wrote this article: First Malicious MCP in the Wild: The Postmark Backdoor That’s Stealing Your Emails | Koi Blog
postmark-mcp - downloaded 1,500 times every single week, integrated into hundreds of developer workflows. Since version 1.0.16, it’s been quietly copying every email to the developer’s personal server. I’m talking password resets, invoices, internal memos, confidential documents - everything.
This is the world’s first sighting of a real world malicious MCP server. The attack surface for endpoint supply chain attacks is slowly becoming the enterprise’s biggest attack surface.
The article generated some discussion, including on Hacker News: A Postmark backdoor that’s downloading emails | Hacker News. Some of the comments pointed out that the MCP risk isn’t really different from existing software risks:
This has nothing to do with MCP really, the same flaw is there in all software: you have to trust the author and the distributor. Nothing stops Microsoft from copying all your Outlook mail. Nothing stops Google from copying all your gmail. Nothing stops the Mutt project from copying all your email. Open source users like to think that “many eyes” keep the code clean and they probably do help, especially on popular projects where all commits get reviewed in detail, but the chance is still there. And the rest of us just trust the developers. This problem is as old as software.
MCP security risks are a real concern and I do not want to downplay that. In many ways though, these risks have existed for as long as software itself, MCP is just the latest attack vendor.
I will note that the blogs I featured here, from Docker and Koi Security, are from companies that attempt to sell solutions to this problem. This does not mean that the problem is not real or that the solutions are not needed, just something to note. I actually do find Docker’s MCP solutions to be very interesting (I mention Docker MCP Catalog below in Supply-Chain Security).
The article “The Day I Told 800+ Engineers Their AI Dreams Could Become Security Nightmares” (mentioned above in MCP Horror Stories), suggests five defense solutions:
So far I have been limiting my MCP usage to personal projects and learning. Below are some of the things I have noted while learning about how to use MCP “safely”:
When Ziva asked about the MCP security risks, she was told to “read the code”. While it’s true that many MCP servers are open-source, reviewing all of them is not exactly feasible. I often do a surface level look at the repo, its activity and amount of stars, but this is not same as reviewing the code in-depth. For this reason, I believe it is worth using MCP servers by known publishers. Docker does come in handy here with their Docker MCP Catalog. While, this catalog is not as extensive as other MCP galleries, it focuses on quality over quantity. All of the MCP servers are in the Docker MCP Catalog are by known publishers. Note that I still refuse to use Docker Desktop (due to its license), but these MCP servers can also be used in Docker CLI together with an MCP client.
Some MCP servers may have permissive default permissions, but can be configured to be more “locked-down” and limited and what they can do and access.
As an example, Kubernetes MCP Server can be run in read-only mode (this is not the default but can be set with a flag when setting up the MCP server). In this mode, the Kubernetes MCP server cannot make changes to clusters (for example, it is unable to apply manifests, but can still view existing resources). Note that even in this mode there can be security risks. One example is viewing secrets. In Kubernetes, secrets are stored in Base64 strings, which are trivial to decode for anyone that has full read access to the cluster. I have personally witnessed Claude Code attempt to read and decode Kuberenets Secrets (either with Kubernetes MCP Server or just kubectl commands) when asked to help troubleshoot my homelab cluster. For this reason, when using agentic CLI tools, I prefer to approve each command individually. Further, Kubernetes access can be regulated with Role-based access control (RBAC).
Similar to .gitignore files, most agentic CLI tools have a way to exclude specific files from the context. For example, a .env file (that may include secrets), should be specifically excluded (when not doing this, I have seen Claude Code attempt to read these files). Unfortunately, there isn’t really a standard “ignore file” for this, each tool has it own way to achieve this. If using multiple tools, multiple files might be needed.