Provides a way to run a browserless/Playwright instance locally using Docker for web automation tasks
Allows fetching the MCP server directly from GitHub repository using npx, enabling web automation without local installation
Enables execution of JavaScript code in browser context, allowing custom scripting for web automation tasks
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., "@Playwright MCP Server take a screenshot of the GitHub homepage and save it"
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 (MCP) server that provides comprehensive web automation tools via a remote Playwright/browserless instance. Features 10 powerful tools with Microsoft Playwright-standard naming convention.
10 Comprehensive Web Automation Tools with Microsoft-standard naming
Connect to any remote browserless/Playwright instance
Advanced accessibility tree capture for LLM-friendly element identification
File upload capabilities for testing forms and workflows
Screenshot capture (full page or element-specific)
HTML content extraction with flexible targeting
Element interaction (clicking, typing, waiting)
JavaScript execution with safety measures
Page refresh with configurable wait conditions
Comprehensive error handling and validation
Related MCP server: Playwright MCP Server
Claude Code:
claude mcp add playwright-server -s user -- npx playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromiumCursor AI:
cursor mcp add playwright-server -- npx playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromium/mcpnpx playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromiumnpm install -g playwright-browserless-mcp
playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromiumgit clone https://github.com/b3nw/playwright-browserless-mcp.git
cd playwright-browserless-mcp
npm install && npm run build--url: Your browserless WebSocket URL
--timeout: Request timeout in milliseconds (default: 30000)
--width: Browser viewport width (default: 1920)
--height: Browser viewport height (default: 1080)
# Basic usage
npx playwright-browserless-mcp --url ws://localhost:3000/playwright/chromium
# With custom settings
npx playwright-browserless-mcp --url ws://your-host:3000/playwright/chromium --timeout 60000 --width 1280 --height 720
# Using environment variable
PLAYWRIGHT_URL=ws://your-host:3000/playwright/chromium npx playwright-browserless-mcpYou need a running browserless/Playwright instance. Here are your options:
docker run -p 3000:3000 ghcr.io/browserless/chromiumThen use: ws://localhost:3000/playwright/chromium
Sign up at browserless.io
Use your provided WebSocket URL
Follow the browserless documentation for self-hosting.
Method 1: CLI (Recommended)
claude mcp add playwright-server -s user -- npx playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromiumMethod 2: Manual config file
Edit ~/.config/claude/claude_desktop_config.json:
{
"mcpServers": {
"playwright-server": {
"type": "stdio",
"command": "npx",
"args": ["playwright-browserless-mcp", "--url", "ws://your-browserless-host:3000/playwright/chromium"]
}
}
}Method 1: CLI
cursor mcp add playwright-server -- npx playwright-browserless-mcp --url ws://your-browserless-host:3000/playwright/chromiumMethod 2: Settings UI
Open Cursor preferences (Cmd/Ctrl + ,)
Navigate to "Features" → "Model Context Protocol"
Click "Add MCP Server"
Configure:
Name: playwright-server
Command: npx
Args: ["playwright-browserless-mcp", "--url", "ws://your-browserless-host:3000/playwright/chromium"]
Edit your Claude configuration to include:
{
"mcpServers": {
"playwright-server": {
"type": "stdio",
"command": "npx",
"args": ["playwright-browserless-mcp", "--url", "ws://your-browserless-host:3000/playwright/chromium"]
}
}
}browser_navigateNavigate to a URL and wait for page load.
url (required): URL to navigate to
waitUntil (optional): "networkidle", "domcontentloaded", or "load"
browser_clickClick on an element specified by CSS selector.
selector (required): CSS selector for element to click
browser_typeType text into an input field.
selector (required): CSS selector for input element
text (required): Text to type
browser_wait_forWait for an element to appear on the page.
selector (required): CSS selector for element
timeout (optional): Timeout in milliseconds (default: 30000)
browser_take_screenshotTake a screenshot of the current page or specific element.
fullPage (optional): Take full page screenshot (default: false)
selector (optional): CSS selector for specific element
browser_get_htmlExtract HTML content from the page or specific element.
selector (optional): CSS selector for specific element
browser_snapshot 🆕Get accessibility tree snapshot for LLM-friendly element identification. Perfect for understanding page structure and finding elements semantically.
selector (optional): CSS selector to limit snapshot to specific element
Returns: Structured accessibility data with roles, names, and selectors
browser_file_upload 🆕Upload files to file input elements. Essential for testing file upload forms and workflows.
selector (required): CSS selector for file input element
paths (required): Array of file paths to upload
browser_refresh 🆕Refresh the current page with configurable wait conditions.
waitUntil (optional): "networkidle", "domcontentloaded", or "load" (default: "load")
timeout (optional): Custom timeout in milliseconds
browser_evaluateExecute JavaScript code in the browser context with safety measures.
script (required): JavaScript code to execute
Once configured, you can use these tools in your AI assistant:
Please navigate to https://example.com and take a screenshotFill out the form on this page with name "John Doe" and email "john@example.com", then upload the resume.pdf fileGet an accessibility snapshot of this page to understand its structure, then click the submit button and wait for the success messageNavigate to the login page, fill in credentials, upload a profile picture, and verify the account was created successfully🔄 Microsoft Playwright Standard Naming: All tools now use browser_ prefix for consistency
🆕 Accessibility Tree Snapshots: browser_snapshot tool for semantic element identification
📁 File Upload Support: browser_file_upload tool for testing file forms
🔄 Page Refresh: browser_refresh tool with configurable wait conditions
✅ 10 Total Tools: Expanded from 7 to 10 comprehensive automation tools
🎯 Enhanced Testing: Better support for complex web application testing workflows
/mcpRestart your AI assistant completely
Verify the server works: npx playwright-browserless-mcp --help
Check the configuration syntax in your config file
Verify your browserless instance is running
Test the WebSocket URL in a browser
Check firewall/network settings
If you see old tool names (navigate, screenshot, etc.), you're using an outdated version. Update to v1.1.0:
npx playwright-browserless-mcp@latest --url your-browserless-urlThis server works with Playwright v1.53. If your browserless instance uses a different version, you may need to adjust the playwright dependency.
MIT
Click on an element specified by selector
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes |
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 ('click') but doesn't mention potential side effects (e.g., page navigation, form submissions), error handling, or performance considerations. This leaves significant gaps for a mutation tool in a browser context.
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 with zero waste, front-loading the core action. It's appropriately sized for a simple tool, making it easy 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?
For a mutation tool with no annotations, no output schema, and minimal parameter guidance, the description is incomplete. It doesn't address return values, error cases, or integration with sibling tools, leaving the agent with insufficient context for reliable use in a browser automation scenario.
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 description adds minimal meaning beyond the input schema, which has 0% description coverage for the single 'selector' parameter. It implies the selector specifies the element to click but doesn't explain selector syntax, types (e.g., CSS, XPath), or validation. Given the low schema coverage, this is inadequate compensation, but it provides a baseline understanding.
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 ('click on') and target ('an element specified by selector'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like browser_evaluate or browser_type, which might also interact with elements, so it doesn't reach the highest score.
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 like browser_evaluate for JavaScript interactions or browser_type for text input. It lacks explicit context, exclusions, or prerequisites, offering only a basic functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript code in the browser context
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Execute JavaScript code' implies a write/mutation operation, it doesn't disclose important behavioral traits like execution context isolation, error handling, security implications, or what happens to the browser state after execution. This leaves significant gaps for an agent to understand 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just 7 words, front-loaded with the core action, and contains zero wasted words. Every element ('Execute', 'JavaScript code', 'in the browser context') earns its place.
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?
For a tool that executes arbitrary JavaScript in a browser context with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical aspects like return values, error conditions, execution scope, or how results are captured, leaving the agent with significant uncertainty about how to use this 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?
With 0% schema description coverage and 1 undocumented parameter, the description adds minimal value beyond the schema. It mentions 'JavaScript code' which gives some semantic meaning to the 'script' parameter, but doesn't explain format expectations, supported JavaScript features, or any constraints on the script content.
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 ('Execute JavaScript code') and the context ('in the browser context'), which is specific and distinguishes it from general JavaScript execution tools. However, it doesn't explicitly differentiate from potential sibling tools that might also execute scripts in different contexts.
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 like browser_navigate or browser_type. There's no mention of prerequisites, typical use cases, or limitations that would help an agent decide when this is the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload files to file input elements on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ||
| paths | Yes |
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 ('upload files') but lacks critical details: whether this requires specific page states, if it waits for elements to be visible, what happens on failure, or if it triggers page changes. For a browser interaction tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan and understand 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 browser file uploads (interacting with UI elements, handling local files), no annotations, no output schema, and poor parameter documentation, the description is incomplete. It should address prerequisites, error handling, or behavioral nuances to be adequate for safe 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 schema has 0% description coverage, so parameters 'selector' and 'paths' are undocumented in the schema. The description adds no meaning beyond the tool name—it doesn't explain what 'selector' refers to (e.g., CSS selector for file input) or that 'paths' are local file paths. This fails to compensate for the schema gap.
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 verb ('upload') and resource ('files to file input elements on the page'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like browser_type or browser_click, but the specificity of 'file input elements' provides some implicit 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 loaded with file input elements), exclusions, or comparisons to sibling tools like browser_type for text input or browser_click for general interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract HTML content from the page or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No |
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 ('Extract HTML content') but lacks details on permissions, rate limits, error handling, or output format. This leaves significant gaps for a tool that interacts with browser 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 and front-loaded in a single sentence, with no wasted words. Every part ('Extract HTML content from the page or a specific element') directly contributes to understanding the tool's function.
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 browser interactions, no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address how HTML is returned, potential errors, or interaction with sibling tools, making it inadequate for safe and 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 1 parameter with 0% description coverage, and the description doesn't add any meaning beyond the schema. It mentions 'a specific element' but doesn't explain the 'selector' parameter's purpose, format, or examples, failing to compensate for the low 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 tool's purpose with a specific verb ('Extract') and resource ('HTML content'), and distinguishes the scope ('from the page or a specific element'). However, it doesn't explicitly differentiate from sibling tools like 'browser_evaluate' which might also retrieve content, keeping it from a perfect score.
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 mentions extracting from 'the page or a specific element,' but it doesn't specify scenarios, prerequisites, or exclusions, such as when to use 'browser_evaluate' for dynamic content instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the current page, similar to pressing F5 or clicking browser refresh
| Name | Required | Description | Default |
|---|---|---|---|
| waitUntil | No | load | |
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the refresh action, it doesn't describe what happens during refresh (page reload, network requests, potential loss of form data), whether it waits for page load completion, or any error conditions. The analogy helps but lacks operational details.
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 perfectly concise - a single sentence that communicates the core purpose efficiently with a helpful analogy. Every word earns its place, and it's front-loaded with the essential information.
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?
For a browser interaction tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain parameter usage, behavioral details, or what happens after refresh. The analogy helps but doesn't compensate for the missing operational context needed for effective tool 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?
With 0% schema description coverage and 2 parameters, the description provides no information about the 'waitUntil' enum parameter or 'timeout' parameter. The schema defines these parameters but the description doesn't explain what they control or when to use different waitUntil values, leaving significant gaps in understanding.
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 specific action ('refresh') and resource ('current page'), and distinguishes it from siblings by specifying the browser context. It uses a helpful analogy ('similar to pressing F5 or clicking browser refresh') that makes the purpose immediately understandable.
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 clear context about when to use this tool (to refresh the current browser page), but doesn't explicitly state when NOT to use it or mention alternatives like browser_navigate for different navigation actions. The browser context is implied but not contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get accessibility tree snapshot for LLM-friendly element identification
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No |
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 mentions the output is 'LLM-friendly' but doesn't specify format, size limits, or whether it's a read-only operation. For a tool that likely interacts with a browser, this leaves critical behavioral traits undocumented.
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 unnecessary words. It's appropriately sized and front-loaded, with every part contributing to understanding the tool's function.
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 browser interactions and the lack of annotations or output schema, the description is insufficient. It doesn't explain what an 'accessibility tree snapshot' entails, how it's structured, or what the agent can expect as a result, leaving significant gaps for effective tool 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 1 parameter with 0% description coverage. The tool description adds no information about the 'selector' parameter—what it selects, its syntax, or examples. This fails to compensate for the schema's lack of documentation, leaving the parameter's purpose unclear.
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 verb ('Get') and resource ('accessibility tree snapshot'), and specifies the purpose ('for LLM-friendly element identification'). However, it doesn't explicitly differentiate from sibling tools like browser_get_html or browser_take_screenshot, which also retrieve page content but in different formats.
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 when this snapshot is preferable over HTML or screenshot methods, nor does it specify prerequisites or exclusions. The context is implied through the tool name but not articulated.
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 |
|---|---|---|---|
| fullPage | No | ||
| selector | No |
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 what the tool does but lacks critical details: it doesn't specify if this requires page visibility, what format the screenshot returns (e.g., image data, file path), potential errors, or performance implications. This is inadequate for a tool with mutation-like effects.
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 with no wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose 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 the complexity (a screenshot tool with potential side effects), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address return values, error conditions, or behavioral nuances, leaving significant gaps for an AI agent to use it correctly.
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 0%, so the description must compensate for undocumented parameters. It mentions 'current page or a specific element', which loosely relates to the 'fullPage' and 'selector' parameters but doesn't explain their semantics, defaults, or interactions (e.g., that 'fullPage' defaults to false). This adds minimal value beyond the schema.
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 a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'browser_snapshot' which might have overlapping functionality, preventing a perfect score.
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 like 'browser_snapshot' or other screenshot-related methods. It mentions 'current page or a specific element' but doesn't clarify scenarios or exclusions, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into an input field specified by selector
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ||
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states what the tool does but doesn't disclose important traits like whether it waits for the selector to exist, handles special keys, validates input, or what happens on failure. This leaves significant gaps for a mutation tool.
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 function without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place.
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 tool's complexity (a mutation operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error conditions, return values, or integration with sibling tools, leaving the agent with insufficient context for reliable 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?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds some meaning by explaining that 'selector' specifies an input field and 'text' is what to type, but it doesn't clarify selector syntax (e.g., CSS, XPath) or text handling (e.g., encoding, line breaks). This partial compensation justifies a baseline score.
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 ('Type text') and target ('into an input field specified by selector'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like browser_click or browser_evaluate, which might 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the browser must be navigated to a page first), exclusions, or comparisons to siblings like browser_click for different interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for an element to appear on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | ||
| timeout | No |
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 mentions waiting for an element to appear but fails to specify what happens on timeout (e.g., error or return), if it polls continuously, or any performance implications. This leaves significant gaps in understanding 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.
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 and efficiently conveys the core purpose without unnecessary details, making it highly concise and well-structured.
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 tool's complexity (waiting with timeout), lack of annotations, and no output schema, the description is incomplete. It does not cover error handling, return values, or interaction with page state, which are crucial for effective use in a browser automation context.
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 0%, so the description must compensate for undocumented parameters. It implies a 'selector' parameter but does not explain its format (e.g., CSS selector) or the 'timeout' parameter's unit (e.g., milliseconds). This adds minimal meaning beyond the bare schema.
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 verb ('wait for') and resource ('element'), specifying that it waits for an element to appear on a page. However, it does not explicitly differentiate from sibling tools like browser_navigate or browser_refresh, which might also involve waiting implicitly, so it falls short of a perfect score.
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 scenarios like waiting after navigation or before interacting with elements, nor does it reference sibling tools for context, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
browser_clickbrowser_evaluatebrowser_file_uploadbrowser_get_htmlbrowser_navigatebrowser_refreshbrowser_snapshotbrowser_take_screenshotbrowser_typebrowser_wait_forEach tool has a clearly distinct purpose with no overlap: clicking, executing JavaScript, uploading files, extracting HTML, navigating, refreshing, taking accessibility snapshots, taking screenshots, typing text, and waiting for elements. The descriptions specify unique actions on the browser/page, making misselection unlikely.
All tool names follow a consistent 'browser_' prefix with a descriptive verb or action (e.g., click, evaluate, navigate). This snake_case pattern is uniform across all 10 tools, providing predictable and readable naming.
With 10 tools, the count is well-scoped for a Playwright automation server. Each tool earns its place by covering essential browser interactions like navigation, interaction, content extraction, and waiting, without being excessive or thin for the domain.
The tool set covers core Playwright workflows comprehensively, including navigation, interaction, content retrieval, and monitoring. Minor gaps exist, such as missing tools for handling dialogs, managing cookies, or executing more complex sequences, but agents can work around these with the provided tools.
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…
A Model Context Protocol server for Wix AI tools
Live browser debugging for AI assistants — DOM, console, network via MCP.
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/b3nw/playwright-browserless-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
