What can @iflow-mcp/puppeteer-mcp-server do?

headless-browser-automation-via-mcp, dom-inspection-and-element-selection, screenshot-and-visual-capture, page-navigation-and-url-control, user-interaction-simulation, content-extraction-and-text-parsing, page-wait-and-synchronization, browser-context-and-session-management

@iflow-mcp/puppeteer-mcp-server

MCP ServerFree

Experimental MCP server for browser automation using Puppeteer (inspired by @modelcontextprotocol/server-puppeteer)

Open Source

/ 100

8 capabilities

Capabilities8 decomposed

headless-browser-automation-via-mcp

Medium confidence

Exposes Puppeteer's headless browser control as an MCP server, allowing LLM clients to spawn, navigate, and interact with Chromium instances through standardized tool calls. Implements the Model Context Protocol to translate high-level browser actions (navigate, click, type, screenshot) into Puppeteer API calls, enabling multi-turn browser automation workflows driven by LLM reasoning without direct SDK integration in the client.

Solves for

I want my LLM agent to autonomously browse websites and extract data without writing custom Puppeteer codeI need to automate web scraping, form filling, or testing workflows triggered by Claude or other MCP-compatible LLMsI want to build a browser-automation-as-a-service backend that LLMs can call via standardized tool protocols

Best for

LLM application developers building agents that need web interaction capabilities

Teams integrating browser automation into Claude-based workflows via MCP

Builders prototyping autonomous web scraping or testing agents

Requires

Node.js 14+ (Puppeteer requirement)

Chromium or Chrome browser binary (Puppeteer downloads automatically or uses system installation)

MCP-compatible client (Claude, or custom LLM application with MCP support)

Limitations

No built-in session persistence — each MCP call operates within a single browser context; multi-step workflows require the LLM to maintain state across calls

Puppeteer's headless mode limitations apply: no support for WebRTC, some media playback scenarios, and certain browser APIs unavailable in headless contexts

Experimental status means API surface may change; no guaranteed backward compatibility between versions

What makes it unique

Bridges Puppeteer's imperative browser control API into the declarative MCP tool-calling protocol, allowing LLMs to reason about and execute multi-step browser workflows without SDK coupling. Inspired by @modelcontextprotocol/server-puppeteer but positioned as an experimental alternative with potential architectural differences in tool schema design or browser lifecycle management.

vs alternatives

Provides standardized MCP-based browser automation that integrates seamlessly with Claude and other MCP clients, avoiding the need for custom Puppeteer wrapper code in each LLM application.

dom-inspection-and-element-selection

Medium confidence

Provides tools to query and inspect the current page's DOM structure, returning element metadata (selectors, text content, attributes, visibility state) that enable LLMs to identify and target specific UI elements for interaction. Uses Puppeteer's page.evaluate() to execute JavaScript in the browser context, extracting structured element information and computing CSS/XPath selectors for reliable element targeting across page navigation.

Solves for

I need my LLM agent to understand the structure of a webpage and identify which elements to interact withI want to extract specific text, links, or form fields from a page and return them as structured dataI need to find elements by text content, class, or other attributes when CSS selectors are not stable

Best for

Web scraping agents that need to dynamically locate and extract content

Testing automation where element selectors may vary across page versions

LLM-driven form-filling workflows requiring robust element identification

Requires

Active browser page context from headless-browser-automation-via-mcp

JavaScript execution enabled in Puppeteer (default)

Limitations

JavaScript-dependent — elements rendered by client-side frameworks may not be fully populated until JS execution completes; timing issues can cause stale DOM snapshots

Selector stability not guaranteed — dynamically-generated class names or IDs may change between page loads, requiring fallback strategies

Large DOM trees (10k+ elements) can cause performance degradation in serialization and transmission

What makes it unique

Exposes DOM inspection as an MCP tool rather than requiring the LLM to write JavaScript; abstracts selector computation and element metadata extraction into a single call, reducing the cognitive load on the LLM for page structure understanding.

