Puppeteer MCP Server

by cploujoux

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 2.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
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. 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.
Behavior2/5
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 ('Navigate to a URL') but does not explain key behaviors such as whether it waits for page load, handles redirects, timeouts, or errors, or if it requires authentication. This leaves significant gaps in understanding how the tool operates beyond its basic function.
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?
The description is extremely concise with a single, clear sentence ('Navigate to a URL') that is front-loaded and wastes no words. It efficiently communicates the core action without unnecessary elaboration, making it easy to parse quickly.
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 complexity (a navigation action in a browser automation context), lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It does not cover behavioral aspects, error handling, or integration with sibling tools, leaving the agent with insufficient information for reliable use.
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 1 parameter with 0% description coverage, and the description does not add any semantic details about the 'url' parameter. It does not specify format requirements (e.g., must be a valid HTTP/HTTPS URL), constraints, or examples, failing to compensate for the lack of schema documentation.
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 tool's function with a specific verb ('Navigate') and resource ('URL'), making the purpose immediately understandable. However, it does not differentiate this navigation tool from its siblings like 'puppeteer_click' or 'puppeteer_hover', which are also navigation-related actions in a browser context, so it lacks sibling distinction.
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. It does not mention prerequisites (e.g., requiring an active browser session), exclusions, or compare it to sibling tools like 'puppeteer_evaluate' for executing scripts or 'puppeteer_screenshot' for capturing pages, leaving the agent with minimal context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/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 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.
Usage Guidelines2/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/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 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.
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. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
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. 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-puppeteer MCP server](https://glama.ai/mcp/servers/cploujoux/mcp-puppeteer/badges/card.svg)](https://glama.ai/mcp/servers/cploujoux/mcp-puppeteer)

Score Badge

Copy to your README.md:

[![mcp-puppeteer MCP server](https://glama.ai/mcp/servers/cploujoux/mcp-puppeteer/badges/score.svg)](https://glama.ai/mcp/servers/cploujoux/mcp-puppeteer)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/cploujoux/mcp-puppeteer'

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