← Back to blog
Comparison··7 min read

Playwright MCP vs Rendershot MCP: choosing a browser MCP server in 2026

Two MCP servers, both built around Playwright, that solve almost completely different problems. Here's when to use each — and the cost tradeoff that's hiding in the choice.

The first time someone asked me "Rendershot has an MCP server, but doesn't Microsoft's Playwright MCP do the same thing?" I gave a bad answer. I muttered something about local vs remote, lost their attention, and moved on. The honest answer is: these two servers overlap by exactly one tool — and they're answering completely different questions. Picking between them isn't a comparison, it's a use-case routing decision.

This post tries to make that routing decision obvious. If you're an agent builder, a developer plugging a browser into Claude Desktop / Cursor / Goose, or anyone evaluating which MCP server fits a specific workflow, the goal is to give you the decision in 60 seconds and the reasoning in 10 minutes.

Upfront: I build Rendershot, so treat this with the obvious bias. I've tried to keep the Playwright MCP claims pinned to its public README and source. If anything drifts out of date, that repo is the source of truth.

The short version

  • Pick Playwright MCP if you want an agent to drive a browser interactively on your local machine — clicking, typing, reading page state, exploring multi-step flows.
  • Pick Rendershot MCP if you want an agent to request finished renders (screenshots or PDFs) from a hosted API, one-shot, with no local browser to install or run.

These aren't competitors. They overlap by exactly one tool surface (browser_take_screenshot in Playwright MCP, capture_screenshot in Rendershot MCP) and the rest of the surface area solves entirely different problems.

If you're not sure which you want, ask yourself: do I want the agent to be in a browser doing things, or do I want the agent to be outside a browser and receive its output? The first is Playwright MCP. The second is Rendershot MCP.

What each one is

Playwright MCP (microsoft/playwright-mcp) is an MCP server from the Playwright team that exposes ~45 tools letting an LLM drive a real browser — Chromium, Firefox, or WebKit — running locally. It sends the agent the page's accessibility tree (not screenshots) as the primary way to "see" pages, which makes it deterministic and token-cheap. You install it as npx @playwright/mcp@latest inside Claude Desktop, Cursor, Claude Code, Goose, or any MCP-compatible client.

Rendershot MCP (@rendershot/mcp-server) is the MCP interface to Rendershot's hosted screenshot/PDF API. It exposes two tools — capture_screenshot and capture_pdf — that an agent calls when it needs an image or PDF of a URL. The agent sends a URL and parameters; the rendering happens on Rendershot's infrastructure; bytes come back. No local browser, no install beyond the MCP config line.

The fundamental split: interactive vs one-shot

Everything else flows from this:

  • Playwright MCP holds a persistent browser session. The agent navigates, the page state stays between tool calls, cookies stick, tabs accumulate. The agent can read the result of one action before deciding the next.
  • Rendershot MCP is stateless per call. Every render is independent. The agent sends a URL with optional auth context (cookies, headers, storage state) and gets bytes back. There's no "what's on the page right now" — there's "render this URL with these parameters."

That single difference cascades through every other dimension.

Setup

Playwright MCP:

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

First run downloads Chromium (~150 MB). Requires Node 18+. Once running, the MCP client can call any of the 45 tools.

Rendershot MCP:

{
  "mcpServers": {
    "rendershot": {
      "command": "npx",
      "args": ["@rendershot/mcp-server"],
      "env": { "RENDERSHOT_API_KEY": "sk_live_..." }
    }
  }
}

No browser download. Requires Node 18+. The API key is the only secret. First call hits Rendershot's fleet immediately.

Both take about a minute to install. Playwright MCP is slower on first run because of the Chromium download.

State and context

This is where the use cases diverge sharpest.

Playwright MCP keeps the browser open across tool calls within a session. An agent can:

  • Log in via a form, then visit five authenticated pages in sequence
  • Click a button, observe the resulting page, decide the next click
  • Hold cookies across hours of agent activity
  • Switch between multiple tabs with browser_tabs