vs alternatives

Simpler for LLMs than raw Puppeteer.evaluate() calls because it returns pre-structured element metadata and auto-generates stable selectors, reducing trial-and-error in element targeting.

screenshot-and-visual-capture

Medium confidence

Captures the current viewport or full-page screenshots as PNG/JPEG images, optionally with element highlighting or region clipping. Implements Puppeteer's page.screenshot() with configurable viewport dimensions, device emulation, and clip regions, enabling LLMs to visually inspect page state and verify automation outcomes without relying solely on DOM inspection.

Solves for

I want my LLM agent to take a screenshot to verify that a page loaded correctly or an action succeededI need to capture specific regions of a page for visual analysis or debuggingI want to emulate different device viewports (mobile, tablet, desktop) and capture responsive layouts

Best for

Visual verification in browser automation workflows

Testing agents that need to assert visual correctness

Debugging LLM-driven automation by inspecting rendered output

Requires

Active browser page context

Sufficient memory for image buffer allocation

MCP client capable of receiving and processing binary image data

Limitations

Screenshot generation adds latency (typically 200-500ms per capture) and memory overhead for large pages

Image transmission over MCP adds bandwidth cost; no built-in compression or progressive loading

Headless rendering may differ from headed browser rendering (fonts, animations, some CSS effects)

What makes it unique

Integrates screenshot capture as an MCP tool, allowing LLMs to request visual snapshots as part of their reasoning loop without explicit Puppeteer API knowledge. Supports device emulation profiles to test responsive designs across form factors.

vs alternatives

Provides visual feedback to LLMs during automation, enabling them to adapt behavior based on rendered output rather than relying solely on DOM structure, improving robustness in dynamic or visually-driven workflows.

page-navigation-and-url-control

Medium confidence

Manages browser navigation including goto(), back(), forward(), and reload() operations with configurable wait conditions (waitUntil: 'load', 'domcontentloaded', 'networkidle'). Implements Puppeteer's navigation API with timeout handling and error reporting, enabling LLMs to traverse multi-page workflows and handle navigation failures gracefully.

Solves for

I want my LLM agent to navigate to a specific URL and wait for the page to fully load before proceedingI need to handle browser back/forward navigation in multi-step workflowsI want to reload a page and retry operations if they fail due to network issues

Best for

Multi-page web scraping workflows requiring sequential navigation

Testing agents that simulate user navigation patterns

LLM-driven workflows with conditional branching based on page content

Requires

Active browser context

Network connectivity to target URLs

Timeout configuration (default typically 30s)

Limitations

Navigation timeouts are fixed per call; no adaptive timeout based on page complexity

Redirect chains may not be fully resolved if intermediate pages trigger JavaScript navigation

Network errors during navigation may leave the browser in an inconsistent state; no automatic recovery

What makes it unique

Exposes Puppeteer's navigation primitives as MCP tools with configurable wait strategies, allowing LLMs to reason about page load states and handle navigation failures as part of their decision-making loop.

vs alternatives

Simpler for LLMs than raw Puppeteer navigation because it abstracts wait-condition logic and provides structured error feedback, reducing the need for LLMs to implement retry logic manually.

user-interaction-simulation

Medium confidence

Simulates user interactions including click(), type(), press() (keyboard), hover(), and focus() operations on page elements. Implements Puppeteer's input APIs with selector-based targeting, allowing LLMs to trigger form submissions, button clicks, and keyboard navigation without direct JavaScript injection. Supports both CSS selector and XPath targeting for element location.

Solves for

I want my LLM agent to fill out and submit web forms by typing into fields and clicking buttonsI need to simulate keyboard navigation (Tab, Enter, Escape) for accessibility testingI want to trigger hover states or focus events to reveal dynamic UI elements

Best for

Form automation and data entry workflows

Testing agents validating interactive UI behavior

