crx-mcp
Related Servers
Alternatives to crx-mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceA local MCP server that lets AI assistants drive your real, already-logged-in Chrome through a browser extension, so agents can read, click, type, navigate, screenshot, inspect network traffic, and manage cookies or storage on pages that require existing sessions. It works without opening a remote-debugging port and keeps all communication on your machine.1 npmISC
- AlicenseNot gradedqualityAmaintenanceA local MCP server that lets AI coding tools drive the user's actual, already-logged-in Chrome browser — snapshotting pages, clicking, typing, navigating, reading content, taking screenshots, and inspecting cookies, network traffic, and console output. Browser automation happens through a Chrome extension using Native Messaging, so no remote-debugging port is exposed and all communication stays on the local machine.1 npmISC
- AlicenseNot gradedqualityCmaintenanceAn MCP Server for Chrome DevTools, following the Chrome DevTools Protocol. Integrates with Claude Desktop and Claude Code.313MIT
- AlicenseBqualityBmaintenanceTurns Chrome into a local MCP server, giving AI agents 51 browser tools to inspect DOM, automate clicks, run JavaScript, audit security and accessibility, mock APIs, extract data, record demos, and more from any MCP client.92459 npmMIT
- AlicenseNot gradedqualityNot gradedmaintenanceAn extension-based MCP server that enables AI assistants to control your existing Chrome browser, leveraging your active login states and settings for automation. It provides over 20 tools for tasks like semantic tab search, screen capture, network monitoring, and direct element interaction.-
- AlicenseAqualityAmaintenanceMCP server + Chrome extension that gives AI coding agents control of your real browser with existing sessions, logins, and cookies. Works with Cursor, Claude, Windsurf.24497 npm58MIT
TDQS
Scored across 23 tools
Each tool targets a distinct context or action: eval tools are separated by target (extension page, content script, service worker), while screenshot/snapshot differ between visual and accessibility representation. The descriptions clearly delineate the boundaries, so misselection is unlikely.
Tool names mix verb-first patterns (eval_extension_page, open_popup, send_message) with noun-first patterns (manifest_validate, storage_get, dnr_rules), and some use bare verbs (click, type, wait_for). This inconsistency is readable but not predictable, placing it at the mixed-conventions level.
With 23 tools, the server is on the heavier side, fitting the borderline 16-25 range. While each tool has a legitimate purpose in the extension-testing domain, the count feels heavy and could potentially be consolidated (e.g., merging DNR-related tools or grouping eval functions).
The tool surface covers the full lifecycle: loading and reloading the extension, evaluating in all contexts, storage, messaging, DNR, permissions, and UI automation. Minor gaps include no dedicated options-page automation or explicit permission manipulation, but agents can work around these via context eval and manifest validation.