Skip to main content
Glama
freelw

Puppeteer MCP Server

by freelw
OverviewSchemaRelated ServersScoreDiscussions
Local

Puppeteer MCP Server

This MCP server provides browser automation capabilities through Puppeteer, allowing interaction with both new browser instances and existing Chrome windows.

Acknowledgment

This project is an experimental implementation inspired by @modelcontextprotocol/server-puppeteer. While it shares similar goals and concepts, it explores alternative approaches to browser automation through the Model Context Protocol.

Related MCP server: Chrome DevTools MCP

Features

  • Navigate web pages

  • Take screenshots

  • Click elements

  • Fill forms

  • Select options

  • Hover elements

  • Execute JavaScript

  • Smart Chrome tab management:

    • Connect to active Chrome tabs

    • Preserve existing Chrome instances

    • Intelligent connection handling

Project Structure

/
├── src/
│   ├── config/        # Configuration modules
│   ├── tools/         # Tool definitions and handlers
│   ├── browser/       # Browser connection management
│   ├── types/         # TypeScript type definitions
│   ├── resources/     # Resource handlers
│   └── server.ts      # Server initialization
├── index.ts          # Entry point
└── README.md        # Documentation

Installation

Option 1: Install from npm

npm install -g puppeteer-mcp-server

You can also run it directly without installation using npx:

npx puppeteer-mcp-server

Option 2: Install from source

  1. Clone this repository or download the source code

  2. Install dependencies:

npm install

  1. Build the project:

npm run build

  1. Run the server:

npm start

MCP Server Configuration

To use this tool with Claude, you need to add it to your MCP settings configuration file.

For Claude Desktop App

