MCP Connector

Automate Browser Interactions Locally

Archived open-source MCP server pairing a Node server with browser extensions for local-first browser automation.

Works with chromefirefox

90
Spark score
out of 100
Updated 2 months ago
Version 1.1.1
Models
universal

Add to Favorites

Why it matters

Automate browser interactions with Chrome and Firefox extensions, keeping all data local and supporting audit trails. This MCP server connects clients to real browser tabs for enhanced testing and debugging.

Outcomes

What it gets done

01

Drive browser actions like navigation, typing, and clicking.

02

Capture DOM snapshots and detect changes for testing.

03

Generate screenshots and perform form filling.

04

Debug browser states with page dumps and console capture.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/vb-yetibrowser-mcp | bash

Capabilities

Tools your agent gets

browser_snapshot

Create a snapshot of the current page focused on accessibility

browser_snapshot_diff

Compare the two most recent snapshots to highlight DOM/ARIA changes

browser_navigate

Load a new URL in the connected tab and return the updated snapshot

browser_go_back

Navigate back through history with MCP synchronization

browser_go_forward

Navigate forward through history with MCP synchronization

browser_wait

Pause automation for a specified number of seconds

browser_wait_for

Block until a selector appears (optionally visible) before continuing

browser_press_key

Simulate a keyboard key press on the focused element

+7 tools

Overview

YetiBrowser MCP Server

An archived, open-source MCP server pairing a Node server with Chrome/Firefox extensions for local-first browser automation - 19 tools covering navigation, form filling, screenshots, console logs, and JavaScript evaluation. Check first whether your MCP client already has native browser control before adopting this, since the project is archived and no longer maintained.

What it does

YetiBrowser MCP is a fully open-source implementation of the Browser MCP workflow: a Node-based MCP server paired with Chrome/Firefox browser extensions that lets MCP clients - Codex/Claude Code, Cursor, Windsurf, MCP Inspector, or custom tools - automate a real browser tab locally, with browsing data staying on the user's machine. This project has been archived: it was built to address the lack of built-in browser control in AI agents like Claude and Codex, but those agents now have that capability built in, removing the need for a dedicated MCP-based solution.

When to use - and when NOT to

Given its archived status, first check whether your MCP client already has native browser automation before adopting this - it was designed for clients that lacked that capability. Where it's still relevant, it suits local-first browser automation where transparent, forkable, auditable code matters and browsing data should never leave the device; its Firefox extension is on hold pending fuller Manifest V3 support. It is not a good fit if you need an actively maintained tool, since the project is no longer developed.

Capabilities

Nineteen tools are exposed: browser_snapshot (accessibility-oriented page snapshot), browser_snapshot_diff (diff the two most recent snapshots), browser_navigate, browser_go_back/browser_go_forward, browser_wait and browser_wait_for (block until a selector appears), browser_press_key, browser_click, browser_hover, browser_drag, browser_type, browser_fill_form (multiple inputs, selects, checkboxes, and radios in one call), browser_select_option, browser_screenshot (viewport or full-page via the DevTools protocol), browser_get_console_logs, browser_page_state (forms, storage keys, cookies), browser_connection_info (bridge WebSocket port, connection status, extension version), browser_evaluate (run custom JavaScript and return JSON-serializable results), and browser_handle_dialog (accept or dismiss alert/confirm/prompt dialogs). The repository is organized into a shared TypeScript package, the MCP server package, shared and per-browser extension code, docs, and packaging scripts. The CLI automatically walks WebSocket ports 9010-9020 to find a free one (overridable via --ws-port), and the Chrome extension's connection popup can track that port automatically or be set manually using the value reported by browser_connection_info.

How to install

[mcp_servers.yetibrowser-mcp]
command = "npx"
args = ["-y", "@yetidevworks/server"]

Who it's for

Developers who already have a browser-automation-capable MCP client and specifically want a transparent, local-first, forkable alternative - understanding that the project is archived and no longer maintained. The Chrome extension is installed from the Chrome Web Store and left on Automatic connection mode unless multiple YetiBrowser MCP server instances are running; the Firefox extension remains unavailable until Manifest V3 support outside Nightly builds is common. The MCP server itself can be wired into Codex CLI (via a ~/.codex/config.toml entry), Claude Code (via claude_desktop_config.json), or any other MCP-aware client that can spawn the CLI over stdio, and MCP Inspector can run alongside it for testing and debugging.

Source README

YetiBrowser MCP

YetiBrowser MCP is a fully open-source implementation of the Browser MCP workflow. It links a Node-based MCP server with Chrome/Firefox extensions so Model Context Protocol clients-Codex/Claude Code, Cursor, Windsurf, MCP Inspector, or your own tools-can automate a real browser tab while keeping every byte on your machine and auditable.

