Chrome DevTools MCP server in n8n.
n8n's MCP Client Tool node speaks HTTP, while Chrome DevTools MCP speaks stdio. The fix is a small gateway process — here's the bridge command and the node settings to point at it.
n8n connects AI agent workflows to MCP servers through its MCP Client Tool node — but that node expects a network endpoint (SSE or Streamable HTTP), and Chrome DevTools MCP ships as a local stdio process from npm. So this setup has one extra step the editor-based guides don't: exposing the server over HTTP.
It's worth the step. The Chrome team's official DevTools server (43.2k GitHub stars) lets an n8n agent inspect live pages, read console errors, and run performance traces — which turns workflows like 'check the site after every deploy' or 'diagnose why this landing page is slow' into automations.
The architecture: one bridge process
You run the MCP server behind a stdio-to-HTTP gateway on a machine that has Node and Chrome — your n8n host, or any box the n8n instance can reach. The gateway (supergateway is a common choice) spawns chrome-devtools-mcp as a child process and exposes it as an SSE endpoint. n8n's MCP Client Tool node then connects to that URL like any remote server.
Keep in mind the browser runs where the gateway runs: if you want the agent to look at internal dashboards or a staging site, that machine needs network access to them.
Start the gateway
On the host machine, run the server behind supergateway. This single command fetches both packages and serves the MCP endpoint on port 8001:
npx -y supergateway \
--stdio "npx chrome-devtools-mcp@latest" \
--port 8001Configure the MCP Client Tool node
In your n8n workflow, add an AI Agent node if you don't have one, then attach an MCP Client Tool node as one of its tools. Set the endpoint to the gateway's SSE URL — http://localhost:8001/sse if n8n runs on the same host as the gateway. No credentials are needed for a local bridge; if you expose the gateway beyond localhost, put authentication in front of it, because anyone who can reach the port can drive the browser.
Once connected, the node lists the server's tools and you can choose to expose all of them or a subset to the agent. The full tool list is also visible on the server's Loomal marketplace listing at https://loomal.ai/marketplace/chrome-devtools-mcp.
A workflow worth building first
A good first test: a manual-trigger workflow where the agent's instruction is 'open the URL from the input, list console errors and any failed network requests, and summarize page load performance.' It exercises navigation, console reading, and tracing in one pass — and once it works manually, you can swap the trigger for a webhook or schedule and you have post-deploy smoke checks.
Troubleshooting in n8n
Connection refused from the node usually means a Docker networking gap: if n8n runs in a container and the gateway runs on the host, localhost inside the container is not your host — use host.docker.internal (or the host's LAN address) in the endpoint URL, and make sure the gateway listens on an interface the container can reach.
If the node connects but tool calls fail, check the gateway's terminal output — it relays the server's stderr. Chrome failing to launch is the usual cause on headless servers; install Chrome or Chromium plus its system dependencies on the gateway host. And if the tool list appears but the agent never calls the tools, tighten your agent prompt: n8n agents need the instruction to actually mention checking the page in a browser.
FAQ
How do I install Chrome DevTools MCP in n8n?
Run the server behind a stdio-to-HTTP bridge such as supergateway on a machine with Node and Chrome, then add an MCP Client Tool node to your n8n workflow and point its SSE endpoint at the gateway URL. The node discovers the tools automatically.
Why can't n8n launch the npm package directly?
n8n's MCP Client Tool node connects over the network (SSE or Streamable HTTP) rather than spawning local processes. Chrome DevTools MCP is a stdio server, so a gateway process translates between the two transports.
My MCP Client Tool node can't reach the gateway — what should I check?
Almost always Docker networking. From inside an n8n container, localhost points at the container itself; use host.docker.internal or the host's IP in the endpoint URL, and confirm the gateway's port is reachable from the container.
Is it safe to expose the gateway publicly?
Not without protection. Anyone who can reach the endpoint can control the browser on that host. Keep it on localhost or a private network, or put a reverse proxy with authentication in front before exposing it more widely.
More MCP servers for n8n.
Find SSE-ready and bridgeable servers on the Loomal marketplace.