Add the following to your Claude Desktop configuration file (located at %APPDATA%\Claude\claude_desktop_config.json on Windows or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

If installed globally via npm:

{
  "mcpServers": {
    "puppeteer": {
      "command": "puppeteer-mcp-server",
      "args": [],
      "env": {}
    }
  }
}

Using npx (without installation):

{
  "mcpServers": {
    "puppeteer": {
      "command": "npx",
      "args": ["-y", "puppeteer-mcp-server"],
      "env": {}
    }
  }
}

If installed from source:

{
  "mcpServers": {
    "puppeteer": {
      "command": "node",
      "args": ["path/to/puppeteer-mcp-server/dist/index.js"],
      "env": {
        "NODE_OPTIONS": "--experimental-modules"
      }
    }
  }
}

For Claude VSCode Extension

Add the following to your Claude VSCode extension MCP settings file (located at %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json on Windows or ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json on macOS):

If installed globally via npm:

{
  "mcpServers": {
    "puppeteer": {
      "command": "puppeteer-mcp-server",
      "args": [],
      "env": {}
    }
  }
}

Using npx (without installation):

{
  "mcpServers": {
    "puppeteer": {
      "command": "npx",
      "args": ["-y", "puppeteer-mcp-server"],
      "env": {}
    }
  }
}

If installed from source:

{
  "mcpServers": {
    "puppeteer": {
      "command": "node",
      "args": ["path/to/puppeteer-mcp-server/dist/index.js"],
      "env": {
        "NODE_OPTIONS": "--experimental-modules"
      }
    }
  }
}

For source installation, replace path/to/puppeteer-mcp-server with the actual path to where you installed this tool.

Usage

Standard Mode

The server will launch a new browser instance by default.

Active Tab Mode

To connect to an existing Chrome window:

  1. Close any existing Chrome instances completely

  2. Launch Chrome with remote debugging enabled:

    # Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

# Linux
google-chrome --remote-debugging-port=9222

  3. Navigate to your desired webpage in Chrome

  4. Connect using the puppeteer_connect_active_tab tool:

    {
  "targetUrl": "https://example.com", // Optional: specific tab URL
  "debugPort": 9222 // Optional: defaults to 9222
}

The server will:

  • Detect and connect to the Chrome instance running with remote debugging enabled

  • Preserve your Chrome instance (won't close it)

  • Find and connect to non-extension tabs

  • Provide clear error messages if connection fails

Available Tools

puppeteer_connect_active_tab

Connect to an existing Chrome instance with remote debugging enabled.

  • Optional:

    • targetUrl - URL of the specific tab to connect to

    • debugPort - Chrome debugging port (default: 9222)

puppeteer_navigate

Navigate to a URL.

  • Required: url - The URL to navigate to

puppeteer_screenshot

Take a screenshot of the current page or a specific element.

  • Required: name - Name for the screenshot

  • Optional:

    • selector - CSS selector for element to screenshot

    • width - Width in pixels (default: 800)

    • height - Height in pixels (default: 600)

puppeteer_click

Click an element on the page.

  • Required: selector - CSS selector for element to click

puppeteer_fill

Fill out an input field.

  • Required:

    • selector - CSS selector for input field

    • value - Text to enter

puppeteer_select

Use dropdown menus.

  • Required:

    • selector - CSS selector for select element

    • value - Option value to select

puppeteer_hover

Hover over elements.

  • Required: selector - CSS selector for element to hover

puppeteer_evaluate

Execute JavaScript in the browser console.

  • Required: script - JavaScript code to execute

Security Considerations

When using remote debugging:

  • Only enable on trusted networks

  • Use a unique debugging port

  • Close debugging port when not in use

  • Never expose debugging port to public networks

Logging and Debugging

File-based Logging

The server implements comprehensive logging using Winston:

  • Location: logs/ directory

  • File Pattern: mcp-puppeteer-YYYY-MM-DD.log

  • Log Rotation:

    • Daily rotation

    • Maximum size: 20MB per file

    • Retention: 14 days

    • Automatic compression of old logs

Log Levels

  • DEBUG: Detailed debugging information

  • INFO: General operational information

  • WARN: Warning messages

  • ERROR: Error events and exceptions

Logged Information

  • Server startup/shutdown events

  • Browser operations (launch, connect, close)

  • Navigation attempts and results

  • Tool executions and outcomes

  • Error details with stack traces

  • Browser console output

  • Resource usage (screenshots, console logs)

Error Handling

The server provides detailed error messages for:

  • Connection failures

  • Missing elements

  • Invalid selectors

  • JavaScript execution errors

  • Screenshot failures

Each tool call returns:

  • Success/failure status

  • Detailed error message if failed

  • Operation result data if successful

All errors are also logged to the log files with:

  • Timestamp

  • Error message

  • Stack trace (when available)

  • Context information

Contributing

Contributions are welcome! Please read our Contributing Guidelines for details on how to submit pull requests, report issues, and contribute to the project.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

8 tools
puppeteer_clickC

Click an element on the page

ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector for element to click

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states 'click an element' without specifying waiting behavior, error handling, or effects on page state. This is insufficient for an agent to predict outcomes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (5 words) with no fluff, but it omits critical details. It is not informationally efficient; it sacrifices completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter, the description lacks completeness: no mention of return values, error conditions, or interaction behavior. Given sibling tools, more context would aid selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's description of 'CSS selector for element to click'. It simply restates the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (click) and resource (element on the page). It is specific enough to differentiate from sibling tools like puppeteer_hover, but lacks additional context like 'simulates a real click interaction'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like puppeteer_hover or puppeteer_select. No prerequisites or conditions for effective use are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_connect_active_tabB

Connect to an existing Chrome instance with remote debugging enabled

ParametersJSON Schema
NameRequiredDescriptionDefault
targetUrlNoOptional URL of the target tab to connect to. If not provided, connects to the first available tab.
debugPortNoOptional Chrome debugging port (default: 9222)

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It implies remote debugging protocol usage but does not disclose failure behavior, statefulness, or impact on subsequent operations. Adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no wasted words, front-loaded with the key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not mention return values or that this tool sets up a connection for subsequent puppeteer commands. Lacks critical context for a preparatory tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers both parameters with descriptions. Baseline 3 since coverage is 100%, and the description adds no extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Connect to an existing Chrome instance with remote debugging enabled', which is specific and distinguishes from sibling tools that perform actions on a connected page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. It does not mention that this is a prerequisite for other puppeteer tools or what to do if no instance is available.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_evaluateB

Execute JavaScript in the browser console

ParametersJSON Schema
NameRequiredDescriptionDefault
scriptYesJavaScript code to execute

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It only states that JavaScript is executed, but omits whether the result is returned, if it is synchronous, or any potential side effects. This lack of detail hinders an agent's ability to anticipate behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that directly communicates the purpose. It is front-loaded and avoids unnecessary words, though it could benefit from slightly more detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one required parameter, no output schema, no annotations), the description is too minimal. It does not mention return values, error handling, or any behavioral nuances, leaving gaps for an AI agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage for the single parameter 'script' with a description 'JavaScript code to execute'. The description adds no further semantic meaning beyond what the schema states, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Execute JavaScript in the browser console' clearly states the action (execute) and the target (JavaScript in the browser console). It distinguishes the tool from sibling tools like puppeteer_click or puppeteer_navigate which perform different browser actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or limitations. It simply states what it does without contextual usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_fillD

Fill out an input field

ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector for input field
valueYesValue to fill

TDQS

D1.9/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to specify whether the fill action clears the field first, appends text, triggers events, or waits for ready state. For a browser automation tool, such omissions are critical and yield a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

At five words, the description is extremely concise but at the cost of critical information. It omits necessary details about behavior, prerequisites, and side effects. This is under-specification, not efficient conciseness, warranting a score of 2.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's behavioral ambiguity, lack of output schema, and zero annotations, the description is severely incomplete. It does not clarify return value, error conditions, or interaction with page state. A score of 1 reflects its inadequacy for safe, informed use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, with both ‘selector’ and ‘value’ described in the schema. The description adds no additional meaning about parameter usage (e.g., format of selectors, allowed value types). Baseline score of 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Fill out an input field' is a near-tautology of the tool name 'puppeteer_fill', providing no additional specificity. It neither distinguishes from sibling tools like puppeteer_select (which handles dropdowns) nor explains what 'fill out' entails (e.g., typing vs. setting value). A score of 2 reflects the lack of unique semantic contribution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus alternatives. The sibling tools (click, hover, select, etc.) have overlapping contexts, but the description offers no explicit when-to-use or when-not-to-use instructions. This leaves the AI agent to infer usage from the name alone, which is insufficient for correct tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_hoverB

Hover an element on the page

ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector for element to hover

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description should disclose behavioral traits. It only states the action, not side effects (e.g., triggering hover events) or requirements (e.g., element must be visible). This is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient, though could include slightly more detail without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one param, no output schema), the description is too minimal. It lacks context about hover behavior, error handling, or interaction with the page, which is important for an automation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a clear description for the single parameter 'selector' (CSS selector). The tool description adds no further meaning, but the schema already suffices. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Hover an element on the page' clearly states the verb (hover) and resource (element on page). It distinguishes from sibling tools like puppeteer_click, puppeteer_fill, etc., which have different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidelines are provided. The description does not specify when to use hover vs click or other sibling tools, nor does it mention prerequisites like element visibility.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_navigateC

Navigate to a URL

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention whether the tool waits for page load, handles redirects, or what happens on network errors. The simple statement 'Navigate to a URL' lacks essential behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at 4 words, which is appropriate for a simple tool. However, it lacks helpful structure and could be improved with a sentence that front-loads the most critical information (e.g., 'Navigates the page to the given URL, waiting for the full page load.').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (navigation involves waiting, loading states, and possible errors), the description is incomplete. It does not address return values, error behavior, or side effects. With no output schema or annotations, the description should cover these aspects but fails to do so.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must add meaning. While 'Navigate to a URL' implies the 'url' parameter is the destination, it does not specify required format (e.g., must include protocol), maximum length, or allowed schemes. The description adds little beyond the parameter name itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Navigate to a URL' clearly states the action (navigate) and the resource (URL). While it doesn't explicitly differentiate from sibling tools like puppeteer_click or puppeteer_fill, the sibling names are distinct enough that confusion is unlikely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., page must be open) or exclusions (e.g., do not use for file:// URLs). Users must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_screenshotB

Take a screenshot of the current page or a specific element

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesName for the screenshot
selectorNoCSS selector for element to screenshot
widthNoWidth in pixels (default: 800)
heightNoHeight in pixels (default: 600)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavioral disclosure. It omits details like whether the page must be fully loaded, handling of missing selectors, or output format, leaving the agent uninformed about key behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it lacks structure and fails to front-load critical information like the element selector option. It could be more informative without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should explain what the tool returns (e.g., file path, base64 data). It does not. Additionally, behavioral gaps (e.g., error handling) make it incomplete for proper usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameter descriptions already exist. The description adds no new semantic meaning beyond 'or a specific element' for selector, but does not clarify defaults or constraints beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Take a screenshot') and the resource ('current page or a specific element'), distinguishing it from sibling tools like puppeteer_click or puppeteer_navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

While the tool's purpose is clear and distinct from siblings, no explicit guidance is provided on when to use it versus alternatives, such as when an element screenshot is preferable over full-page or when to use puppeteer_evaluate instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

puppeteer_selectB

Select an element on the page with Select tag

ParametersJSON Schema
NameRequiredDescriptionDefault
selectorYesCSS selector for element to select
valueYesValue to select

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only states 'Select an element' without explaining side effects (e.g., triggers change, requires visibility) or any behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two parameters and no output schema, the description lacks details about the interaction behavior and typical use cases. It is insufficient for an agent to understand the full context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool selects an element with a Select tag, which distinguishes it from siblings like puppeteer_click or puppeteer_fill. However, it could be more precise by specifying it selects an option within a <select> element.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for <select> elements but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a distinct purpose: clicking, filling, hovering, navigating, etc. No two tools overlap in functionality, so an agent can clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent 'puppeteer_<action>' naming pattern, with verbs like click, fill, hover, navigate, etc. This predictable pattern aids agent selection.

Tool Count5/5

With 8 tools covering essential browser automation actions (navigate, click, fill, screenshot, etc.), the count is well-scoped for the server's purpose.

Completeness4/5

The tool set covers common actions but lacks some operations like getting current URL/title, waiting for elements, or handling popups. These are minor gaps for basic automation.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Puppeteer MCP Server

    merajmehrabi
    A
    license
    A
    quality
    B
    maintenance
    Enables browser automation with Puppeteer, supporting navigation, form interactions, and connection to active Chrome instances for comprehensive web page interaction.
    8
    2,359
    482
    MIT

  • Chrome DevTools MCP

    ctrlShiftBryan
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI coding assistants to control and inspect a live Chrome browser through DevTools for automated testing, performance analysis, debugging, and web scraping. Provides reliable browser automation using Puppeteer with comprehensive DevTools access.
    3,288,165
    3
    Apache 2.0

  • Puppeteer Swarm MCP

    greatSumini
    A
    license
    A
    quality
    D
    maintenance
    Enables browser automation with concurrent tab pool management using Puppeteer. Supports navigation, content extraction, screenshots, element interaction, and JavaScript execution across multiple browser tabs with auto-recovery and idle timeout features.
    11
    16
    1
    MIT

  • Chrome DevTools MCP

    khawjaahmad
    -
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI coding assistants to control and inspect a live Chrome browser for automated debugging, performance analysis, and web interaction. It leverages Puppeteer and Chrome DevTools to provide capabilities like network monitoring, console logging, and automated browser actions.

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/freelw/puppeteer-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server