Microsoft Playwright MCP gives an MCP client persistent browser control using Playwright and structured page state. It is designed for exploratory browser tasks where an agent needs to inspect and interact with a live page.
Key takeaways
- Uses structured accessibility information instead of relying only on screenshots.
- Browser profiles and authenticated sessions can contain highly sensitive data.
- Microsoft notes that command-line Playwright plus skills may be more token-efficient for many coding tasks.
What is Microsoft Playwright MCP?
Official Playwright MCP server for browser automation through structured accessibility snapshots and browser actions. MCP standardizes how a compatible client discovers and invokes tools, but it does not make those tools safe automatically. The client, server, credentials and upstream service remain separate trust boundaries.
What tools does it expose?
- Navigate pages and inspect accessible page structure.
- Click, type, select, upload and perform other browser interactions.
- Manage tabs, screenshots and browser state.
- Optionally connect to existing or isolated browser profiles.
The exact catalog can change by release, account, enabled feature or server configuration. Inspect the live tool list and JSON schemas before enabling it. A descriptive tool name is not an authorization control, and a read-sounding operation can still reveal sensitive metadata.
What is a safe first test?
Open a public test site in an isolated browser profile and perform navigation plus a harmless search. Keep uploads, downloads, authentication and form submission disabled until domain restrictions and confirmation behavior are understood.
Use a test account or project, allow only the required tools and record the client configuration, server version and arguments. Verify the result directly in the upstream service. Add write tools only after read-only behavior, authentication expiry, error handling and audit logs have been reviewed.
What data and credentials can it access?
The server can see page text, form values, cookies and any account data available to the controlled browser profile. Browser actions may send data to third parties or trigger external changes.
Credentials should be supplied through the documented OAuth flow, a secret manager or a restricted environment variable, never pasted into prompts or committed to source. The upstream account should expose only the resources required for the pilot.
Which permissions should you grant?
- Access only to an isolated browser profile for the pilot.
- A domain allowlist enforced outside the prompt when possible.
- Filesystem access for uploads or downloads only when explicitly required.
Prefer project-scoped, read-only or restricted tokens. Where the server offers tool filters, combine them with upstream authorization rather than treating filtering as the only control. Separate development and production identities and rotate test credentials after the evaluation.
What should a security review cover?
- Treat every page as an untrusted prompt-injection source.
- Never reuse a personal browser profile with saved passwords or payment data.
- Require confirmation for submissions, purchases and account changes.
Assume tool results can contain prompt injection or hostile content. Keep approval gates in application code for financial, administrative, destructive or public actions. Apply network restrictions, timeouts, output-size limits and audit logging at the host or gateway layer.
What are the main limitations?
- Dynamic sites, bot detection and accessibility gaps can break actions.
- Browser control is less stable than a supported API.
- Persistent sessions increase credential and privacy risk.
This is a documentation-based profile checked on 2026-10-04; Anavem did not connect the server or test it against a live account. Tool catalogs, transport support, pricing, licensing and authentication methods can change. Verify the current first-party documentation before installation.