Release Notes
Fixes
- WebMCP tools now surface in
webmcp_list_tools within milliseconds of WebMCP.toolsAdded, instead of 2-17 seconds later or never: open_tab and the tab-lifecycle listener enabled the CDP domains before starting the per-tab event listeners. Enabling is exactly what makes Chrome emit its authoritative replay — WebMCP.enable re-emits the whole toolsAdded list, Debugger.enable replays scriptParsed, and so on — and tokio::sync::broadcast delivers nothing retroactively, so every one of those events went to zero subscribers and was dropped permanently. Nothing retriggers the replay once the page is already loaded, which is why the cache stayed empty until the next navigation happened to purge-and-resync it (the observed 2-17 s spread is just "whenever that navigation came"). Ordering is now subscribe → attach handles → enable, in both open_tab and tab_lifecycle. Measured on Chrome 153 against https://www.knot.kz/: webmcp_list_tools reflects a new tool in 1-491 ms after open_tab returns and 42-89 ms after a same-document #/contact navigation (6/6 rounds), against a hard 25 s timeout before the fix. As a side effect the listeners also now capture the Runtime/Debugger replay (scriptParsed, executionContextCreated), so those caches are more complete than before.
- A dropped-event gap can no longer leave a stale tool cache: the WebMCP and Page listeners now rebuild the tool cache from the source whenever the event channel reports a lag (
CdpError::Lagged, new in cdp-lite 0.3). A lag drops an unknown mix of toolsAdded and toolsRemoved, so the cache is cleared and WebMCP.enable is re-sent rather than patched. Non-lag errors deliberately do not trigger this — they must not wipe a cache that is still valid. Invocations survive, as they do on navigation. This is the last line of defence behind the ordering fix above; no lag was ever observed in measurement (see below), so it is hardening rather than a fix.
Changed
cdp-browser-lite 0.4 (from 0.3.5) and cdp-lite 0.3 (from 0.2.0). The re-exported CdpError gains Lagged { skipped: u64 } and is #[non_exhaustive]; cdp-lite's shared event ring grew from 128 to 4096 (EVENT_CHANNEL_CAPACITY, overridable with *_with_capacity).
Notes
- Investigation instrumented both crates with epoch-microsecond arrival timestamps (since removed). Wire-to-listener latency was 140 µs and the broadcast channel never lagged (0 occurrences across a 6-round soak), so the earlier "slow listener / channel overflow" hypothesis was refuted — the loss was in the subscribe/enable ordering, not in the transport.
Install chrome-debug-mcp 1.5.5
Install prebuilt binaries via shell script
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/raultov/chrome-debug-mcp/releases/download/v1.5.5/chrome-debug-mcp-installer.sh | sh
Install prebuilt binaries via powershell script
powershell -ExecutionPolicy Bypass -c "irm https://github.com/raultov/chrome-debug-mcp/releases/download/v1.5.5/chrome-debug-mcp-installer.ps1 | iex"
Install prebuilt binaries via Homebrew
brew install raultov/tap/chrome-debug-mcp
Install prebuilt binaries into your npm project
npm install @raultov/chrome-debug-mcp@1.5.5
Download chrome-debug-mcp 1.5.5
