Inspect why a page failed, not just what it looked like. Chrome DevTools MCP connects an agent to page structure, console messages, network requests, and performance traces so a browser symptom can be traced to runtime evidence.
A failed save can originate in the request, server response, or page handling. Collecting those observations together helps distinguish evidence from a plausible explanation.
Test URL, failed save steps, test input, expected response, and the configured Chrome connection.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Chrome DevTools MCP https://github.com/ChromeDevTools/chrome-devtools-mcp Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use Chrome DevTools MCP to reproduce the failed save action on my test page. Inspect the related request and console errors, distinguish client and server failures, and report evidence before suggesting code changes. Expected deliverable: A request/console timeline with evidence-backed causes and a verification plan. Include failed steps and unresolved questions when evidence is insufficient.
Chrome DevTools MCP connects coding agents to a supported Chrome browser for inspection and automation. Its distinctive role is explaining a symptom with runtime evidence: a failed form can be compared with its request and console messages, while a slow page can be investigated through a performance trace. The host reasons about that evidence; the browser tools do not decide the application’s intended behavior.
Page-scoped tools use pageId, obtained from list_pages or a newly created page. Within that page, take_snapshot returns element uids for clicks and form input. These are two different objects: pageId selects the browser target, while uid identifies a control in an observed page state. Correct targeting matters when several development tabs are open.
The official repository includes MCP configuration, a CLI, and browser-operation and specialized debugging Skills. The full browser Skill excludes slim mode; extension and memory tooling have explicit enablement flags. Floatboat can use the corresponding external-agent MCP path after runtime setup. Apache-2.0 covers the project source; Chrome components, host models, and documented usage telemetry require separate consideration.
Choose evidence according to the question: a failed request, a slow rendering path, and growing retained memory need different tools. Page IDs and current snapshots keep those investigations attached to the intended browser target.
Use the request and console tools around a reproduced action to distinguish client validation, transport failure, and a server error. Inspect the particular request rather than treating every console warning as the cause.
A scoped performance trace can show loading and rendering work behind a slow interaction. Compare equivalent device, cache, and network conditions before attributing an improvement to code.
The official Skills cover LCP, accessibility, cookies, and memory. Extension tools require --categoryExtensions, while memory tools require --memoryDebugging in the documented full configuration.
Use the observable symptom to choose the investigation. Request, performance, memory, and extension work need different starting inputs and failure interpretations; a screenshot of the same page cannot substitute for each kind of runtime evidence.
Supply a staging URL, test record, and the action that produces a save error. Target that page, reproduce once, and inspect the related request and console messages. Report whether the request was absent, failed in transport, or received an error response; each points to a different next check.
Provide the page, reported delay, and a repeatable environment. Capture a trace of that scenario and identify the resource or rendering work tied to the delay. Compare a later run under equivalent conditions; a smaller trace file or successful recording is not a performance improvement by itself.
With memory tools enabled, supply a repeatable interaction such as opening and closing the same panel several times. Follow the official memory Skill to compare retained objects and suspected paths. Distinguish temporary allocation from objects that remain reachable after the scenario has completed.
With --categoryExtensions enabled, load an approved unpacked extension using install_extension and retain its returned ID. Inspect its page behavior separately from its background worker; evaluate_script targets a worker with serviceWorkerId rather than pageId. Deliver the affected target and error so a maintainer can reproduce the issue.
The initial workflow below investigates a staging save failure with the full MCP tool set. It needs a supported browser, a visible page target, and exact reproduction inputs; extension and memory flags are unnecessary for this particular request investigation.
Follow the current release’s runtime requirements and documented Chrome connection. The repository officially supports Google Chrome and Chrome for Testing; do not assume arbitrary Chromium variants are covered.
Read the official chrome-devtools Skill and inspect the active MCP tool list. Slim mode has a different surface. When enabling optional categories, restart the server or client as the documentation requires.
Supply the URL, test account where needed, exact steps, visible symptom, and expected outcome. Keep unrelated tabs out of the initial target selection, and avoid secrets in copied request evidence.
This sequence separates page targeting, reproduction, and interpretation. It can end with a client-side failure, server response, or unresolved evidence gap; the useful output is a narrowed cause and a repeatable next check, not an automatic code change.
Call list_pages and retain the target pageId, or obtain one from new_page with the supplied URL. Wait for known form text using wait_for where necessary. Do not assume the first listed tab is the application under investigation.
Use take_snapshot with that pageId to locate the current field and save-button uids. Fill the supplied test data and click using the same pageId. Record the visible error and when it appeared; refresh the snapshot if the form rerendered before the action.
Inspect list_network_requests and list_console_messages for the reproduced interaction, then get_network_request for the relevant request when available. An absent request can point to client validation or a handler problem; an error response requires examining its status and body. Correlation narrows the question but is not proof of root cause.
Return the reproduction steps, page target, visible error, affected request, and relevant console message with credentials redacted. State the leading explanation and remaining uncertainty. Propose the same action as a post-fix check, including what response and page state would demonstrate recovery.
Compare the workflows, operating requirements, and source licenses of these projects.
