# Scout MCP Server Browser automation MCP server with 84 tools. Pure CDP, DOM diffing, vision hybrid. **Publisher claimed.** No tool list reported, and Pod has not connected to this server. ## Status Pod has not dialled Scout yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim. ## Connect Published as `ghcr.io/felixgeelhaar/scout:1.10.0` on oci. Runs locally. ## Known issues **13 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 10. ### Most discussed ### Stability + UX bugs surfaced during E2E driving of a Vue/Astro app Feedback after using scout MCP (`scout 1.6.1`) to drive a full E2E walkthrough of a Vue + Astro + Go app (brotwerk). Most-impactful fix at top. ## Stability bugs 1. **Stale CDP node IDs after framework re-render.** `click`, `type`, `fill_form_semantic` cache CDP node refs from prior `annotated_screenshot` / `observe`. When Vue/React reconciles, refs invalidate but tools still use them → cryptic `cdp: error -32000: Could not find node with given id`. Fix: re-resolve selector to live nodeId at a [Read the thread](https://github.com/klarlabs-studio/scout/issues/14) · 2026-05-20 · closed · 1 comment ### Expose video recording (Playwright recordVideo) via MCP ## Problem Scout exposes \`start_recording\` / \`stop_recording\` / \`save_playbook\` / \`replay_playbook\` — but those record an *action playbook* (JSON of clicks/types for replay), not a screen video. For demo / docs / landing-page work, the value is the **video** (MP4 / WebM) that you can embed. Playwright already supports this natively via \`browser.newContext({ recordVideo: { dir, size } })\` — scout just doesn't expose it. ## Workaround Call Playwright directly: \`\`\`js const ctx = a [Read the thread](https://github.com/klarlabs-studio/scout/issues/4) · 2026-05-02 · closed · 1 comment ### CDP connection stability + React compatibility issues ## Summary While using Scout extensively to automate and demo a React SPA dashboard ([go-teamhealthcheck](https://github.com/felixgeelhaar/go-teamhealthcheck)), I encountered several issues that made the experience unreliable. Filing them together since they came up in the same session. ## Environment - Scout MCP server (via Claude Code) - Target: React 19 SPA with react-router-dom v7, served from Go backend on localhost - Both headless and visible modes tested ## Issues ### 1. Frequent CDP [Read the thread](https://github.com/klarlabs-studio/scout/issues/1) · 2026-03-26 · closed · 1 comment ### screenshot: add save_to_disk / output_path so captures return a file path instead of base64 ## Problem `screenshot` and `annotated_screenshot` return a base64 data URL inline. For an agent driving scout on behalf of a user, that image lands in the **agent's** context — it renders for the model but never reaches the human. There is no way to hand the capture over. Encountered while running a scripted end-to-end walkthrough with screenshot milestones: every capture came back as base64, and the user simply saw nothing. ## Current workarounds, both bad 1. **Force an overflow.** Request [Read the thread](https://github.com/klarlabs-studio/scout/issues/79) · 2026-08-01 · closed · 0 comments ### No viewport / device emulation: width params don't set the CSS viewport (responsive testing impossible) ## Summary There is no way to set the browser **viewport size / emulate a device** through the MCP tools. Width parameters that *look* like they should control it (`screenshot.max_width`, `start_screen_recording.width/height`) only affect the **output image / capture frame**, not the page's CSS viewport. As a result, width-based `@media` breakpoints can't be exercised, so mobile/responsive layouts can't be verified. ## Repro 1. `configure { headless: true, fresh: true }` (also reproduces with [Read the thread](https://github.com/klarlabs-studio/scout/issues/47) · 2026-06-28 · closed · 0 comments ### Most recent ### type should report committed value after framework microtask flush ## Problem `type` returns the typed string immediately: ``` {selector: "input[type=email]", value: "x@y.z", action: "typed"} ``` But on frameworks with two-way binding (Vue v-model, Svelte bind:value), the value may be transformed, sanitized, or never committed. Caller has no way to know without a separate `observe`. ## Proposal Mirror what `fill_form_semantic` already does: ``` { selector: "input[type=email]", typed: "x@y.z", committed: "x@y.z", // re-read after rAF + microtas [Read the thread](https://github.com/klarlabs-studio/scout/issues/22) · 2026-05-22 · closed · 0 comments ### annotated_screenshot: add stable node_handle alongside per-call label ## Problem `annotated_screenshot` warns that labels are per-call only — re-shuffled on any DOM mutation. Multi-step flows (annotate → click → annotate again) can't reliably reference the same node, forcing the caller to recompute selectors. ## Proposal Return a stable `node_handle` per element alongside the per-call label number: ``` {label: 7, node_handle: "h_a3f2", selector: "button.mode-tab", text: "Mit Passwort", ...} ``` - `node_handle` valid for as long as the node is alive (weak ref). - [Read the thread](https://github.com/klarlabs-studio/scout/issues/19) · 2026-05-22 · closed · 0 comments ### Form submission silently fails: click_label on type=submit and dispatch_event(submit) don't fire @submit handlers ## Summary Scout cannot drive form submission on a Vue 3 island that uses `@submit.prevent`. The handler never fires; no network request is dispatched; no console error surfaces. Two approaches both silently no-op: 1. `click_label` on the `