Web scraping workflows requiring interaction to load dynamic content

Requires

Active browser page context

Valid CSS selector or XPath for target element

Element must be visible and interactive (not disabled, not hidden)

Limitations

Selector-based targeting requires stable element selectors; dynamic or obfuscated selectors may fail

Type() operation is character-by-character and slower than direct value assignment; may not trigger all input events

No support for drag-and-drop, file uploads, or complex gesture interactions

What makes it unique

Abstracts Puppeteer's input APIs into declarative MCP tools, allowing LLMs to specify interactions at a high level (click button, type text) without managing low-level event handling or timing concerns.

vs alternatives

More reliable than raw JavaScript injection for form filling because it uses Puppeteer's native input simulation, which properly triggers browser event handlers and respects form validation logic.

content-extraction-and-text-parsing

Medium confidence

Extracts text content, HTML, and structured data from the current page using Puppeteer's page.evaluate() to execute JavaScript queries. Supports extracting all text, specific element text, HTML snippets, and running custom JavaScript to parse page content. Returns extracted content as plain text, HTML, or JSON-structured data depending on the extraction query.

Solves for

I want my LLM agent to extract all text from a page for summarization or analysisI need to parse structured data (product listings, search results) from a page and return it as JSONI want to extract specific HTML sections for further processing or storage

Best for

Web scraping workflows extracting content for analysis or storage

LLM-driven content aggregation and summarization

Data extraction from semi-structured web pages

Requires

Active browser page context

JavaScript execution enabled

Sufficient memory for content buffering

Limitations

Custom JavaScript extraction requires the LLM to write or the server to support templated queries; no automatic schema inference

Large pages with extensive text may produce output exceeding MCP message size limits; no built-in pagination

Dynamically-loaded content (infinite scroll, lazy loading) may not be captured unless explicitly scrolled and waited for

What makes it unique

Provides both templated extraction (all text, specific selectors) and custom JavaScript evaluation as MCP tools, allowing LLMs to request extraction at varying levels of specificity without writing Puppeteer code.

vs alternatives

More flexible than static HTML parsing because it executes JavaScript in the browser context, capturing dynamically-rendered content and allowing custom extraction logic without re-implementing page-specific parsers.

page-wait-and-synchronization

Medium confidence

Provides tools to wait for specific conditions before proceeding: waitForSelector() (element appears), waitForNavigation() (page navigation completes), waitForFunction() (custom JavaScript condition), and waitForTimeout() (fixed delay). Implements Puppeteer's wait APIs with configurable timeouts, enabling LLMs to synchronize automation steps with asynchronous page behavior (AJAX requests, animations, dynamic content loading).

Solves for

I want my LLM agent to wait for a specific element to appear before interacting with itI need to wait for a page navigation to complete after clicking a linkI want to wait for a custom condition (e.g., 'loading spinner disappears') before proceeding

Best for

Automation workflows with asynchronous page behavior (SPAs, AJAX-heavy sites)

Testing agents that need to synchronize with dynamic content loading

Workflows requiring robust timing without hardcoded delays

Requires

Active browser page context

Timeout configuration (default typically 30s)

For waitForFunction: valid JavaScript code

Limitations

Timeout-based waiting can mask underlying issues; if a condition never occurs, the agent must handle timeout errors

Custom JavaScript conditions (waitForFunction) require the LLM to write valid JavaScript; syntax errors will cause failures

No built-in exponential backoff or retry logic; timeouts are fixed per call

What makes it unique

Exposes Puppeteer's wait primitives as MCP tools, allowing LLMs to reason about and declare wait conditions as part of their automation plan rather than embedding timing logic in interaction sequences.

vs alternatives

More robust than fixed delays because it waits for actual conditions to occur, reducing flakiness in automation workflows and allowing LLMs to adapt to varying page load times.

browser-context-and-session-management

Medium confidence

