Supports interaction with page elements through CSS selectors for targeting specific elements to click, hover, fill, screenshot, or select.
Enables execution of JavaScript code in the browser console through the puppeteer_evaluate tool, with access to console output via resources.
Provides browser automation capabilities allowing interaction with web pages, navigation, element selection, form filling, JavaScript execution, and screenshot capture in a real browser environment.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Puppeteer MCP Server take a screenshot of the homepage and name it 'homepage_screenshot'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that provides browser automation capabilities using Puppeteer. This server enables LLMs to interact with web pages, take screenshots, and execute JavaScript in a real browser environment.
puppeteer_navigate
Navigate to any URL in the browser
Input: url (string)
puppeteer_screenshot
Capture screenshots of the entire page or specific elements
Inputs:
name (string, required): Name for the screenshot
selector (string, optional): CSS selector for element to screenshot
width (number, optional, default: 800): Screenshot width
height (number, optional, default: 600): Screenshot height
puppeteer_click
Click elements on the page
Input: selector (string): CSS selector for element to click
puppeteer_hover
Hover elements on the page
Input: selector (string): CSS selector for element to hover
puppeteer_fill
Fill out input fields
Inputs:
selector (string): CSS selector for input field
value (string): Value to fill
puppeteer_select
Select an element with SELECT tag
Inputs:
selector (string): CSS selector for element to select
value (string): Value to select
puppeteer_evaluate
Execute JavaScript in the browser console
Input: script (string): JavaScript code to execute
The server provides access to two types of resources:
Console Logs (console://logs)
Browser console output in text format
Includes all console messages from the browser
Screenshots (screenshot://<name>)
PNG images of captured screenshots
Accessible via the screenshot name specified during capture
Related MCP server: Puppeteer MCP Server
Browser automation
Console log monitoring
Screenshot capabilities
JavaScript execution
Basic web interaction (navigation, clicking, form filling)
Here's the Claude Desktop configuration to use the Puppeter server:
NOTE The docker implementation will use headless chromium, where as the NPX version will open a browser window.
{
"mcpServers": {
"puppeteer": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--init",
"-e",
"DOCKER_CONTAINER=true",
"mcp/puppeteer"
]
}
}
}{
"mcpServers": {
"puppeteer": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-puppeteer"]
}
}
}Docker build:
docker build -t mcp/puppeteer -f src/puppeteer/Dockerfile .This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether the click triggers navigation, requires the element to be visible/clickable, handles errors if the selector isn't found, or has any side effects like waiting for page changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, making it highly concise and front-loaded. Every word earns its place by conveying the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description is incomplete. It lacks context on prerequisites (e.g., page must be loaded), behavioral details (e.g., error handling), and output expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'selector' parameter fully. The description adds no additional meaning beyond implying the element is on a page, which is minimal value. Baseline 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click an element on the page' clearly states the action (click) and target (element on the page), making the purpose immediately understandable. However, it doesn't differentiate from siblings like 'puppeteer_hover' which also targets page elements, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a page to be loaded), exclusions, or comparisons to siblings like 'puppeteer_hover' for hovering instead of clicking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser console
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details: it doesn't disclose that this executes in a browser context (implying potential side effects), doesn't mention error handling, return values, or that it might require a page to be loaded. For a tool that executes arbitrary code with no safety annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing JavaScript in a browser (a potentially powerful/destructive operation), no annotations, no output schema, and 100% schema coverage, the description is incomplete. It doesn't address return values, error cases, or safety considerations, leaving the agent under-informed about behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'script' documented as 'JavaScript code to execute'. The description adds no additional meaning beyond this, such as examples, constraints, or context about the execution environment. With high schema coverage, the baseline is 3, 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.
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 target (JavaScript in browser console). It distinguishes from siblings like click, fill, or navigate by specifying code execution rather than UI interaction or navigation. However, it doesn't explicitly contrast with potential similar tools beyond the provided sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., requires an active browser page), exclusions (e.g., not for DOM manipulation vs. puppeteer_click), or context for choosing between executing JavaScript and using other puppeteer tools. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill out an input field
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for input field | |
| value | Yes | Value to fill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('fill out') but lacks details on side effects (e.g., whether it triggers events, requires the element to be visible, or handles errors), permissions, or performance considerations. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at four words, with no wasted language. It front-loads the core action ('Fill out') and target ('an input field'), making it easy to parse quickly. Every word earns its place, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a Puppeteer-based interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain the web automation context, potential errors, or what happens after filling (e.g., if it waits for page updates). For a mutation tool in this environment, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('selector' and 'value'). The description adds no additional meaning beyond what the schema provides, such as examples or constraints. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill out an input field' clearly states the action (fill) and target (input field), making the basic purpose understandable. However, it lacks specificity about the context (e.g., web page interaction via Puppeteer) and doesn't distinguish it from sibling tools like 'puppeteer_click' or 'puppeteer_select', which also interact with page elements. This results in a vague but functional purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a page loaded via 'puppeteer_navigate'), exclusions, or comparisons to siblings like 'puppeteer_select' for dropdowns. Without such context, the agent must infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to hover |
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 states the action but doesn't mention potential side effects (e.g., triggering JavaScript events, changing page state), error conditions, or performance considerations. This leaves significant gaps for a tool that interacts with dynamic web content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address what happens after hovering (e.g., does it wait for page updates?), potential errors, or return values. For a browser automation tool with dynamic interactions, this leaves critical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'selector' clearly documented in the schema. The description doesn't add any additional meaning or context about the parameter beyond what the schema provides, such as selector best practices or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('hover') and target ('an element on the page'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'puppeteer_click' or 'puppeteer_select', which also interact with page elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about scenarios where hovering is appropriate (e.g., triggering dropdowns or tooltips) or when other tools like 'click' or 'select' might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| height | No | Height in pixels (default: 600) | |
| name | Yes | Name for the screenshot | |
| selector | No | CSS selector for element to screenshot | |
| width | No | Width in pixels (default: 800) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Take a screenshot') but doesn't describe what happens after (e.g., returns an image file, saves locally, requires permissions, or has rate limits). For a tool with potential side effects (like file creation) and no annotations, this is a significant gap, warranting a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded and every word earns its place, making it highly concise and well-structured, deserving a score of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a screenshot tool with potential behavioral implications), lack of annotations, and no output schema, the description is incomplete. It doesn't cover return values (e.g., image data or file path), error conditions, or dependencies on other tools like puppeteer_navigate. This leaves significant gaps for an AI agent to use it effectively, resulting in a score of 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all 4 parameters (height, name, selector, width), including defaults. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'selector' interacts with 'current page' or format details. With high schema coverage, the baseline is 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 target ('current page or a specific element'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like puppeteer_click or puppeteer_navigate, though the verb 'screenshot' inherently distinguishes it. This earns a 4 for clear purpose without explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a page loaded via puppeteer_navigate first), exclusions, or comparisons to other screenshot-related tools if any existed. This lack of contextual usage information results in a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an element on the page with Select tag
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to select | |
| value | Yes | Value to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not explain what 'select' entails (e.g., does it simulate user interaction, change UI state, or trigger events?), potential side effects, error conditions, or permissions needed. This is inadequate for a tool that likely performs UI interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, front-loading the key action and target. It is appropriately sized for the tool's complexity, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not cover behavioral aspects like what happens after selection, error handling, or return values, which are crucial for a UI interaction tool. This leaves significant gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (selector and value). The description adds no additional meaning beyond what the schema provides, such as examples or constraints, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Select an element') and the target ('on the page with Select tag'), which is a specific verb+resource combination. However, it does not explicitly distinguish this from sibling tools like puppeteer_click or puppeteer_fill, which might also interact with page elements, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, context, or exclusions, such as when to choose puppeteer_select over puppeteer_click for dropdowns or other selectable elements, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no ambiguity. Click, fill, hover, navigate, screenshot, evaluate, and select all target different browser automation actions with no overlap in functionality.
All tools follow a perfect verb_noun pattern with consistent 'puppeteer_' prefix and snake_case naming. The naming convention is predictable and readable throughout the entire set.
Seven tools is an excellent number for a browser automation server - enough to cover essential interactions without being overwhelming. Each tool serves a distinct, valuable purpose in the Puppeteer domain.
The toolset covers most essential browser automation operations including navigation, interaction, evaluation, and capture. A minor gap exists in text extraction/reading capabilities, but core workflows are well-supported for a basic Puppeteer interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
A Model Context Protocol server for Wix AI tools
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cploujoux/mcp-puppeteer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
