even-better-playwright-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| browser | No | Browser to use: chromium, firefox, webkit (default: chromium) | chromium |
| headless | No | Run browser in headless mode (default: false) | false |
| cdp-endpoint | No | Connect to existing browser via CDP endpoint | |
| user-data-dir | No | Use persistent browser profile directory |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| snapshotA | Get compressed accessibility snapshot with ref IDs. Returns: DOM tree with [ref=e1], [ref=e2] etc. Use refs with execute tool: await $('e1').click() Call again after navigation (refs become stale). Options:
|
| screenshotA | Capture page screenshot. Options:
When withLabels is used, labels are color-coded by role:
|
| browser_executeA | Execute Playwright code with these in scope:
Rules
Checking Page StateAfter any action (click, submit, navigate), verify what happened: For visually complex pages (grids, galleries, dashboards), use screenshotWithAccessibilityLabels({ page }) instead. Accessibility SnapshotsExample output: Use aria-ref to interact - NO quotes around the ref value: For pagination: Choosing snapshot method:
Selector Best PracticesFor unknown sites: use accessibilitySnapshot() with aria-ref For development (with source access), prefer:
If locator matches multiple elements (strict mode violation), use Working with PagesNavigationCommon PatternsPopups: page.evaluateCode inside page.evaluate() runs in the browser - use plain JavaScript only. console.log inside evaluate runs in browser, not visible here: Utility Functions
Network InterceptionFor scraping/reverse-engineering APIs, intercept network instead of scrolling DOM: Then trigger actions and analyze: IMPORTANT: After navigation, refs are stale - call snapshot tool again. |
| browser_search_snapshotA | Search current snapshot with regex. Requires: Call snapshot first. Returns: Matching lines with refs. Options:
Use this to find specific elements in large pages without re-reading the entire snapshot. |
| browser_network_requestsA | Get captured network requests from the browser. Automatically starts capturing when first called. Use includeStatic:true to include images/CSS/fonts. Returns recent requests with status, timing, and response previews. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Debugger API | CDP Debugger API - set breakpoints, step through code, inspect variables |
| Editor API | CDP Editor API - view and live-edit page scripts and CSS at runtime |
| Styles API | CDP Styles API - inspect CSS styles applied to elements |
TDQS
Scored across 5 tools
Each tool has a distinct and non-overlapping purpose: browser_execute runs code, browser_network_requests captures network data, browser_search_snapshot searches snapshots, screenshot captures images, and snapshot retrieves accessibility data. There is no ambiguity in their functions.
All tool names follow a consistent snake_case pattern with a 'browser_' prefix for three tools and simple nouns for the others, creating a clear and predictable naming scheme. The structure is uniform and easy to understand.
With 5 tools, the server is well-scoped for browser automation, covering execution, network monitoring, snapshot searching, screenshot capture, and accessibility snapshot retrieval. Each tool serves a unique and essential function without redundancy.
The tool set provides comprehensive coverage for browser automation tasks, including interaction, monitoring, and inspection. A minor gap exists in lacking a dedicated tool for browser context/page management (e.g., opening/closing pages), but this is mitigated by instructions within browser_execute.