Manages browser lifecycle including launching, closing, and resetting browser contexts. Implements Puppeteer's browser and page lifecycle APIs, allowing LLMs to control when browser instances are created/destroyed and manage session state (cookies, local storage, authentication). Supports context isolation for parallel workflows or test isolation.

Solves for

I want to launch a fresh browser instance for a new automation workflowI need to preserve session state (cookies, auth tokens) across multiple page navigationsI want to reset the browser to a clean state between test runs

Best for

Multi-step automation workflows requiring session persistence

Testing agents that need isolated browser contexts

Workflows with authentication or stateful interactions

Requires

Node.js process with sufficient memory (typically 100-200MB per browser instance)

Chromium/Chrome binary available

Permissions to spawn child processes

Limitations

Single-instance design means concurrent workflows may queue or conflict; no native multi-instance pooling

Browser launch time (typically 1-3s) adds latency to workflow initialization

Memory usage grows with browser instance lifetime; no automatic garbage collection or memory limits

What makes it unique

Exposes browser lifecycle as MCP tools, allowing LLMs to explicitly manage browser creation and teardown rather than relying on implicit lifecycle management, enabling better resource control and session isolation.

vs alternatives

Provides explicit session management that LLMs can reason about, improving predictability and enabling workflows that require session persistence or context isolation across multiple operations.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Related Artifactssharing capabilities

Artifacts that share capabilities with @iflow-mcp/puppeteer-mcp-server, ranked by overlap. Discovered automatically through the match graph.

MCP Server31

puppeteer-mcp-server

Experimental MCP server for browser automation using Puppeteer (inspired by @modelcontextprotocol/server-puppeteer)

screenshot-and-visual-captureheadless-browser-automation-via-mcpwebpage-navigation-and-interaction

3 shared capabilities

MCP Server25

puppeteer-mcp-server

Experimental MCP server for browser automation using Puppeteer (inspired by @modelcontextprotocol/server-puppeteer)

headless-browser-automation-via-mcpscreenshot-and-visual-capturedom-element-interaction-and-querying

3 shared capabilities

MCP Server27

@hisma/server-puppeteer

Fork and update (v0.6.5) of the original @modelcontextprotocol/server-puppeteer MCP server for browser automation using Puppeteer.

headless-browser-automation-via-mcpdom-element-interaction-and-manipulation

2 shared capabilities

MCP Server22

ScreenshotMCP

** - Capture website screenshots including full page, elements, and device specific sizes.

targeted element screenshot extractionfull-page website screenshot capture

2 shared capabilities

MCP Server25

@mseep/puppeteer-mcp-server

Experimental MCP server for browser automation using Puppeteer (inspired by @modelcontextprotocol/server-puppeteer)

headless-browser-automation-via-mcpscreenshot-and-visual-capture

2 shared capabilities

Product29

Cheat Layer

Empower your growth with intuitive, AI-driven cloud...

headless browser automation with visual element targeting

1 shared capability

Best For

✓LLM application developers building agents that need web interaction capabilities
✓Teams integrating browser automation into Claude-based workflows via MCP
✓Builders prototyping autonomous web scraping or testing agents
✓Web scraping agents that need to dynamically locate and extract content
✓Testing automation where element selectors may vary across page versions
✓LLM-driven form-filling workflows requiring robust element identification
✓Visual verification in browser automation workflows
✓Testing agents that need to assert visual correctness

Known Limitations

⚠No built-in session persistence — each MCP call operates within a single browser context; multi-step workflows require the LLM to maintain state across calls
⚠Puppeteer's headless mode limitations apply: no support for WebRTC, some media playback scenarios, and certain browser APIs unavailable in headless contexts
⚠Experimental status means API surface may change; no guaranteed backward compatibility between versions
⚠Single-browser-instance design — concurrent requests from multiple LLM clients may queue or conflict; no native multi-instance pooling
⚠Network latency between MCP server and client adds overhead for screenshot/DOM inspection operations
⚠JavaScript-dependent — elements rendered by client-side frameworks may not be fully populated until JS execution completes; timing issues can cause stale DOM snapshots