Why pick YetiBrowser MCP?

  • Transparent and hackable - no blob downloads. Inspect, fork, and extend every component.
  • Local-first - the extension talks only to a localhost MCP server; browsing data never leaves your device.
  • Cross-browser - shared logic powers both Chrome and Firefox packages (Firefox build is pending better Manifest V3 support, so connection UX may be limited until Mozilla ships full MV3 APIs).
  • Developer-focused tooling - richer console capture, DOM diffing, page-state dumps, and full-page screenshots built for debugging and QA.
  • Production-friendly - scripts and docs for packaging, publishing, and integrating with IDE workflows.

Repository layout

  • packages/shared - shared TypeScript definitions for messages and tool schemas.
  • packages/server - the MCP server that bridges MCP clients to a running browser tab.
  • extensions/shared - shared extension source (background/popup) and assets.
  • extensions/chrome / extensions/firefox - per-browser packaging layers.
  • docs/ - workspace commands, publishing checklists, and feature notes.
  • scripts/ - helper utilities such as package-extensions.sh for release zips.

MCP Tools Available

  • browser_snapshot - capture an accessibility-oriented snapshot of the current page
  • browser_snapshot_diff - compare the two most recent snapshots to highlight DOM/ARIA changes
  • browser_navigate - load a new URL in the connected tab and return an updated snapshot
  • browser_go_back / browser_go_forward - move through history while keeping MCP in sync
  • browser_wait - pause automation for a set number of seconds
  • browser_wait_for - block until a selector appears (optionally visible) before proceeding
  • browser_press_key - simulate a keyboard key press on the focused element
  • browser_click - click the element identified by a CSS selector
  • browser_hover - hover the pointer over the targeted element
  • browser_drag - drag an element onto a drop target for sortable/drag-and-drop UIs
  • browser_type - type text (optionally submitting with Enter) into an editable element
  • browser_fill_form - fill multiple inputs/selects/checkboxes/radios in a single call
  • browser_select_option - choose one or more options in a <select> element
  • browser_screenshot - capture a viewport or full-page screenshot via the DevTools protocol
  • browser_get_console_logs - return recent console output, including errors with stack traces
  • browser_page_state - dump forms, storage keys, and cookies for the connected page
  • browser_connection_info - report bridge WebSocket port, connection status, and extension version
  • browser_evaluate - run custom JavaScript inside the page and return JSON-serializable results
  • browser_handle_dialog - accept or dismiss alert/confirm/prompt dialogs with optional prompt text

MCP Browser Extension Installation

Chrome Browser

Firefox Browser (not currently available)

  • Due to the limited capabilities of Manifest v3 in Firefox stable release, the Firefox extension is on hold until full support is commonly avaialble (outside of Nightly builds).

MCP Server Installation

Codex CLI

  • Edit your ~/.codex/config.toml and add the MCP entry:
    [mcp_servers.yetibrowser-mcp]
    command = "npx"
    args = ["-y", "@yetidevworks/server"]
    
  • Restart codex CLI command; you should see yetibrowser-mcp listing under /mcp tools.
  • If you want to provide a specific port, use this format for the args entry: args = ["-y", "@yetidevworks/server", "--ws-port", "9010"]

Claude Code

  • Make sure the extension is installed and connected to a tab, then start the MCP server with npx -y @yetidevworks/server (or run the locally built CLI).
  • Add the server entry to ~/Library/Application Support/Claude/claude_desktop_config.json (see the example in docs/publishing.md).
  • Restart claude so it picks up the new MCP server; you should see yetibrowser-mcp listed under the /mcp tools menu once the extension connects.

Other MCP-aware clients

  • Any MCP client can connect by spawning the CLI (npx -y @yetidevworks/server) or optionally provide a specific port, e.g. npx -y @yetidevworks/server --ws-port 9010.
  • The server exposes the standard MCP transport over stdio, so use whatever configuration mechanism your client supports to run the command above when a tab is connected.

MCP Inspector

  • For testing and debugging outside a coding agent.
  • npx @modelcontextprotocol/inspector npx -y @yetidevworks/server -- --ws-port 9010 to run and inspect the MCP server in conjunction with the YetiBrowser MCP browser extension.

Troubleshooting

  • The CLI walks ports 9010-9020 until it finds a free one, logging switched to when it advances. Pass --ws-port <port> if you want to pin a specific port instead.
  • The Browser extension popup mirrors that behaviour: leave it on “Automatic” to track the CLI’s port, or choose “Manual” and enter the port reported by browser_connection_info / the CLI log to override it.
  • Simply ask your AI tool about the connection port. For example: what is the yetibrowser mcp connction info?, then set the manual port the port reported.

Documentation & build scripts

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.