Chrome DevTools MCP: Configure Inspection and Form Testing Separately

Start with the evidence you need

If an application has already failed, an agent can inspect its console errors and network responses without submitting the form again. That is a different assignment from reproducing a failure with new input. The second assignment needs interaction access and may create another account, order or saved record.

The Chrome DevTools MCP tool reference separates input, navigation, network inspection and debugging into categories. The server can exclude categories through its configuration options. This gives you a concrete way to remove input tools before an investigation, while keeping tools that retrieve evidence.

For a failed order save, begin by asking for the failed request, response status and associated console error. If those records do not explain the failure, a controlled reproduction can follow. Asking the agent to “fix the order page” from the outset leaves inspection and resubmission mixed together.

Remove input and direct evaluation independently

--no-javascript-evaluation disables the server’s entry points for caller-supplied JavaScript. That includes evaluate_script, the slim-mode evaluate tool, navigation initialization scripts and direct navigation to the javascript:, data: and vbscript: schemes.

The restriction also removes evaluation used only to read data. It does not classify a supplied script as harmless or state-changing. Use take_snapshot for an accessibility-tree text representation or take_screenshot for the rendered page instead. Neither is a replacement for inspecting every internal JavaScript variable.

To remove interaction tools as well, set --category-input=false. The input category includes clicking, filling fields, form filling, key presses, typing and uploads. Removing the category closes more interaction routes than merely telling the agent not to click a particular submit button.

A conventional MCP client configuration for an investigation can look like this:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y", "chrome-devtools-mcp@latest",
        "--no-javascript-evaluation",
        "--category-input=false",
        "--category-emulation=false",
        "--category-performance=false",
        "--category-memory=false",
        "--experimental-devtools=false"
      ]
    }
  }
}

The project’s setup instructions require Node.js LTS, npm and a supported Chrome installation. Update the existing server entry if one is already registered. The example uses the normal tool set; adding --slim would replace it with a reduced set that does not provide this inspection workflow.

Emulation, performance and memory tools are excluded because this assignment does not need them. Navigation remains enabled because its category also contains list_pages and select_page. Debugging remains enabled for console and snapshot tools, but it also contains lighthouse_audit, whose navigation mode reloads the page. This is a reduced-capability configuration, not a documented read-only preset. For observation-only calls, use the client’s supported tool approval controls to restrict individual calls and parameters.

Follow a request from the page to the error

Keep the failed page open in the connected Chrome instance. The list tools normally return records since the last navigation. Set includePreservedMessages or includePreservedRequests when you need preserved records from the last three navigations. If the relevant event is absent, keep the connection open and reproduce it manually with test data before asking the agent to inspect it.

1. List the open pages and identify the intended page ID.
2. Pass that ID as pageId to take_snapshot and list_console_messages. Keep the same page ID for the subsequent message and request lookups.
3. Use the returned message ID with get_console_message to inspect the error in detail.
4. List network requests and use the failed request’s ID with get_network_request to inspect the response.

A suitable assignment is: “Inspect the current page’s console errors and failed network requests. Connect each proposed cause to the evidence. Do not reload, enter data or submit the form.” This defines the work; it does not replace server settings or client-side authorization.

The resulting report should distinguish a failed HTTP response from the interface’s handling of it. A server may reject a request correctly while the page fails to display the reason. Conversely, the interface may show a generic failure because the request never reached the expected endpoint. The agent needs the recorded response and error details to distinguish those possibilities. Reading a failure record does not establish that a later save would succeed.

Allow interaction when the task requires a new submission

For a reproducible form bug, change the argument to --category-input=true and use a fresh snapshot to obtain field UIDs. Fill the test values with fill_form, retrieve another snapshot if the interface changes, and click the intended control using the current UID. Keep direct evaluation disabled if normal input tools are sufficient.

For example, a test registration form can be filled with an already registered test email. Submitting it triggers the application’s own request handler. The next inspection can connect the server’s rejection with the message shown to the user. This is useful reproduction precisely because the application’s JavaScript still runs.

In issue #2726, ITSMERNB reported that version 1.8.0 blocked direct JavaScript URL navigation but still executed code when an existing JavaScript link was clicked. The current configuration documentation explicitly leaves scripts triggered by permitted browser interactions active.

Typing can also change server data before a submit button is pressed. An autosaving form makes “fill but do not submit” an inadequate rule for preventing writes. Use test data and an appropriate test account for that workflow. An account with server-enforced read-only permissions can reject writes, but then it cannot reproduce the full behavior of a normal user’s successful save.

Leave experimental DevTools UI automation off unless the task specifically needs it. When --experimental-devtools is enabled, the agent can automate the DevTools Console, which offers another evaluation route outside the direct-evaluation restriction. Reading console messages through the dedicated inspection tools does not require enabling that UI automation.

Choose which signed-in state the agent receives

The advanced usage guide explains that the default browser has a dedicated MCP profile that persists between runs. A separate browser window is therefore not necessarily a fresh session. If you sign into a service in that profile, its session can remain available in a later run.

The --isolated option uses a temporary profile that is cleaned up when the browser closes. That is useful for public-page testing that should not inherit earlier sign-ins. It does not undo server writes made during the session: signing into a production account and saving a record can still modify that account’s data.

To investigate an existing signed-in browser, Chrome 144 and later provide automatic connection through --autoConnect. Enable remote debugging at chrome://inspect/#remote-debugging, then approve the browser’s connection prompt. The documented access covers all open windows in the selected profile, rather than only the tab you were viewing.

That distinction affects a useful choice. A login-state bug may require the existing profile; a public form layout bug usually does not. For account administration or order handling, a dedicated test account gives the investigation a narrower set of records and operations than a normal administrator session.

Limit destinations without mistaking that for write protection

--allowed-url-pattern, supported with Chrome 149 or later, restricts destinations for navigation and subresource requests. For example, --allowed-url-pattern=https://staging.example.com/* matches that example HTTPS host on its default port. Replace it with the actual target.

If the page calls an API on another host, allowing only the page host can break the application. Authentication and CDN requests may need additional destinations too. A blank page under that configuration may be caused by the restriction rather than the original bug. Inspect the blocked request path before changing application code.

The URL allowlist does not distinguish reads from writes to an allowed destination. A save request to the permitted API can still run. Use destination restrictions to contain where the browser connects, and account permissions to determine what the service accepts from that user.

Check the effective configuration after changing it

Restart the MCP server through the client after editing ordinary launch arguments. Confirm that input and evaluation tools are absent from the offered tool list. If they remain, check whether the client is connected to an old process or another registered server entry.

The configuration reference also supports JSON files with camelCase keys. Command-line arguments take precedence. With --watchConfig, supported tool settings can change without restarting; invalid JSON is logged and leaves the previous configuration in place. Browser launch and connection settings still require a restart.

Changing URL restrictions while connected applies them to future requests and navigation, but does not detach targets already open on newly disallowed URLs. Reconcile the open pages and connected profile when narrowing the job. The official guidance also requires the configuration file and its parent directory to be unwritable by the agent, so the agent cannot simply change the restrictions governing its own access.