Requirements

Node.js 14+ (Puppeteer requirement)Chromium or Chrome browser binary (Puppeteer downloads automatically or uses system installation)MCP-compatible client (Claude, or custom LLM application with MCP support)Network connectivity between MCP client and serverActive browser page context from headless-browser-automation-via-mcpJavaScript execution enabled in Puppeteer (default)Active browser page contextSufficient memory for image buffer allocation

Input / Output

Accepts: URL strings, CSS selectors or XPath expressions, Text input for form fields, Keyboard/mouse action specifications, CSS selectors, XPath expressions, Text content patterns, Element attribute filters, Viewport dimensions (width, height), Device emulation profile (mobile, tablet, desktop), Clip region coordinates (x, y, width, height), Image format preference (png, jpeg), URL string (http/https), Wait condition enum (load, domcontentloaded, networkidle), Timeout duration in milliseconds, CSS selector or XPath string, Text input for type() operation, Keyboard key names (Enter, Tab, Escape, etc.), Coordinates for click() operation, CSS selector for element targeting, JavaScript code snippet for custom extraction, Extraction mode enum (text, html, json), CSS selector (for waitForSelector), JavaScript code snippet (for waitForFunction), Navigation options (for waitForNavigation), Browser launch options (headless, viewport, user agent), Context isolation flags

Produces: PNG/JPEG screenshots, HTML DOM snapshots, Extracted text content, JSON-structured page metadata, JSON array of element metadata (selector, text, attributes, position), HTML snippet of matched elements, Computed CSS selector strings, PNG image buffer, JPEG image buffer, Base64-encoded image string, Navigation success/failure status, Final URL after redirects, HTTP status code, Error message if navigation failed, Interaction success/failure status, Error message if element not found or interaction failed, Plain text string, HTML string, JSON object or array, Structured data with metadata, Success/timeout status, Element reference (for waitForSelector), Error message if condition not met, Browser instance ID, Session state metadata, Launch success/failure status

UnfragileRank

Adoption15%(30% weight)

Quality25%(25% weight)

Ecosystem30%(25% weight)

Match Graph10%(15% weight)

Freshness75%(5% weight)

UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.

Type: MCP Server

8 capabilities

Visit @iflow-mcp/puppeteer-mcp-server→

Package Details

npm

Registry

0.7.2

Version

Weekly Downloads

About

Experimental MCP server for browser automation using Puppeteer (inspired by @modelcontextprotocol/server-puppeteer)

Alternatives to @iflow-mcp/puppeteer-mcp-server

wink-embeddings-sg-100d24Repository

100-dimensional English word embeddings for wink-nlp

Compare →

voyage-ai-provider30API

Voyage AI Provider for running Voyage AI models with Vercel AI SDK

Compare →

@vibe-agent-toolkit/rag-lancedb27Agent

LanceDB implementation of RAG interfaces for vibe-agent-toolkit

Compare →

vectra41Repository

A lightweight, file-backed vector database for Node.js and browsers with Pinecone-compatible filtering and hybrid BM25 search.

Compare →

Are you the builder of @iflow-mcp/puppeteer-mcp-server?

Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.

Claim this artifact →Verification via email

Get the weekly brief

New tools, rising stars, and what's actually worth your time. No spam.

Data Sources

mcp registry

Looking for something else?

Search →

Capabilities8 decomposed

headless-browser-automation-via-mcp

Medium confidence

Solves for

Best for

LLM application developers building agents that need web interaction capabilities

Teams integrating browser automation into Claude-based workflows via MCP

Builders prototyping autonomous web scraping or testing agents

Requires

Node.js 14+ (Puppeteer requirement)

Chromium or Chrome browser binary (Puppeteer downloads automatically or uses system installation)

MCP-compatible client (Claude, or custom LLM application with MCP support)

