What can you do with this server?

The MCP-Server-Playwright enables browser automation for interacting with and extracting data from web pages through Playwright. With this server, you can: * Navigate to URLs: Load any web page by specifying its URL * Interact with elements: Click, hover, fill form fields, and select dropdown options using CSS selectors or text content * Capture screenshots: Take screenshots of entire pages or specific elements * Execute JavaScript: Run arbitrary code within the browser context * Monitor console logs: Access and retrieve browser console output * Perform comprehensive automation: Complete complex sequences of interactions in a real browser environment

Which integrations are available for this server?

Allows execution of JavaScript in the browser environment via the browser_evaluate tool Supports macOS as a compatible operating system with specific configuration paths

How do I use MCP-Server-Playwright?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-Server-Playwright take a screenshot of the homepage and show me the console logs" 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.

en es ja ko zh

MCP-Server-Playwright

by VikashLoomba

Overview Schema Related Servers Score Discussions

JavaScript

Local

Related MCP server: Playwright MCP Server for Security

Features

🌐 Full browser automation capabilities
📸 Screenshot capture of entire pages or specific elements
🖱️ Comprehensive web interaction (navigation, clicking, form filling)
📊 Console log monitoring
🔧 JavaScript execution in browser context

Installation

Installing via Smithery

To install MCP Server Playwright for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @automatalabs/mcp-server-playwright --client claude

You can install the package using either npx or mcp-get:

Using npx:

npx @automatalabs/mcp-server-playwright install

This command will:

Check your operating system compatibility (Windows/macOS)
Create or update the Claude configuration file
Configure the Playwright server integration

The configuration file will be automatically created/updated at:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Using mcp-get:

npx @michaellatman/mcp-get@latest install @automatalabs/mcp-server-playwright

Configuration

The installation process will automatically add the following configuration to your Claude config file:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@automatalabs/mcp-server-playwright"]
    }
  }
}

Using with Cursor

You can also use MCP Server Playwright with Cursor, an AI-powered code editor. To enable browser automation in Cursor via MCP:

Install Playwright browsers (if not already):
```
npx playwright install
```

Install MCP Server Playwright for Cursor using Smithery:

npx -y @smithery/cli install @automatalabs/mcp-server-playwright --client cursor

Configuration file setup:
If you do not use Claude, the configuration file (claude_desktop_config.json) may not be created automatically.
- On Windows, create a folder named Claude in %APPDATA% (usually C:\Users\<YourName>\AppData\Roaming\Claude).
- Inside that folder, create a file named claude_desktop_config.json with the following content:
```
{
  "serverPort": 3456
}
```
Follow the remaining steps in the Installation section above to complete the setup.

Now, you can use all the browser automation tools provided by MCP Server Playwright directly from Cursor’s AI features, such as web navigation, screenshot capture, and JavaScript execution.

Note: Make sure you have Node.js installed and npx available in your system PATH.

Components

Tools

`browser_navigate`

Navigate to any URL in the browser

{
  "url": "https://stealthbrowser.cloud"
}

`browser_screenshot`

Capture screenshots of the entire page or specific elements

{
  "name": "screenshot-name",     // required
  "selector": "#element-id",     // optional
  "fullPage": true              // optional, default: false
}

`browser_click`

Click elements on the page using CSS selector

{
  "selector": "#button-id"
}

`browser_click_text`

Click elements on the page by their text content

{
  "text": "Click me"
}

`browser_hover`

Hover over elements on the page using CSS selector

{
  "selector": "#menu-item"
}

`browser_hover_text`

Hover over elements on the page by their text content

{
  "text": "Hover me"
}

`browser_fill`

Fill out input fields

{
  "selector": "#input-field",
  "value": "Hello World"
}

`browser_select`

Select an option in a SELECT element using CSS selector

{
  "selector": "#dropdown",
  "value": "option-value"
}

`browser_select_text`

Select an option in a SELECT element by its text content

{
  "text": "Choose me",
  "value": "option-value"
}

`browser_evaluate`

Execute JavaScript in the browser console

{
  "script": "document.title"
}

