Skip to content

Blog

Playwright MCP setup: browsers, profiles and checks

Set up Playwright MCP with an isolated browser. JSON example, first page visit, profile conflicts and a practical acceptance test for your website.

Published on · by tracevero · Reading time 4 minutes (694 words)

You want to open a website through MCP and inspect its controls. Start with a public test page and a specific goal: the expected heading should appear, and a chosen link should reach the right destination. This gives you a concrete browser task to verify. A server that starts successfully has not yet answered that question. Write down the address and expected result before you begin.

Browser interaction or a simple page fetch?

A browser is a useful test route for interfaces with navigation and forms. If you only need the text at a known address, first compare the Fetch guide. The browser directory shows declared server properties. Similar names do not replace a check of the package identity and provider source.

Define the acceptance scope
TaskExpected resultAdditional check
Open a public pageHeading and destination matchFinal address after redirects
Use navigationChosen destination appearsLink label and keyboard focus
Inspect an authenticated areaOnly the test account is visibleAccount name before any change

Configure an isolated profile

Microsoft documents the package @playwright/mcp. Its --isolated option keeps browser state in memory. The example below uses the mcpServers root; place it in a client file that accepts that format. Separate guides explain file placement for VS Code and Cursor.

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

The @latest tag is a moving target. Record the version actually used after your attempt, and choose a specific release for repeatable checks. Also record the client version, operating system and test address. If startup fails, follow the command and path diagnosis. A terminal and an editor may run with different environments even on the same computer.

Verify a complete browser journey

Your acceptance test 1. Prepare Record the target 2. Open Read the heading 3. Interact Compare the destination
Suggested checks for your own environment, not a completed server test.
  1. Inspect the available tool list. Choose the navigation operation it exposes and open your public test address.

  2. Read the page structure. Compare the heading and final address with your independently recorded expectation.

  3. Follow a predetermined link. Check the result again, including a new tab or redirect if one occurs.

  4. Close the browser and repeat the journey. Record whether both attempts reach the same page and expected content.

For the first attempt, choose a link without side effects. You can then add your own test case involving form fields. Separate filling a form from submitting it, and inspect the state before the final step. A screenshot helps when the question concerns layout or clipped content. Record the viewport width so that a later visual comparison uses equivalent conditions. Keep the original expectation alongside both results.

Diagnose profile conflicts and lost sign-in state

A persistent profile cannot be used by multiple browser instances at the same time. Give parallel clients separate profiles or isolated sessions. Isolated mode loses session state when the browser closes. Having to sign in again is therefore not automatically a defect. Before reporting an issue, check which profile mode the actual launch command selected.

A useful handover needs only a small report: starting address, selected action, expected result and observed difference. State whether the connection failed or whether the failure happened during navigation. The Inspector guide helps separate these stages. Avoid changing the client, package release and website at the same time during diagnosis; that leaves the cause unresolved even if the next attempt succeeds.

Is Playwright MCP the same as a test suite?
Plan repeated checks with explicit expectations and recorded results. A single browser action establishes only the outcome of that attempt.
Do I need my normal browser profile?
A public page in an isolated profile is enough for the first attempt. Your personal profile is unnecessary for that test.
Why is my sign-in gone after closing?
Check the profile mode first. An isolated session is deliberately temporary.
Has tracevero tested every listed browser server?
No. The directory reports sources and declared properties. This guide describes a test workflow for your own environment.

Provider documentation checked on 1 October 2026. The test plans and examples are editorial suggestions.

  1. Microsoft: Playwright MCP
    Show retrieval commandcurl -s https://github.com/microsoft/playwright-mcp

Put it into practice

All posts

tracevero · https://tracevero.com/blog/playwright-mcp-setup