Limitations

No built-in session persistence — each MCP call operates within a single browser context; multi-step workflows require the LLM to maintain state across calls

Puppeteer's headless mode limitations apply: no support for WebRTC, some media playback scenarios, and certain browser APIs unavailable in headless contexts

Experimental status means API surface may change; no guaranteed backward compatibility between versions

What makes it unique

vs alternatives

Provides standardized MCP-based browser automation that integrates seamlessly with Claude and other MCP clients, avoiding the need for custom Puppeteer wrapper code in each LLM application.

dom-inspection-and-element-selection

Medium confidence

Solves for

Best for

Web scraping agents that need to dynamically locate and extract content

Testing automation where element selectors may vary across page versions

LLM-driven form-filling workflows requiring robust element identification

Requires

Active browser page context from headless-browser-automation-via-mcp

JavaScript execution enabled in Puppeteer (default)

Limitations

JavaScript-dependent — elements rendered by client-side frameworks may not be fully populated until JS execution completes; timing issues can cause stale DOM snapshots

Selector stability not guaranteed — dynamically-generated class names or IDs may change between page loads, requiring fallback strategies

Large DOM trees (10k+ elements) can cause performance degradation in serialization and transmission

What makes it unique

vs alternatives

Simpler for LLMs than raw Puppeteer.evaluate() calls because it returns pre-structured element metadata and auto-generates stable selectors, reducing trial-and-error in element targeting.

screenshot-and-visual-capture

Medium confidence

Solves for

Best for

Visual verification in browser automation workflows

Testing agents that need to assert visual correctness

Debugging LLM-driven automation by inspecting rendered output

Requires

Active browser page context

Sufficient memory for image buffer allocation

MCP client capable of receiving and processing binary image data

Limitations

Screenshot generation adds latency (typically 200-500ms per capture) and memory overhead for large pages

Image transmission over MCP adds bandwidth cost; no built-in compression or progressive loading

Headless rendering may differ from headed browser rendering (fonts, animations, some CSS effects)

What makes it unique

vs alternatives

page-navigation-and-url-control

Medium confidence

Solves for

Best for

Multi-page web scraping workflows requiring sequential navigation

Testing agents that simulate user navigation patterns

LLM-driven workflows with conditional branching based on page content

Requires

Active browser context

Network connectivity to target URLs

Timeout configuration (default typically 30s)

Limitations

Navigation timeouts are fixed per call; no adaptive timeout based on page complexity

Redirect chains may not be fully resolved if intermediate pages trigger JavaScript navigation

Network errors during navigation may leave the browser in an inconsistent state; no automatic recovery

What makes it unique

vs alternatives

Simpler for LLMs than raw Puppeteer navigation because it abstracts wait-condition logic and provides structured error feedback, reducing the need for LLMs to implement retry logic manually.

user-interaction-simulation

Medium confidence

Solves for

Best for

Form automation and data entry workflows

Testing agents validating interactive UI behavior

Web scraping workflows requiring interaction to load dynamic content

Requires

Active browser page context

Valid CSS selector or XPath for target element

Element must be visible and interactive (not disabled, not hidden)

Limitations

Selector-based targeting requires stable element selectors; dynamic or obfuscated selectors may fail

Type() operation is character-by-character and slower than direct value assignment; may not trigger all input events

No support for drag-and-drop, file uploads, or complex gesture interactions

What makes it unique

vs alternatives

More reliable than raw JavaScript injection for form filling because it uses Puppeteer's native input simulation, which properly triggers browser event handlers and respects form validation logic.

content-extraction-and-text-parsing

Medium confidence

Solves for

Best for

Web scraping workflows extracting content for analysis or storage

LLM-driven content aggregation and summarization

Data extraction from semi-structured web pages

Requires

Active browser page context

JavaScript execution enabled

Sufficient memory for content buffering

Limitations

