[Bug] MCP Server v0.0.82 - Multiple tool implementation failures (window management, PDF, DOM)

[debpramanik]

Description

After comprehensive testing of all 62 BrowserOS MCP tools (v0.0.82), I identified 6 tools with server-side implementation bugs that are not yet tracked as issues. These tools fail consistently with reproducible errors.

Affected Tools & Errors

1. create_window / create_hidden_window

Error: MCP error -32602: Structured content does not match the tool's output schema: data/window must NOT have additional properties

Root Cause: Server returns window data with extra fields not defined in the tool's output schema. The schema has additionalProperties: false but the server response includes fields like incognito, alwaysOnTop, or other Chrome window properties not declared in the schema.

Reproduction:

Call create_window() → Schema validation fails
Call create_hidden_window() → Same schema error

2. move_page / activate_window

Error: Internal error in move_page: CDP error: Browser window not found

Root Cause: The CDP window management implementation appears incomplete. The server cannot resolve window IDs returned by list_windows (which also has schema issues). Window handle mapping between CDP and MCP layer is broken.

Reproduction:

1. Call list_windows() → Returns windows with IDs
2. Call move_page(page=21, windowId=0) → "Browser window not found"
3. Call activate_window(windowId=0) → Same error

3. save_pdf

Error: MCP error -32001: Request timed out

Root Cause: PDF generation via CDP Page.printToPDF hangs indefinitely. Likely missing timeout handling or the CDP command isn't completing for certain page types.

Reproduction:

1. Navigate to any page (e.g., https://the-internet.herokuapp.com/javascript_alerts)
2. Call save_pdf(page=10, path="/tmp/test.pdf")
3. Request times out after 60s

4. get_dom

Error: Internal error in get_dom: CDP error: Could not find node with given id

Root Cause: DOM node resolution fails when using CSS selectors. The server's DOM.querySelector or DOM.querySelectorAll CDP calls aren't properly handling the node ID lifecycle.

Reproduction:

1. Navigate to any page
2. Call get_dom(page=10, selector="h1")
3. Returns "Could not find node with given id"

Environment

• BrowserOS Version: 146.0.7821.31 (macOS)
• MCP Server Version: v0.0.82
• MCP URL: http://127.0.0.1:9002/mcp
• Client: opencode v1.14.33
• OS: macOS (darwin)

Testing Methodology

All 62 tools were tested systematically:

• ✅ 57 tools working correctly
• ❌ 6 tools failing with server-side errors
• ⚠️ drag tool works with coordinates (drag_at) but not element-to-element

Impact

These bugs block common automation workflows:

• Multi-window browser automation
• PDF export/save functionality
• DOM inspection/extraction with selectors
• Window management for complex tab workflows

Related

• PR fix(server): MCP tool fidelity — drag dnd, click react fallback, fill validate, snapshot carousel #864 (fix(server): MCP tool fidelity) is open and addresses drag tool issues
• These 6 tools are not covered by existing issues or PRs

Suggested Fixes

1. Schema errors: Update output schemas to match actual server responses, or strip extra fields before returning
2. Window CDP errors: Fix window ID mapping between CDP Browser.getWindowForTarget and MCP layer
3. PDF timeout: Add proper timeout handling and error recovery for Page.printToPDF
4. DOM errors: Fix DOM.querySelector implementation to properly resolve node IDs

Happy to provide additional test cases or help verify fixes.

[shadowfax92]

Hey Deb Pramanik (@debpramanik) — appreciate the thorough testing and detailed breakdown! Six failing tools is significant. We're tracking this for the next MCP server release. Added the 'bug' label.

[maxim-ultra]

I took a closer look at the window schema part of this issue.

The current server passes raw CDP window metadata into MCP structured output, but the declared window and bounds schemas are narrower. That looks like a credible reason create_window can succeed internally and still fail at the MCP output boundary.

I prepared a focused two-file patch with a regression test. It only makes the window metadata contract forward-compatible and does not touch the other tool schemas or Chromium process code. Would that focused proof be useful here?

[shadowfax92]

Thanks again Deb Pramanik (@debpramanik) for the thorough breakdown — and Maxim Ultra (@maxim-ultra), a focused patch with a regression test for the window-schema boundary would be very welcome, please open the PR. The raw-CDP-metadata-vs-narrower-output-schema diagnosis matches what we'd expect. Keeping this open and tracking it through the next MCP server release.

[shadowfax92]

This is fixed in v0.46.0.

Release: https://github.com/browseros-ai/BrowserOS/releases/tag/v0.46.0

Closing this as completed. If any of these MCP tool failures still reproduce on v0.46.0, please comment with the updated tool/error and I’ll look into it again.