Rendershot MCP doesn't have a session. Each tool call carries its own auth context. To screenshot an authenticated page, you pass the cookies (or storage state) as a parameter. To capture three pages from the same logged-in user, you pass the cookies three times. The agent doesn't "stay logged in" — there's no session to be logged into.

If your workflow is "find the failing flow in this app," Playwright MCP is the right shape. If your workflow is "screenshot these 50 URLs," Rendershot MCP is the right shape.

Concurrency

Playwright MCP runs one local browser on your machine. While it's rendering a page or waiting for a click, your other agent work (or your other tabs) compete for memory and CPU. Parallel renders aren't really a concept — you have one browser, one agent loop, one thing happening.

Rendershot MCP renders on a fleet of headless Chromium workers. The MCP client can issue many capture_screenshot calls in parallel; each one goes to a separate worker. You can fire 50 renders in 5 seconds without your laptop noticing.

If your workflow is interactive (one click at a time), concurrency doesn't matter. If your workflow is bulk (render N URLs as fast as possible), Playwright MCP becomes the bottleneck.

Cost

Playwright MCP is free as software. The cost is your hardware (the local Chromium burns RAM), your time (renders block while your machine works), and your context tokens. Even though the accessibility tree is token-cheap relative to screenshots, a complex page can still send 5–15K tokens of structured DOM per call, and a multi-step workflow stacks those.

Rendershot MCP charges per render — 1 credit each, with a free tier of 200 renders per month. Your laptop doesn't render anything; the agent's context only carries the tool call and the response URL, not the page contents.

For "I'm prototyping an agent that needs to look at three pages," Playwright MCP is cheaper. For "my agent renders 10,000 pages a month for a real workflow," Rendershot is cheaper — and dramatically faster — because the work isn't happening on your machine.

Multi-tenancy

Playwright MCP wasn't designed for serving multiple tenants out of one instance. The local browser holds one tenant's state at a time; switching tenants means clearing cookies and starting over.

Rendershot MCP creates a fresh BrowserContext per render with that render's specific auth parameters. Tenant A's cookies never see Tenant B's session. If you're building a product where end-users trigger screenshot/PDF renders through an agent, this matters. If you're a single developer using an agent for your own work, it doesn't.

Availability

Playwright MCP runs when your laptop is on, the MCP client is open, and the agent's process is alive. If your machine sleeps, the browser's gone. If you close Claude Desktop, the server stops.

Rendershot MCP works whenever the Rendershot API is up — 24/7, regardless of your local state. If you've wired Rendershot MCP into an automation that runs overnight, the renders happen overnight. Playwright MCP can't do that without your machine staying on.

One nuance — Playwright also ships a CLI/SKILLS variant

The Microsoft team now recommends a Playwright CLI + SKILLS approach for coding-agent use cases where MCP's token cost (accessibility-tree dumps per call) starts to bite. MCP stays right for stateful interactive loops; CLI/SKILLS is more efficient for high-throughput agentic coding workflows. If you're optimising for token cost on a coding agent, look at both.

This nuance doesn't affect the Playwright-MCP-vs-Rendershot-MCP decision — they still solve different problems — but worth flagging if you're evaluating Playwright MCP specifically.

When to pick which

Pick Playwright MCP if:

  • You want the agent in a browser, doing things across multiple steps
  • You're testing or exploring an app interactively
  • You're prototyping locally and don't want an API key for this
  • You need full browser primitives — clicks, form fills, network interception, JS execution, video recording

Pick Rendershot MCP if:

  • You want the agent to receive finished renders (PNG, PDF) of a URL
  • You're building a product or automation where renders happen at machine cadence, not human cadence
  • You don't want to run a local Chromium
  • You need multi-tenant safety, scheduled renders, webhooks on completion, or 24/7 availability
  • You'd rather pay per render than maintain a local browser

Use both if your agent does interactive exploration in development (Playwright MCP) and ships finished renders in production (Rendershot MCP). They compose cleanly; their tool surfaces don't collide.

Want to try Rendershot's MCP server? Grab an API key at rendershot.io/register and add the four-line config to your MCP client. Free tier includes 200 renders / month — enough to wire Rendershot into Claude Desktop or Cursor and try the pattern end-to-end before committing.

← More postsCreate an API key