Resources

Console Logs (console://logs)
- Access browser console output in text format
- Includes all console messages from the browser
Screenshots (screenshot://<n>)
- Access PNG images of captured screenshots
- Referenced by the name specified during capture

License

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

Available Tools

10 tools

browser_clickB

Click an element on the page using CSS selector

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector for element to click

TDQS

B3.3/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 convey behavioral traits. It only states the click action without mentioning waiting, scrolling, error handling, or side effects. This is insufficient for an agent to predict the tool's behavior.

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 no superfluous words. It is front-loaded and efficient.

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

Completeness3/5

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

For a simple click tool, the description is minimal but sufficient to convey the core action. However, it lacks details on return values or error behavior, which are not covered by annotations or output schema. A more complete description would include expected 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 coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter description, but the parameter is well-defined.

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 'Click an element on the page using CSS selector', which specifies the verb (click), resource (element), and method (CSS selector). This distinguishes it from sibling tools like browser_click_text which click by text.

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 over alternatives such as browser_click_text or browser_hover. No exclusions or context for selection are given.

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

browser_click_textB

Click an element on the page by its text content

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text content of the element to click

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description lacks any behavioral details such as what happens if multiple elements match, whether scrolling is automatic, or if it waits for elements to be visible. This is a significant gap for a click action.

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, clear sentence with no wasted words. It is front-loaded with the purpose. However, it is slightly under-specified for a click action, but this doesn't affect 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?

For a click tool with multiple siblings, the description is too sparse. It does not explain return values, error handling, or behavior with partial text matches. Given no output schema, the description should compensate but fails to do so.

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 has 100% coverage on the single parameter, and the description adds no extra semantic value beyond stating 'by its text content,' which parallels the parameter description. Baseline score 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 clearly states the action (click) and the target (element by its text content). It distinguishes from sibling tools like browser_click (likely by coordinates or selector) and browser_hover_text (hover instead of click).

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. Does not mention when not to use it (e.g., for non-text elements) or clarify that browser_click might be better for CSS selectors.

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

browser_evaluateB

Execute JavaScript in the browser console

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes	JavaScript code to execute

TDQS

B3.2/5.0

Behavior2/5

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

The description does not disclose behavioral traits such as return values, side effects, or security implications, which are crucial for a code execution tool.

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, front-loaded sentence with no unnecessary words.

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 tool that executes arbitrary JavaScript, the description is too minimal, lacking details on output, limitations, or interaction with the page.

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 provides adequate description for the sole parameter, and the tool description adds no extra meaning beyond 'execute JavaScript'.

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 (execute) and the resource (JavaScript in the browser console), distinguishing it from sibling tools like clicking or navigating.

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, or any context-specific recommendations.

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

browser_fillC

Fill out an input field

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector for input field
`value`	Yes	Value to fill

TDQS

C2.9/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 says 'Fill out an input field' without specifying if it triggers events, clears existing content, or how it handles special characters. This is insufficient for an agent to predict side effects.

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 sentence with no filler words. It is concise, though slightly too terse; a bit more detail could fit without harming 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?

For a browser automation tool, the description omits important context like return behavior (e.g., success indicator) or whether it clears the field first. No output schema exists, so the description should cover this. It feels incomplete for an 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 coverage is 100% with clear parameter descriptions (CSS selector, value). The tool description adds no extra meaning beyond the schema, which is acceptable per baseline rules.

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 'Fill out an input field' clearly states the verb and resource, but does not differentiate from sibling tools like browser_click or browser_select. It is specific enough for the main action.

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 (e.g., browser_evaluate for setting values programmatically). The description lacks context about prerequisites or exclusions.

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

browser_hoverB

Hover an element on the page using CSS selector

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector for element to hover

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 should disclose behavioral traits (e.g., whether it waits for visibility, simulates real hover), but it only states the action without any side effects or prerequisites.

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?

Extremely concise (single sentence) but lacks front-loading of key information. However, brevity is appropriate for a simple tool.

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

Completeness3/5

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

For a simple hover action, the description is functionally complete but does not elaborate on return values or relation to sibling tools, which would improve completeness.

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%; the description merely repeats the schema's parameter description. No additional semantic value is added.

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 it hovers an element using a CSS selector, distinguishing it from siblings like browser_hover_text which likely uses text-based selection.

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 (e.g., browser_hover_text, browser_click). An agent would need to infer usage from the name alone.

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

browser_hover_textB

Hover an element on the page by its text content

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text content of the element to hover

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description must carry full behavioral weight. It only states the hover action without disclosing what happens on element absence, multiple matches, or scrolling needs.

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 no wasted words, front-loading the core action and selection method.

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

Completeness3/5

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

Given the tool's simplicity (1 param, no output schema), the description is complete enough for basic understanding but lacks guidance for edge cases or differentiation from sibling text-based tools.

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 3 is appropriate. The description adds minimal value beyond the schema's parameter description, only reiterating 'by its text content'.

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 (hover), the target (element), and the selection method (by text content). This distinguishes it from siblings like browser_hover which likely uses selectors.

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 like browser_hover or browser_click_text. No prerequisites or context scenarios are mentioned.

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

browser_navigateC

Navigate to a URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

C2.8/5.0

Behavior1/5

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

No annotations are provided, and the description omits behavioral details like whether the navigation waits for the page to load, handles errors, or replaces the current page. The description carries the full burden but provides none.

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 wasted words. However, it could benefit from a structure that includes the action and context without being 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 the simplicity of the tool (one parameter, no output schema), the description is minimal but incomplete. It does not cover important aspects like error handling, loading behavior, or tab management, which an agent might need.

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 description adds minimal value beyond the input schema; it implies the 'url' parameter is the target URL, but does not explain format, restrictions, or default behavior. With 0% schema coverage, more detail is needed.

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 'Navigate to a URL' clearly states the action and resource, and it distinguishes this tool from siblings like browser_click and browser_fill, which perform 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 guidance is provided on when to use this tool versus alternatives, such as when to navigate versus evaluate or wait. The description does not mention context or prerequisites.

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

browser_screenshotA

Take a screenshot of the current page or a specific element

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name for the screenshot
`selector`	No	CSS selector for element to screenshot
`fullPage`	No	Take a full page screenshot (default: false)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It does not disclose important traits such as that the screenshot captures only the viewport by default, that fullPage captures the entire scrollable area, or that the selector must be visible.

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 no redundant words. It is appropriately sized for a straightforward tool.

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

Completeness3/5

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

Given the tool's simplicity, the description covers the basic action. However, it omits details like what happens if selector is invalid, how the screenshot is saved, or that the page must be fully loaded.

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 additional meaning beyond parameter names and types, failing to explain that selector is optional or fullPage defaults to false.

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 tool takes a screenshot of the current page or a specific element. It uses a specific verb-resource pair and distinguishes well from sibling tools like click, navigate, or evaluate.

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 the tool is for capturing visual content, but it doesn't explicitly provide when to use it over alternatives, nor does it mention any exclusions or prerequisites.

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

browser_selectB

Select an element on the page with Select tag using CSS selector

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector for element to select
`value`	Yes	Value to select

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as events triggered, error handling, or side effects, leaving critical context missing.

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?

Single sentence with no redundancy, front-loaded with the key action and target, efficient but could be slightly more structured.

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

Completeness3/5

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

For a simple tool with 2 required params and no output schema, the description covers basic purpose and parameters but omits behavioral details like events or return values.

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 already describes both parameters with 100% coverage; the description adds no extra meaning beyond naming the CSS selector and value.

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 specifies the verb ('Select'), resource ('element with Select tag'), and method ('using CSS selector'), distinguishing it from siblings like browser_click or browser_fill.

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 explicit guidance on when to use this tool versus alternatives; lacks when-not-to-use or references to sibling tools for other element types.

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

browser_select_textC

Select an element on the page with Select tag by its text content

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text content of the element to select
`value`	Yes	Value to select

TDQS

C2.3/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, but it does not. It doesn't mention side effects, such as whether the page is modified, or error handling if the text or value is not found. This leaves the agent unsure of the tool's impact.

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 overly vague. It lacks structure and fails to front-load key information. While short, it sacrifices clarity 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 tool with no output schema and two parameters, the description is insufficient. It does not explain how the two parameters relate (text identifies the element, value selects the option). The agent lacks a complete understanding of the tool's behavior.

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%, but the parameter descriptions are tautological (e.g., 'Text content of the element to select'). The tool description itself does not add any meaning beyond the input schema. Baseline 3 applies due to high coverage, but no extra value is provided.

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 states 'Select an element on the page with Select tag by its text content,' which is vague and potentially misleading. It does not clearly explain that the tool likely selects an option from a dropdown based on text, especially confusing given the 'value' parameter. It barely distinguishes from sibling tool 'browser_select' only by name.

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 'browser_select' or 'browser_click_text'. The description lacks any context about prerequisites, such as whether the page must be loaded or the element must exist.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv1.0.0Jan 2, 2026
- Addedbrowser_click
- Addedbrowser_click_text
- Addedbrowser_evaluate
- Addedbrowser_fill
- Addedbrowser_hover
- Addedbrowser_hover_text
- Addedbrowser_navigate
- Addedbrowser_screenshot
- Addedbrowser_select
- Addedbrowser_select_text

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. Pairwise similar tools like click and click_text are differentiated by CSS selector vs text content, making ambiguity minimal.

Naming Consistency5/5

All tools follow a consistent 'browser_verb' pattern, with optional '_text' suffix for text-based selectors. Snake_case is used uniformly.

Tool Count5/5

10 tools is an appropriate number for browser automation, covering essential actions without being overwhelming. The scope is well-defined.

Completeness4/5

The set covers core browser interactions (navigation, click, fill, select, hover, evaluate, screenshot). Missing operations like waiting, scrolling, or keyboard input are minor gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,406
render-mcp A
io.github.RodRomer
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
61
E2LLM
com.e2llm
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Browser Automation Agent Orchestration
26
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2

Related MCP Servers

Puppeteer MCP Server
Browser Automation Web Scraping Agent Orchestration
jwaldor
A
license
C
quality
D
maintenance
Enables LLMs to perform web browsing tasks, take screenshots, and execute JavaScript using Puppeteer for browser automation.
Updated 2 years ago (2025-01-13 19:55 UTC)
4
28,366
1
MIT
Playwright MCP Server for
Browser Automation Web Scraping Testing & QA Tools
o0x1024
A
license
Not graded
quality
D
maintenance
Enables LLMs to perform browser automation tasks including web scraping, taking screenshots, and executing JavaScript using Playwright. It facilitates real-time interaction with web pages and the generation of automated test code.
Updated 9 months ago (2025-12-19 15:56 UTC)
58
MIT
Playwright MCP Server
Browser Automation Web Scraping
vinothbhc1986
A
license
Not graded
quality
D
maintenance
Enables browser automation using Playwright, allowing LLMs to interact with web pages, take screenshots, generate test code, scrape web pages, and execute JavaScript in a real browser environment.
Updated 3 months ago (2026-06-03 05:43 UTC)
18,122
MIT
Cloudflare Playwright MCP
Browser Automation Web Scraping
Abuh112
F
license
Not graded
quality
C
maintenance
Enables AI assistants to control a browser for web automation tasks such as navigation, typing, clicking, and taking screenshots.
Updated 6 months ago (2026-02-24 05:02 UTC)
-

Appeared in Searches

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/VikashLoomba/MCP-Server-Playwright'

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

Table of Contents

Features

Installation

Installing via Smithery

Configuration

Using with Cursor

Components

Tools

browser_navigate

browser_screenshot

browser_click

browser_click_text

browser_hover

browser_hover_text

browser_fill

browser_select

browser_select_text

browser_evaluate

Resources

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`browser_navigate`

`browser_screenshot`

`browser_click`

`browser_click_text`

`browser_hover`

`browser_hover_text`

`browser_fill`

`browser_select`

`browser_select_text`

`browser_evaluate`