Playwright MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port the auth gate binds to; Render routes to it. | 10000 |
| MCP_TOKEN | Yes | Required. Bearer token every request must present. The container refuses to start without it. On Render this is generated for you at deploy time; rotate by editing the value (or clicking Generate again) in the Dashboard and updating your clients. | |
| UPSTREAM_PORT | No | Loopback port the MCP server listens on behind the gate. Change only if it collides with something inside the container. | 8931 |
| PLAYWRIGHT_MCP_ALLOWED_HOSTS | No | Comma-separated list of allowed hosts for the server's host check (e.g. myapp.com,myapp.onrender.com; * disables the check). The entrypoint scopes the server's host check to your service's own onrender.com hostname automatically via Render's RENDER_EXTERNAL_HOSTNAME, but if you add a custom domain you must set this. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browser_closeB | Close the page |
| browser_resizeB | Resize the browser window |
| browser_console_messagesB | Returns all console messages |
| browser_handle_dialogC | Handle a dialog |
| browser_evaluateB | Evaluate JavaScript expression on page or element |
| browser_file_uploadB | Upload one or multiple files |
| browser_dropA | Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided. |
| browser_fill_formB | Fill multiple form fields |
| browser_press_keyB | Press a key on the keyboard |
| browser_typeB | Type text into editable element |
| browser_navigateC | Navigate to a URL |
| browser_navigate_backA | Go back to the previous page in the history |
| browser_network_requestsA | Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details. |
| browser_network_requestA | Returns full details (headers and body) of a single network request, or a single part if |
| browser_run_code_unsafeA | Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent. |
| browser_take_screenshotA | Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions. |
| browser_snapshotB | Capture accessibility snapshot of the current page, this is better than screenshot |
| browser_clickB | Perform click on a web page |
| browser_dragA | Perform drag and drop between two elements |
| browser_hoverA | Hover over element on page |
| browser_select_optionB | Select an option in a dropdown |
| browser_tabsA | List, create, close, or select a browser tab. |
| browser_wait_forA | Wait for text to appear or disappear or a specified time to pass |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools target clearly distinct actions (click, hover, drag, navigate, type). A few pairs risk confusion: browser_network_requests vs browser_network_request (singular/plural), browser_drag vs browser_drop, and browser_type vs browser_fill_form, though descriptions give some guidance.
Every tool uses the browser_ prefix with snake_case and an action-oriented name, forming a highly predictable pattern. The singular/plural network tools are the only minor wrinkle but still follow the convention.
23 tools is on the heavier side but each maps to a genuine browser-automation capability (navigation, input, forms, dialogs, network, console, snapshots, tabs, waiting). It's reasonable for the breadth of the domain rather than redundant.
Coverage spans navigation, interaction, form filling, file upload/drag, dialogs, network and console inspection, screenshots, and tab management—solid for browser automation. Minor gaps like forward navigation and explicit cookie/storage or viewport-state management are workarounds via evaluate/run_code.