I Bridged My Real Logged-In Browser to Chrome's New WebMCP API

Description and use

The author built webmcp-bridge to expose real browser sessions as WebMCP tools, enabling agents to access authenticated content without scraping.

Problem

Server‑side fetchers fail on login walls, 403s, and bot detection, making DOM scraping fragile.

Outcome

15 smoke tests passed; agents can now read authenticated pages and bypass bot checks by calling real browser tools.

Workflow

• 1. Install webmcp-bridge via pip.
• 2. Run the local server (127.0.0.1:18765).
• 3. Include the shim script on any page: <script src="http://127.0.0.1:18765/webmcp.js"></script>.
• 4. The shim fetches tool manifests from /webmcp/tools and registers them with document.modelContext.registerTool().
• 5. Agents discover and call the tools like any other page tool.
• 6. For open_and_read_url, the server enforces a domain allowlist defined in ~/.config/webmcp-bridge/config.json.

Evidence

Chrome's WebMCP proposal (W3C Community Group draft, origin trial from M149) lets a web page declare typed, callable tools via document.modelContext.registerTool() — so an in-browser AI agent can call them directly instead of scraping the DOM.

Source

I built webmcp-bridge — the first bridge from Browser Buddy to the WebMCP API.

Source

Two tools ship out of the box: read_active_tab and open_and_read_url.

Source

Because login walls, 403s, and bot detection defeat server-side fetchers — and DOM scraping is fragile by design.

Source

The server binds 127.0.0.1 only; the shim is same-origin by design.

Source

pip install webmcp-bridge webmcp-bridge # http://127.0.0.1:18765/ — demo page included

Source