Data point: --browser-url against a non-Chromium CDP server — full tool battery passes

[yinnho]

We've been testing how far --browser-url reaches beyond real Chrome by pointing it at aginxbrowser — a browser for AI agents implemented in Rust (own CSS/layout/paint stack, V8 via deno_core for JS, no Chromium) that exposes a CDP server via --cdp-port.

Setup: aginxbrowser --cdp-port 9223 + chrome-devtools-mcp@1.9.0 --browser-url http://127.0.0.1:9223, driven over MCP stdio (initialize → tools/list → tools/call).

Results against v1.9.0:

tool	result
initialize / tools/list	29 tools listed
new_page, list_pages	pass
take_snapshot	pass — the snapshot renders from our synthesized Accessibility.getFullAXTree; the uid tree came out correct (RootWebArea → heading level=1 → StaticText)
evaluate_script	pass (6 * 7 → 42)
take_screenshot	pass (real PNG)
list_network_requests	pass (request log with status codes)
list_console_messages	pass
resize_page	initially failed: Protocol error (Browser.setContentsSize): Unknown Browser method

The one gap was on our side: Browser.setContentsSize — the Chrome ≥129 contents-resize path resize_page uses — wasn't implemented by our CDP server yet. We've now wired it up (and Browser.getWindowForTarget returns the live viewport instead of a fixed 1280×720), after which the whole battery passes.

Two takeaways that might be useful here:

• --browser-url makes the server genuinely engine-agnostic — nothing in the core flow (pages / snapshot / evaluate / screenshot / network / resize) depended on Chrome-only behavior beyond documented CDP methods.
• v1.9.0 tools take a numeric pageId argument (parsed from the list_pages markdown) — worth knowing for anyone scripting the MCP layer directly.

Happy to share the probe script if anyone wants to run the same battery against another CDP server implementation.