WebMCP vs Playwright vs Firecrawl: Which Should Your Agent Use?

Here is the whole decision in one line. If the site your agent needs to touch ships WebMCP tools, call them. If it does not, and you need to click through a real UI, use Playwright MCP. If you are reading public pages at scale, use Firecrawl. The rest of this guide is why, and where each one bites.

The reason this became a live question at all is a Chrome origin trial. WebMCP entered an origin trial in Chrome 149 on June 9, 2026 (per Chrome for Developers). It is a proposed browser standard, authored in the W3C Web Machine Learning Community Group and worked on by Google and Microsoft engineers (per InfoQ, whose title flags it as a "standard proposal," and the W3C community group repo). It is not GA. There is no announced ship date to stable Chrome. Treat everything here as "usable behind an origin-trial token today," not "done."

What it does is narrow and useful. A site that adopts WebMCP hands an in-browser agent a list of typed, named tools it can call, instead of making the agent screenshot the page and guess where to click. That is the entire idea. It does not kill scraping. It opens a second lane that only exists on sites that opt in, which means your agent needs a plan for both lanes. So does your decision.

The one thing to walk away with

Cooperation is the axis. Every other factor (speed, token cost, reliability) falls out of a single question: does the target site cooperate with your agent or not?

A WebMCP-enabled site cooperates. It publishes the tools, the parameters, the schema. Your agent calls a function and gets a structured result. A plain site does not cooperate, so your agent has to operate the human UI, and now you are choosing between driving a real browser (Playwright MCP) and reading rendered text (Firecrawl). Hold that split in your head and the table at the bottom writes itself.

What WebMCP actually does: two APIs

WebMCP defines two ways for a site to expose tools. Both let an agent skip the screenshot-and-guess loop.

The Declarative API annotates an existing HTML form. You add attributes to the <form> and the browser surfaces it to in-browser agents as a declared tool, no JavaScript required:

<form
  toolname="Search flights"
  tooldescription="Searches flights for a route and dates, then displays results"
  toolautosubmit>
  <input name="origin" />
  <input name="destination" />
  <input name="depart" type="date" />
</form>

That block is straight from the WebMCP declarative-API explainer (reproduced by InfoQ). The agent reads toolname and tooldescription, fills the fields with typed values, and toolautosubmit lets it submit without a separate click. If your site already runs on forms, this is the cheapest possible way in.

The Imperative API is the one you reach for when a form cannot express the action. You register a tool in JavaScript through the modelContext interface, so it runs in the page's own JS context and can hit internal APIs an HTML form never could:

navigator.modelContext.registerTool({
  name: "toggle_layer",
  description: "Add, remove, or toggle a pizza layer (sauce, cheese).",
  inputSchema: {
    type: "object",
    properties: {
      layer: { type: "string", enum: ["sauce-layer", "cheese-layer"] },
      action: { type: "string", enum: ["add", "remove", "toggle"] },
    },
    required: ["layer"],
  },
  execute: async ({ layer, action }) => {
    await toggleLayer(layer, action);
    return `Performed ${action || "toggle"} on layer: ${layer}`;
  },
});

The shape of this example follows the WebMCP imperative-API docs, reproduced by InfoQ. One nuance the coverage tends to gloss: the registration object surface has been styled as both document.modelContext and navigator.modelContext across explainer drafts and secondary write-ups during the trial, so pin your integration to the current WebMCP docs rather than a blog snippet. The execute function does the real work: it mutates page state, calls whatever backend it needs, and returns a payload straight to the agent. No DOM round-trip.

