Ghostlight vs Weavetab

A side-by-side look at the Ghostlight and Weavetab MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Ghostlight logoGhostlightBrowser Automation · Local subprocess (stdio)Drive your real logged-in browser from any MCP client. Governed or wide open, one portable binary.63GoodAuth: no auth requiredWeavetab logoWeavetabBrowser Automation · Local subprocess (stdio)Open automation engine for AI agents. Control live browsers and desktop apps locally.64GoodAuth: no auth required

Verdict: choose Ghostlight for browser automation work as a local process; choose Weavetab for browser automation as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Ghostlight logoChoose Ghostlight when

  • You need dedicated capabilities in the Browser Automation domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like browser_tabs, browser_navigate, browser_history.
Explore Ghostlight

Weavetab logoChoose Weavetab when

  • You need dedicated capabilities in the Browser Automation domain.
  • You prefer a local stdio subprocess transport.
  • Its auth model fits you: No auth required.
  • You want tools like browser_map, browser_navigate, browser_click.
Explore Weavetab

Feature & specification comparison

Rows where the two servers differ are marked.

SpecGhostlight logoGhostlightWeavetab logoWeavetab
CategoryBrowser AutomationBrowser Automation
Quality signal63/100 · Good64/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNo auth requiredNo auth required
PricingFreeFree
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars13
Directory activity 2 views 0 installs 0 upvotes 0 views 0 installs 0 upvotes
Tools2341

Tools & capabilities

Ghostlight tools 23

  • browser_tabsList, focus, or close this session's tabs. List gives fresh handles from the live browser; with no tab yet it needs none and names those connected.
  • browser_navigateGo to an HTTP(S) URL. Reuses the obvious tab; new_tab true opens a new one.
  • browser_historyGo back or forward, or reload. A new document invalidates target_ and view_ handles, so collect fresh ones.
  • browser_windowSet a tab's zoom or resize its browser window. Either invalidates view_ handles, so take a fresh screenshot before coordinate work.
  • browser_readRead visible page text, including open shadow roots and frames, or one target. To act, get handles from browser_inspect or browser_find.
  • browser_inspectInspect controls or page structure for fresh target_ handles. Scope document returns the outline as a bounded tree, without handles. Form controls also carry their value and what they accept: options, type, limits, hint and group.
  • browser_findFind targets by visible or accessible text and get fresh target_ handles. Fastest when you know the label. Option text finds its dropdown.
  • browser_screenshotCapture the viewport, full page, one target, or a magnified region; returns a view_ handle for coordinate calls.
  • browser_clickClick a target_ handle, a control found by selector, or a point in a view_ screenshot. Needs action; a selector lookup or expect check also needs read. Prefer a target.
  • browser_scrollScroll the page (default down, medium), reveal a target_, or wheel-scroll at a point in a view_ screenshot.
  • browser_hoverHover a target_ handle or a point in a view_ screenshot.
  • browser_fill_formFill 1 to 30 fields in one call; needs write even for unsent drafts. Nothing submits unless submit_target names the control. A value a control cannot take is refused before any field changes, with what it accepts. For credentials, set user_authorized_credentials only on the user's explicit instruction.
  • +11 more on the listing page

Weavetab tools 41

  • browser_mapSnapshot interactive DOM with volatile ref IDs that invalidate after DOM mutations. For complex SPAs (e.g. GitHub dashboards), use `scope` or `query` to reduce tokens. For forms/pagination/sequential loops, ALWAYS use `delta: true` to save 97% tokens. For canvas/WebGL/Figma pages where the DOM has < 5 interactive elements, use `visual: "auto"` to get a numbered screenshot — then use browser_click({ mark: N }) to interact.
  • browser_navigateNavigate to a URL or launch/focus a configured Electron app.
  • browser_clickClick a DOM element. Use browser_canvas for charts/canvas. If stuck_warning=true, stop and use browser_map. Pass mark: N to click a numbered element from browser_map({ visual: true/"auto" }) without any DOM re-scan.
  • browser_typeType text into an input field or currently focused element. If id/selector/label is omitted, automatically types directly into document.activeElement without needing a redundant click or browser_map. If target is already focused, skips click to prevent unfocus bugs.
  • browser_type_secretInject a secret from an environment variable.
  • browser_keyPress a keyboard key.
  • browser_scrollScroll the page.
  • browser_dialogAccept or dismiss JS dialogs (alert, confirm, prompt). Browser sessions only.
  • browser_burstHIGH-SPEED MULTI-ACTION PIPELINE: Executes 2 or more sequential browser actions in a single round-trip without waiting for LLM turns between steps. PREFER THIS over individual single-action calls (e.g. typing + pressing Enter, filling multiple form fields, clicking tabs/buttons then waiting, searching, navigating + reading) to drastically slash latency and token burn. Supports native primitives (browser_click, browser_fill, browser_type, browser_type_secret, browser_navigate, browser_key, browser_scroll, browser_wait, browser_map, etc.) plus ergonomic macro steps (type_and_send, click_and_wait, navigate_and_read, scroll_and_read, fill_form). If compile_from_history: true is passed, automatically compiles recent successful session trail actions into a burst macro.
  • browser_tabsManage browser and Electron app tabs/windows (open, switch, close, list). Specify 'app' when targeting desktop apps (e.g. app: 'discord') to avoid opening web browser.
  • browser_waitPause until a condition is met.
  • browser_captchaAutonomous CAPTCHA detection and solving.
  • +29 more on the listing page

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Ghostlight

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "ghostlight": {
      "command": "npx",
      "args": [
        "-y",
        "ghostlight"
      ]
    }
  }
}

Weavetab

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "weavetab": {
      "command": "npx",
      "args": [
        "-y",
        "@weavetab/mcp"
      ]
    }
  }
}

Frequently asked questions

Ghostlight is categorized under Browser Automation and uses a local stdio subprocess. Weavetab belongs to Browser Automation and uses a local stdio subprocess. Pick Ghostlight for browser automation work and Weavetab for browser automation.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Ghostlight is listed as free. Auth: no auth required. Weavetab is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add ghostlight and weavetab as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Ghostlight has a quality signal of 63/100 (Good) with 2 views, 0 installs and 1 GitHub stars. Weavetab has 64/100 (Good) with 0 views, 0 installs and 3 GitHub stars.