Find Why a Page Is Broken: Console and Network Errors

A page that renders but does not work is the slow kind of bug. Nothing looks wrong in a screenshot, so you open DevTools, find the console error, copy it into the chat, then go back for the failed request. This use case hands that loop to the agent. With observers turned on, MCP Browser Extension can read the page's console output and the requests it made, in the same Chrome where you reproduce the bug.

It suits front-end developers checking a staging build, QA testers writing up a bug report, and anyone supporting a site they did not build who needs the actual error, not a description of it.

The demo uses two public practice pages from The Internet, an open source test site: one throws a JavaScript error while it loads, the other has two broken images. Neither page needs a sign-in, and the agent did not type into or submit anything.

The prompt to give the agent

Naming the two pages and the three facts you want back (error, file, line) keeps the answer short. On your own site, name the page and the action that triggers the bug, such as "click Save on the profile form".

What the agent did

Observers are off by default, so the server ran with --enable-observers added to its MCP config. The agent then worked in its own background tab:

navigate     { "url": "https://the-internet.herokuapp.com/javascript_error" }
screenshot   {}
console_logs { "level": "exception" }

navigate     { "url": "https://the-internet.herokuapp.com/broken_images" }
screenshot   {}
console_logs { "level": "error" }
network_log  { "includeResources": true, "urlContains": ".jpg" }

On the first page, the screenshot shows one line of text and nothing else. The page looks fine. console_logs told a different story. It returned one entry at level exception:

Uncaught TypeError: Cannot read properties of undefined (reading 'xyz')
    at loadError (https://the-internet.herokuapp.com/javascript_error:8:52)
    at onload (https://the-internet.herokuapp.com/javascript_error:12:30)

That is the cause, with the function, the file and the line: loadError on line 8 runs from the page's onload handler and reads a property of something that is undefined. Uncaught errors are recorded at level exception, not error, so ask for that level, or leave level out to get everything.

On the second page, two of the three images showed as empty boxes. console_logs at level error named both:

Failed to load img: https://the-internet.herokuapp.com/asdf.jpg
Failed to load img: https://the-internet.herokuapp.com/hjkl.jpg

network_log with includeResources: true listed all three image requests. The two broken ones each transferred 318 bytes, while the working avatar image loaded normally. Image entries come from the browser's Resource Timing data, which carries timing and size but no HTTP status. So the agent reported "a tiny response instead of an image" and did not claim a 404 it could not see.

The result

In one short run the agent came back with three facts a developer can act on: the uncaught TypeError and its line, the two image files that did not load, and the network evidence that they returned almost nothing. No one opened DevTools or copied text between windows.

The output is a starting point, not a fix. The agent saw what the page did in this browser, at this moment. It did not read the server logs, and it cannot tell you why asdf.jpg is missing from the server.

How to try it

1. Follow the quickstart to connect MCP Browser Extension to your agent.
2. Make sure you run version 0.9.29 or later, then add --enable-observers to the server's arguments in your MCP config and reconnect the server. The observer tools reference lists what each tool records.
3. Allow the domain you want to debug. Observers only run on allowed sites.
4. Open or reload the page, then give the agent a prompt like the one above.

The recording hook is installed when the page starts loading, so errors that happen during load are caught. For a tab that was already open before you turned observers on, reload it first.

Variations

• A blank screen after login. Ask the agent to run the sign-in flow on a test account, then read network_log { "failedOnly": true } to find the request that returned a 500. This is where using your own Chrome helps: the bug often only appears with your session.
• A button that does nothing. Click it with the agent, then read console_logs with sinceSeq from the previous call so you only see what the click produced.
• A release check. Open the five most important pages of a staging build and report every exception and every failed request in one list.
• A click that hangs. If a page opens a confirm() dialog, the dialogs tool answers it and records what it said, instead of the click timing out.

For the wider picture, including how this compares with Chrome DevTools MCP, read AI agent debugging: find why a web page is broken.

FAQ

Can an AI agent see JavaScript errors on a page?

Yes, with observers on. console_logs returns console output and uncaught errors from the page, with the message and stack trace, so the agent can name the function and line.

Does network_log show the HTTP status of every request?

It shows method, URL, status and duration for fetch and XMLHttpRequest calls. Scripts, images and stylesheets, added with includeResources, come with timing and size but no status. The main document request and headers are not included.

Is it safe to leave observers on?

They are off by default because the hook patches console, fetch, XMLHttpRequest and the dialog functions on allowed pages. What it records stays in the page until a tool call reads it. Turn it on when you are debugging and keep the allowlist narrow.

Do I need Chrome DevTools open?

No. The agent reads the same information through the extension, in the background tab it opened.