The catch nobody markets: exposing your own functions to an agent is a security surface. The proposal authors call out indirect prompt injection directly, and the spec adds annotation hints for it. Externally sourced data should carry an untrustedContentHint so the agent treats it with scrutiny; a non-mutating read can carry a readOnlyHint so the agent knows human confirmation is safe to skip (per InfoQ, summarizing Chrome's tool security guidance). If a refund tool is callable but your refund policy logic lives elsewhere and is stale, an agent will execute the wrong refund cleanly and confidently. Ship the tool, ship the guardrail.

What Playwright MCP does

Playwright MCP (@playwright/mcp, maintained by Microsoft) is the pragmatic default when the target site has no WebMCP and you still need to operate its UI. Instead of feeding the model screenshots, it drives the browser and passes structured accessibility snapshots back, so the agent works from the accessibility tree, not pixels (per the playwright-mcp README). No vision model, deterministic actions, and it runs across Chromium, Firefox, and WebKit.

Why that matters for cost and reliability: a screenshot-action-screenshot loop chews through context fast and breaks the moment an ad shifts the layout. Working from structured accessibility data avoids both problems. It is the difference between describing a page and photographing it every step. Playwright MCP is not site-cooperative (it works whether the site wants it to or not) which is exactly why you use it on the vast majority of the web that has never heard of WebMCP.

One early implementer forked the Chrome DevTools MCP server to run WebMCP tools from client-side JavaScript and reported a roughly 90% drop in LLM token usage against the screenshot-loop baseline, plus better speed and determinism (per an HN Show HN report cited by InfoQ). That is one developer's benchmark on one polyfill, not a Playwright number, so read it as a directional signal for why structured tools beat screenshots, not a spec guarantee. The direction is the point: the more structured the interface an agent works against, the cheaper and steadier the run.

What Firecrawl does

Firecrawl sits in a different lane entirely: reading. It crawls public URLs and returns LLM-ready Markdown, which is the format you want when the job is building a knowledge base or feeding a RAG pipeline, not clicking buttons. Firecrawl reports its clean Markdown output cuts LLM token consumption by 67% versus raw HTML (per the Firecrawl blog). The free tier is 1,000 credits a month including five hours of browser usage, with paid plans from $16 a month (per the same Firecrawl post), and there is a keyless free tier your agent can hit to search and scrape without provisioning a key first.

Two features make it the right pick for read-heavy work rather than a general driver. Its MCP server means a coding agent (Claude Code, Cursor, Codex) gets web access without wiring up your own browser. And /monitor pings your agent when watched pages change, so a change-detection pipeline sends diffs on a schedule instead of re-crawling everything. If your pipeline is "read the public web, keep it fresh, hand clean text to a model," this is the shortest path. You can start on the free tier and see whether 1,000 credits covers your month before you pay anything.

Where Firecrawl is the wrong tool: anything interactive behind auth on a site with no cooperation. Reading is not clicking. For a form submit on an uncooperative site, you are back to Playwright MCP.

Which to use: the decision table

Five common jobs, one pick each. This is the part to bookmark.

Job	Right tool	Why
Target site ships WebMCP tools	WebMCP	Typed function call, no scraping, structured result
You control the browser and need cross-browser coverage on an uncooperative site	Playwright MCP	Accessibility-tree driving works on any site, Chromium/Firefox/WebKit
Reading public pages, building a knowledge base, monitoring changes	Firecrawl	LLM-ready Markdown at scale, /monitor diffs, keyless free tier
Filling a form on a site with no WebMCP	Playwright MCP	Drives the real UI deterministically without vision
Submitting to an internal API behind a login on a WebMCP-enabled site	WebMCP Imperative API	execute runs in the page's JS context and can reach backend calls a form cannot

Notice the table is not a ranking. WebMCP does not beat Playwright; it needs a cooperative site to exist at all. Firecrawl does not beat WebMCP; it reads, it does not act. Each row is a different job, and the job picks the tool.

What to do now

If you build a SaaS product, register for the origin trial and wire WebMCP tools into your two or three highest-intent flows (search, checkout, ticket creation are the ones Chrome keeps using as examples). The payoff is that a browser-integrated agent can drive your product natively instead of fumbling your UI, and you decide which actions it can take. Keep the tool descriptions tight; Chrome's guidance caps them at 500 characters per tool and 150 per parameter, and an agent that gets a clear description picks the right tool more often (per InfoQ). But scope it: origin trials are time-limited and the API can still shift before it stabilizes, so do not bet a production dependency on the current object shape.

If you build agents, keep Playwright MCP as your general-purpose driver today, because the cooperative-site population is small and the trial is Chrome-only for now. Add WebMCP tool support to your agent client so that when a site does cooperate, you take the cheaper structured path. The two are complements, not a migration.

If you scrape public content at scale, Firecrawl is purpose-built for turning public pages into clean text, and its /monitor feature watches pages for changes on a schedule. WebMCP will not touch this job; it is about acting on cooperative sites, not reading uncooperative ones.

The verdict

Use WebMCP if the target site publishes tools and you want a typed, structured call instead of a screenshot guess, and you can live behind an origin-trial token until the standard settles.

Use Playwright MCP if you are driving an uncooperative UI, need cross-browser coverage, or want the reliable general-purpose default that works on the whole web today.

Use Firecrawl if the job is reading public pages into LLM-ready Markdown, building a knowledge base, or watching pages for changes, where clean text at scale beats operating a browser.