The Browser Can Open the Page. Chrome DevTools Tells Me Why It Broke

How I connect Bob to a dedicated Chrome session so it can debug with console logs, network requests, and performance traces instead of guessing from the page.

The built-in browser tool is good. I still reach for Chrome DevTools when I want Bob to debug like a developer instead of acting like a polite intern with a screenshot button.

IBM Bob already has a built-in browser tool. I use it. For quick checks on localhost, simple click paths, or a fast screenshot after a UI change, it is the shortest path from question to answer. No extra process. No remote debugging port. No setup ritual.

But a browser tool and a debugging tool are not the same thing.

When a page looks fine and the console is exploding, when one request quietly returns 401, or when performance gets weird after a harmless-looking dependency bump, I want Bob working from the same evidence I would use myself. That means console messages, network requests, performance traces, screenshots, and a real browser session I can inspect too. I do not want Bob guessing from pixels when the browser already knows what broke.

That is why I keep the official chrome-devtools-mcp around.

What We Build

We will connect IBM Bob to a dedicated Chrome session through the Chrome DevTools Protocol remote debugging interface. At the end, Bob can open a page, inspect console output, list network requests, take screenshots, and run a performance trace against the same browser session you can inspect manually.

What You Need

You need Chrome, npm, and Node.js 22.12 or newer. The package currently requires that runtime level. You also need IBM Bob, because that is the client I am using here. If you want to follow along properly, have one real target ready: a local app, a staging URL, or at least a page with enough JavaScript to fail in an interesting way.

• Chrome stable

• Node.js 22.12 or newer

• npm

• IBM Bob

• A local app or URL to test

• About 10 minutes

The Built-In Browser Tool Is Still Useful

I am not replacing one tool with the other. I am giving each tool the job it deserves.

I use the built-in browser tool for fast, boring work: open a local page, click through a flow, confirm text, check whether a dialog still appears, maybe grab a screenshot. That is good enough surprisingly often.

I switch to Chrome DevTools when the visible symptom is only the surface.

The built-in browser tool is great for navigation and quick verification. Chrome DevTools earns its place when you need console output, network evidence, or a performance trace. One tool shows me what happened on the page. The other gives me much more of the reason it happened.

That last part is why I personally prefer the Chrome DevTools toolset for serious debugging. I already trust those artifacts. If Bob tells me that GET /api/session failed with 401, I know exactly where I would look next. If Bob tells me First Contentful Paint is high after a trace, I know what kind of evidence I am looking at. There is less translation cost between what Bob saw and how I would debug the same problem myself.

The built-in browser tool feels like remote hands. Chrome DevTools feels like shared instrumentation.

Start Chrome Yourself

The official server can start Chrome on its own. That is fine, and for some setups it is the easiest option.

I still prefer starting Chrome myself with a separate debug profile.

First, the trust boundary becomes obvious. The MCP server can inspect the content of that browser session, so I want a clean profile with only the tabs relevant to the task. Second, I do not want my daily Chrome profile mixed with Bob work. Third, this manual connection pattern is useful when the MCP client runs inside a sandbox and cannot launch Chrome directly.

On macOS, start Chrome like this:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/tmp/chrome-debug"

Keep that terminal window open. Then visit http://127.0.0.1:9222 in any browser. If Chrome is listening, you should see debugging metadata instead of a connection error.

The separate --user-data-dir matters more than it looks. It keeps the debug session isolated from your normal browsing profile and makes it much harder to hand Bob tabs, cookies, and history that were never part of the task.

Attach the Official MCP Server

Now add the server to your MCP configuration. MCP, Model Context Protocol, is just the mechanism that lets Bob talk to extra tools. The exact file path depends on the client, so I am showing the generic JSON shape here. In IBM Bob, this sits next to the built-in browser tool, not instead of it.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222",
        "--no-usage-statistics",
        "--no-performance-crux"
      ],
      "env": {
        "CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS": "true"
      }
    }
  }
}

I use this setup for a boring reason: I often point these tools at internal systems. I prefer the default to be private and predictable.

Here is what the important flags do:

• --browser-url connects the server to the Chrome instance we started ourselves

• --no-usage-statistics disables usage telemetry for the MCP server

• --no-performance-crux stops performance tooling from sending trace URLs to the CrUX API for field data lookup

• CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS=true disables update checks from the MCP process

Restart your MCP client after saving the config so the server is picked up cleanly.

Why I Prefer Chrome DevTools for Debugging with Bob

This is the real point of the setup. It is not just a bigger tool list.

I prefer it because it keeps Bob inside a workflow I already trust.

When Bob uses the built-in browser tool, I mostly get the outside of the page. That is useful. But once the problem lives in JavaScript errors, failed fetches, missing headers, slow render paths, or a suspicious waterfall, I want Bob looking at the same instrumentation I would open myself a few seconds later.

That makes the conversation better.

Bob stops saying things like “the page may be failing because a request did not complete.” Instead it can tell me which request failed, what status code came back, what the console said, or which trace insight looks suspicious. If I need to take over, I can inspect the exact same Chrome session manually. No translation step. No mental jump from screenshot to root cause. Just the browser, the evidence, and the bug.

There is also a less romantic reason: I know Chrome DevTools very well already. I do not want a second debugging universe if I can avoid it. If Bob and I can both work from DevTools artifacts, handoff gets cheaper.

Use It Like a Debugger

Once the server is running, use it for work where the extra evidence actually matters.

Open a real page and ask for the kind of output you would want from a human teammate:

Bob, use Chrome DevTools to open http://localhost:3000, take a screenshot, and list any console errors.


Then move one level deeper:

Bob, use Chrome DevTools to open http://localhost:3000, list failed network requests, and explain which one blocks login.


And when performance is the story:

Bob, use Chrome DevTools to record a performance trace on http://localhost:3000 and explain why First Contentful Paint is high.


If the setup is working, the replies should feel grounded. Bob should name actual console messages, actual requests, and actual trace findings. That is the whole point. We are not asking for browser-flavored intuition. We are asking for evidence.

What Breaks When the Setup Is Wrong

The failure modes here are thankfully boring.

• http://127.0.0.1:9222 does not respond: Chrome is not running in debug mode, or another process took the port

• Bob sees the wrong page: you reused a busy browser profile instead of a clean debug profile

• The MCP client cannot launch Chrome itself: attach to a manually started browser with --browser-url, which is exactly the flow in this article

• Bob can inspect too much: you started the session with a normal profile that already had unrelated tabs, cookies, or secrets loaded

That last one is the only part I treat as a real footgun. The server can inspect whatever lives in that browser session. Use a dedicated profile. Keep unrelated tabs out of it. Boring hygiene is still the cheapest security control.

Keep Both Tools

I am not giving up the built-in browser tool. It is fast, convenient, and perfect for quick local checks.

I just do not confuse convenience with debugging depth.

When I want to know whether a page opened, whether a button still works, or whether the layout survived my last CSS change, the built-in browser tool is enough. When I want to know why the page broke, which request failed, what the console said, or where the trace went sideways, I want Chrome DevTools.

My rule is simple: use the built-in browser tool when speed is enough. Use Chrome DevTools when you need evidence.

The nice part is that you do not have to choose one forever. Keep the built-in browser tool for the short path. Add Chrome DevTools MCP for the moments where the browser should stop being a picture and start being a debugger.