CDPM vs Weavetab

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

CDPM logoCDPMBrowser Automation · Local subprocess (stdio)Shares numbered, logged-in Chrome instances over CDP across multiple Claude Code sessions, with per-tab command queues. Local stdio server.65GreatAuth: 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 CDPM 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?

CDPM logoChoose CDPM 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_status, browser_launch, browser_close.
Explore CDPM

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.

SpecCDPM logoCDPMWeavetab logoWeavetab
CategoryBrowser AutomationBrowser Automation
Quality signal65/100 · Great64/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 stars33
Directory activity 9 views 0 installs 0 upvotes 0 views 0 installs 0 upvotes
Tools3641

Tools & capabilities

CDPM tools 36

  • browser_statusShows running Chrome slots (1-30) with their tabs, opener, last action and one-line summary. Pass slot for just that slot.
  • browser_launchStarts slot Chrome. Call only when the user explicitly asks (other tools never start a closed slot). Without slot, uses the lowest free slot. If already running, just attaches. The user decides windowed (visible) vs headless (hidden): headless: true only if they say "headless/hidden". If unstated, don't guess; ask first, then call with headless. Starting a closed slot without headless only returns a confirmation request. Start several slots at once with slots (list) or count (lowest first). For different jobs per slot, after launching give each slot its own subagent in parallel.
  • browser_closeCloses slot Chrome cleanly (session and cookies saved). The profile (logins) is kept. Reports if another agent used it recently.
  • browser_tabsSlot tab list: number, ID, title, URL, opener, last action, per-tab summary (updated only by actions with summary). "·front" marks the tab currently in front in its window (one per window).
  • browser_tab_newOpens a new tab in the slot and returns its ID. When agents share a slot, open your own tab and work only by its ID to avoid mixing.
  • browser_tab_closeCloses a tab. tab is required.
  • browser_tab_selectBrings a tab to the front of its Chrome window. Changes what the user sees, so use only when the user wants it. (Background tabs can be read, operated and captured; no need to bring them forward to work.)
  • browser_snapshotReads the tab as accessibility-tree text. Clickable/typable elements get refs like [e12]. Long pages are split; only page 1 (top) is shown (page=2 to continue; refs stay the same across pages). find="text" shows only matching elements with their parent context; ref="e40" shows only that element's subtree. Refs change when the page changes, so re-snapshot before acting.
  • browser_textReads the page body text (main/article if present). With ref, only that element's text. Shorter and easier than a snapshot for articles/documents. Use page for long text.
  • browser_screenshotCaptures the visible area of the tab as PNG, even background tabs (without switching). Never changes window size or viewport, so full-page capture is unsupported (scroll then capture, or use snapshot/text).
  • browser_navigateNavigates the tab to a URL and waits for the body to load.
  • browser_backGo back.
  • +24 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.

CDPM

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

Weavetab

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

Frequently asked questions

CDPM is categorized under Browser Automation and uses a local stdio subprocess. Weavetab belongs to Browser Automation and uses a local stdio subprocess. Pick CDPM 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.

CDPM 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 igelharine-cdpm and weavetab as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, CDPM has a quality signal of 65/100 (Great) with 9 views, 0 installs and 3 GitHub stars. Weavetab has 64/100 (Good) with 0 views, 0 installs and 3 GitHub stars.