Playwright MCP Actor (Standby) avatar

Playwright MCP Actor (Standby)

Pricing

Pay per usage

Go to Apify Store
Playwright MCP Actor (Standby)

Playwright MCP Actor (Standby)

Exposes an interactive, per-step Playwright browser automation MCP server. Runs in Standby mode so an AI agent (Make.com, n8n) can call navigate/click/fill/screenshot tools one at a time against a live browser session, instead of running one blind generated script.

Pricing

Pay per usage

Rating

0.0

(0)

Developer

Rakame Monarka

Rakame Monarka

Maintained by Community

Actor stats

0

Bookmarked

1

Total users

0

Monthly active users

5 days ago

Last modified

Share

Runs a live, interactive browser (Playwright/Chromium) as an MCP server, so an AI agent (Make.com AI Agent, n8n AI Agent, Claude, etc.) can drive it one step at a time instead of generating one blind script upfront. This solves multi-step/wizard forms, unexpected popups, and syntax-error-prone generated pageFunction code.

How it works

This Actor runs in Standby mode: it stays alive as an HTTP server and is billed only while running.

Connect your MCP client to:

POST https://<actor-standby-hostname>/mcp

with header Authorization: Bearer <APIFY_TOKEN>.

Session isolation

Every browsing task gets its own isolated Chromium BrowserContext (separate cookies, page, and video recording). Concurrent callers never share a page.

  • If your MCP client keeps one connection open for a whole task (e.g. Make.com's MCP Tools module), you don't need to do anything — the Actor uses your MCP transport session automatically.
  • If your MCP client opens a new connection on every single tool call (e.g. n8n's MCP Client Tool node), pass an explicit session_key argument (any string you choose, e.g. a UUID you generate once per task) on every tool call and reuse the same value throughout the task. Without it, each call would land on a fresh blank page with no memory of the last one.

Idle sessions (no calls for 60s) are closed automatically. To keep the container from running out of memory under heavy concurrent use, only a limited number of browser sessions run at once (default 5); a new session beyond that limit fails with a clear, retryable error instead of degrading everyone else's session.

Tools

  • browser_navigate(url, session_key?)
  • browser_snapshot(session_key?) — returns visible interactive elements with stable refs (e0, e1, ...). Call after navigating or after any action that changes the page.
  • browser_fill(ref, value, session_key?)
  • browser_click(ref, session_key?)
  • browser_select_option(ref, value, session_key?)
  • browser_press_key(key, session_key?)
  • browser_wait_for({ text?, timeoutMs?, session_key? })
  • browser_screenshot(session_key?) — returns a base64 PNG and a public URL
  • browser_report_progress(message, webhook_url, channel_id, thread_ts?, session_key?) — POSTs a live progress screenshot to a webhook of your choice (e.g. one that posts to Slack) mid-task
  • browser_close(session_key?) — ends the session, returns a public URL to the recorded video

Notes

  • Browsers launch with headless: false under Xvfb (matches common anti-bot-fingerprint preferences).
  • Never wired to click final submit/confirm/pay buttons automatically — that's left to the calling agent's own instructions/guardrails.