Custom JavaScript extraction requires the LLM to write or the server to support templated queries; no automatic schema inference

Large pages with extensive text may produce output exceeding MCP message size limits; no built-in pagination

Dynamically-loaded content (infinite scroll, lazy loading) may not be captured unless explicitly scrolled and waited for

What makes it unique

vs alternatives

page-wait-and-synchronization

Medium confidence

Solves for

Best for

Automation workflows with asynchronous page behavior (SPAs, AJAX-heavy sites)

Testing agents that need to synchronize with dynamic content loading

Workflows requiring robust timing without hardcoded delays

Requires

Active browser page context

Timeout configuration (default typically 30s)

For waitForFunction: valid JavaScript code

Limitations

Timeout-based waiting can mask underlying issues; if a condition never occurs, the agent must handle timeout errors

Custom JavaScript conditions (waitForFunction) require the LLM to write valid JavaScript; syntax errors will cause failures

No built-in exponential backoff or retry logic; timeouts are fixed per call

What makes it unique

vs alternatives

More robust than fixed delays because it waits for actual conditions to occur, reducing flakiness in automation workflows and allowing LLMs to adapt to varying page load times.

browser-context-and-session-management

Medium confidence

Solves for

Best for

Multi-step automation workflows requiring session persistence

Testing agents that need isolated browser contexts

Workflows with authentication or stateful interactions

Requires

Node.js process with sufficient memory (typically 100-200MB per browser instance)

Chromium/Chrome binary available

Permissions to spawn child processes

Limitations

Single-instance design means concurrent workflows may queue or conflict; no native multi-instance pooling

Browser launch time (typically 1-3s) adds latency to workflow initialization

Memory usage grows with browser instance lifetime; no automatic garbage collection or memory limits

What makes it unique

vs alternatives

Provides explicit session management that LLMs can reason about, improving predictability and enabling workflows that require session persistence or context isolation across multiple operations.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Alternatives to @iflow-mcp/puppeteer-mcp-server

wink-embeddings-sg-100d24Repository

100-dimensional English word embeddings for wink-nlp

Compare →

voyage-ai-provider30API

Voyage AI Provider for running Voyage AI models with Vercel AI SDK

Compare →

@vibe-agent-toolkit/rag-lancedb27Agent

LanceDB implementation of RAG interfaces for vibe-agent-toolkit

Compare →

vectra41Repository

A lightweight, file-backed vector database for Node.js and browsers with Pinecone-compatible filtering and hybrid BM25 search.

Compare →

@iflow-mcp/puppeteer-mcp-server

Capabilities8 decomposed

headless-browser-automation-via-mcp

dom-inspection-and-element-selection

screenshot-and-visual-capture

page-navigation-and-url-control

user-interaction-simulation

content-extraction-and-text-parsing

page-wait-and-synchronization

browser-context-and-session-management

Related Artifactssharing capabilities

puppeteer-mcp-server

puppeteer-mcp-server

@hisma/server-puppeteer

ScreenshotMCP

@mseep/puppeteer-mcp-server

Cheat Layer

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to @iflow-mcp/puppeteer-mcp-server

Are you the builder of @iflow-mcp/puppeteer-mcp-server?

Get the weekly brief

Data Sources

@iflow-mcp/puppeteer-mcp-server

Capabilities8 decomposed

headless-browser-automation-via-mcp

dom-inspection-and-element-selection

screenshot-and-visual-capture

page-navigation-and-url-control

user-interaction-simulation

content-extraction-and-text-parsing

page-wait-and-synchronization

browser-context-and-session-management

Related Artifactssharing capabilities

puppeteer-mcp-server

puppeteer-mcp-server

@hisma/server-puppeteer

ScreenshotMCP

@mseep/puppeteer-mcp-server

Cheat Layer

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to @iflow-mcp/puppeteer-mcp-server

Are you the builder of @iflow-mcp/puppeteer-mcp-server?

Get the weekly brief

Data Sources