Skip to main content
Glama

Related Servers

Alternatives to chromaphore-mcp

No user-submitted related servers found.

    Related Servers

    • A
      license
      Not graded
      quality
      B
      maintenance
      MCP server that lets AI agents drive the locally installed Chrome or Edge, opening pages, taking compact accessibility-tree snapshots with @e references, and clicking, typing, scrolling, or capturing screenshots. It also exposes multi-account and cross-channel tab switching, tab sync rules, and ad-block/perf statistics.
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      A lean, LLM-first browser automation MCP server that gives Claude (or any MCP client) a real Chromium browser to navigate, interact with, and debug web apps.
      14
      14 npm
      6
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      A local MCP server that lets Claude Code and Codex drive your real, already-logged-in Chrome — reading pages, clicking, typing, filling forms, navigating, managing tabs and taking screenshots — without Playwright. It pairs with a companion extension over a local WebSocket, with an on/off switch and a domain blocklist so the AI acts only where you allow.
      MIT
    • A
      license
      Not graded
      quality
      A
      maintenance
      A 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 npm
      ISC
    • A
      license
      Not graded
      quality
      A
      maintenance
      MCP server to control a real Chrome browser from Claude, enabling navigation, DOM snapshots, clicks, typing, screenshots, and JS execution via a Chrome extension bridge.
      MIT

    TDQS

    B3/5.0

    Scored across 28 tools

    Disambiguation4/5

    Each tool targets a distinct browser capability (navigation, tabs, pointer actions, form controls, lifecycle, recording), and descriptions explicitly delimit the subtle cases (type vs paste vs fill_date, click vs press, observe vs view). The one real soft spot is the trio of observation tools — observe (text listing), view (annotated image, ~1,500 tokens) and screenshot (writes a PNG, 'shows you nothing') — where view and screenshot could be picked wrongly at a glance. Overall boundaries are clear.

    Naming Consistency3/5

    All names are snake_case and readable, but ordering conventions are mixed: noun_verb families (tab_list, tab_new, tab_select, tab_close, browser_open, record_start) sit alongside verb_noun names (fill_date, pick_color) and bare verbs (press, click, type, scroll, navigate, observe, fetch). The grouping by prefix (tab_*, browser_*, record_*) helps, but there is no single predictable pattern.

    Tool Count3/5

    28 tools is on the heavy side of the rubric, though a full browser-automation domain plausibly needs this breadth and nearly every tool covers a distinct interaction. Some niche entries (pick_color, fill_date, fingerprint as a standalone read) could plausibly be folded into broader tools. It sits at the borderline rather than being genuinely bloated.

    Completeness4/5

    Coverage is strong: browser lifecycle and install, tabs, navigation, observation, the full range of input primitives, dialogs, uploads, drag/slider, network fetch and HAR recording. Gaps are minor and workaroundable — no explicit download handling, no cookie/storage management tool (though eval_js can reach app state) and no frame/iframe targeting tool. Agents can proceed without dead ends for most workflows.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues