Playwright MCP Tools: Every Tool, With Examples

Playwright MCP tools at a glance

Playwright MCP tools are the functions that Microsoft's official Playwright MCP server gives an AI assistant such as Claude, Copilot or Cursor. The model calls browser_navigate to open a page, browser_snapshot to read its accessibility tree, and browser_click or browser_type to act on the element references in that tree. You type plain English and the assistant picks the tool. This page lists every tool in the current README, what each one does, its key parameters and a prompt that triggers it.

For what the server is and how it fits together, start with the Microsoft Playwright MCP guide. To install it, follow the 5-minute setup guide. This page is the tool reference.

How the tools work: refs, not pixels

Almost every interaction tool takes a target parameter. It is either an element reference from the latest snapshot (such as e42) or a unique selector. Many also take an optional element, a human-readable description like "Sign in button" that the client shows when it asks you to approve the action.

So the normal loop is: navigate, snapshot, act on a ref, then snapshot again. With the default --snapshot-mode full, action tools return a fresh snapshot in their response, which is why the model rarely needs to call browser_snapshot itself. Tools are also marked read-only or not. Read-only tools such as browser_snapshot, browser_find and browser_network_requests only observe the page.

Core automation tools (on by default)

These 24 tools load with no flags. They cover navigation, reading the page, every common input, waiting, JavaScript, console and network inspection.

Tab management (on by default)

Test assertion tools (--caps=testing)

This is the group QA engineers want. Without it, the model can click around but has no tool that returns a locator or gives a pass/fail check. With it, the model can ask Playwright for the locator it would use and confirm what is on screen.

DevTools tools (--caps=devtools)

Tracing, video, highlighting and action recording all live in this group. There is no separate tracing capability in the current README: browser_start_tracing and browser_stop_tracing are DevTools tools.

Network tools (--caps=network)

Reading requests is core. Changing them (mocks and offline mode) needs this group.

Storage tools (--caps=storage)

Cookies, localStorage, sessionStorage and saved storage state. The last two are the ones that matter for staying logged in; see Playwright MCP authentication for the full pattern.

Coordinate-based tools (--caps=vision)

These act on x/y pixel positions instead of element refs. Use them for canvas apps, maps, charts or anything that has no useful accessibility tree.

PDF and config tools (--caps=pdf, --caps=config)

Bonus: webmcp_* tools from the page

Since v0.0.82, if a page registers tools through the experimental WebMCP browser API, the server lists them as real MCP tools named webmcp_<tool>. They follow the current tab, so the list changes as you browse. Their names, descriptions and results come from the page, so the release notes say to treat them as untrusted input. Turn them off with --no-webmcp.

How to enable opt-in tool groups

Pass a comma-separated list to --caps. In an MCP client config the flag goes into args:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--caps=testing,devtools"
      ]
    }
  }
}

With the Claude Code CLI, put -- before the server command so Claude Code doesn't try to read --caps as its own flag:

claude mcp add playwright -- npx @playwright/mcp@latest --caps=testing,devtools

You can also set the environment variable PLAYWRIGHT_MCP_CAPS=testing,devtools, or use a config file passed with --config:

{
  "capabilities": ["core", "testing", "devtools"],
  "browser": { "browserName": "chromium" },
  "snapshot": { "mode": "full" }
}

Only enable what you need. Every tool's name and schema is sent to the model, so turning on all seven groups adds 47 tool definitions to its context.

Snapshot mode vs vision mode

Playwright MCP is snapshot-first. The README describes it as working on "structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models." Vision is an add-on, not a separate mode you switch to.

Related switches: --snapshot-mode none stops action tools from returning a snapshot (the model calls browser_snapshot when it wants one), --snapshot-boxes adds each element's bounding box to snapshots, and --image-responses omit stops screenshots from being sent to the client at all.

Which tools matter most for writing tests

If your goal is a committed .spec.js file rather than a one-off browser task, these are the tools that do the work:

1. browser_navigate + browser_snapshot: the model learns the real roles and names on the page instead of guessing selectors.
2. browser_find: locates one element without pulling the whole tree, which keeps long sessions cheaper.
3. browser_click, browser_type, browser_fill_form, browser_select_option: walk the flow once so you know it works before it is written down.
4. browser_generate_locator (--caps=testing): returns the locator Playwright would use, so the test uses getByRole-style locators rather than brittle CSS.
5. browser_verify_* (--caps=testing): confirm the expected outcome live, then turn each check into an expect().
6. browser_start_recording / browser_stop_recording (--caps=devtools): you click through the flow yourself and get Playwright code back.
7. browser_start_tracing / browser_stop_tracing (--caps=devtools): a trace of the exploration helps when the generated test fails later.

A prompt that uses all of them:

Open https://demo.playwright.dev/todomvc. Add two todos, complete the first,
and filter by Active. Use browser_generate_locator for every element you touch
and browser_verify_text_visible for the result. Then write
tests/todo.spec.js with @playwright/test using those locators.

The --codegen flag sets the language of the Playwright code the server reports (typescript, python, java, csharp or none). Then run the file with npx playwright test like any other test. No MCP is needed at run time. For the end-to-end workflow with Claude, see Playwright MCP Server + Claude AI.

Token cost: why fewer tools is cheaper

Every tool you enable costs context before the model does anything: its name, description and JSON schema are sent with each request. Then each action returns a page snapshot, and on a large page that is the biggest cost. The README itself says coding agents may be better served by the Playwright CLI with skills, because it avoids "loading large tool schemas and verbose accessibility trees into the model context."

• Enable only the --caps groups the task needs.
• Prefer browser_find over a full browser_snapshot when looking for one element.
• Use depth or a target on browser_snapshot, or save it with filename.
• Try --snapshot-mode none or --mobile (the README notes mobile pages are usually lighter).

The numbers are compared in Playwright MCP Server vs CLI: token cost comparison. If you work in Claude Code, also read Playwright CLI for Claude Code.

Learn Playwright + Claude AI

Knowing the tool list is step one. The Playwright + Claude AI & MCP Server course teaches Playwright in JavaScript from scratch, then shows how to drive the MCP server with Claude to explore an app and turn what it finds into tests you commit: Page Object Model, API testing and CI/CD with GitHub Actions included. It's rated 4.5★ from 130+ ratings, with 510+ students enrolled.

Playwright MCP pricing: is it free?

Yes. @playwright/mcp is open source under the Apache 2.0 licence, like Playwright itself, so there is no Playwright MCP pricing tier, licence or per-seat fee. What you do pay for is the AI model on the other end: every tool call sends page context to the LLM, so the real cost is tokens from Claude or whichever model you use. That's why the tool count matters: fewer enabled tools and smaller snapshots mean fewer tokens per step. See the Playwright CLI vs MCP token cost comparison for real numbers. Cloud browsers, if you choose to run the browser remotely, are billed separately by their providers.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn