Will WebMCP replace Playwright? Turning “guess the button” into tools the website provides

When I built an MCP server for NotebookLM, which has no public API, Playwright controlled the page: find the input, submit a question, wait for streaming to stop, then extract the answer from the screen. Version one worked quickly. Most of the work after that went into defenses against redesigns, stale answers, and the wrong DOM node.

So my first reaction to WebMCP was direct: if a website can tell an agent which tools it has, what parameters they take, and what happens when they run, can those selector fallback arrays finally go away?

My answer is: some of them can, but Playwright will not disappear. To explain why, we first need to remove a common misconception.

Start with the responsibility: Playwright is not guessing

A Playwright test that has already been written is deterministic code. It finds elements with the locator you specified. Playwright also waits for the element to be visible, stable, able to receive events, and enabled; if those conditions are not met, the action fails.

await page.getByLabel('Question').fill('What is WebMCP?');
await page.getByRole('button', { name: 'Submit' }).click();
await expect(page.getByRole('status')).toContainText('Submitted');

This code does not guess. Inference was needed before the code was written: which field is the question, which button means submit, and which state proves completion? When a person studies the product and writes the test, that is test design. When an AI agent reads the DOM at runtime and picks the element that looks most plausible, that is “guessing the button.”

Playwright does not recommend binding every test to brittle CSS classes either. Its guidance prioritizes user-facing semantics such as roles, labels, and visible text, with an explicit test-id contract when necessary. A well-designed Playwright test already minimizes guessing.

WebMCP changes who writes the tool contract

Traditional browser automation keeps the contract outside the website. The script knows which page to open, where to click, and what to wait for. The website does not know that the agent is trying to “submit a support request”; it only sees a sequence of mouse and keyboard events.

WebMCP moves the contract back into the website. A page can register a tool with a name, description, input schema, and execution function. Instead of reconstructing the whole interaction, the agent sees a capability the website has chosen to provide:

document.modelContext.registerTool({
    name: 'submit_support_request',
    description: 'Submit a support request and return its ticket ID',
    inputSchema: {
        type: 'object',
        properties: {
            subject: { type: 'string', description: 'Issue subject' },
            details: { type: 'string', description: 'Issue details' },
        },
        required: ['subject', 'details'],
    },
    execute: ({ subject, details }) =>
        submitSupportRequest({ subject, details }),
});

The difference is larger than “fewer clicks.” Previously, the agent inferred intent from the page and translated that intent into gestures. Now the site provides a named tool whose arguments can be validated first. As long as the contract stays stable, an interface redesign does not require the agent to discover where the button moved.

That also defines its boundary: the website developer must add WebMCP, and its tools are bound to the currently open page and session. It does not suddenly give every website a universal API, and it is not another name for a remote backend MCP server.

An HTML form can become a tool without a hidden second flow

WebMCP has another direction I find even more interesting than JavaScript registration: the declarative API. Add toolname, tooldescription, and parameter descriptions to an existing form and an agent can discover it. The form remains visible and usable by a person.

<form
    toolname="search_articles"
    tooldescription="Search articles on this website"
    toolautosubmit
>
    <input
        name="query"
        required
        toolparamdescription="Topic or keyword to search for"
    />
    <button type="submit">Search</button>
</form>

This is healthier than building a hidden shortcut only the agent knows. The person and agent see the same form and enter the same submit event, which makes it less likely that the product grows two drifting implementations.

WebMCP and Playwright occupy different positions

For “let an agent perform a structured action on a cooperating website,” WebMCP can remove a great deal of DOM exploration and clicking. For “prove that a user can check out in Safari and can see the error message,” WebMCP does not replace Playwright at all.

Playwright can also intercept network traffic, mock responses, retain traces, compare screens, and run the same flow in Chromium, Firefox, and WebKit. Those are browser control and testing capabilities. A tool schema on the page does not make them less valuable.

What part can WebMCP actually replace?

The most replaceable layer is the agent’s runtime interface translation: scan the DOM, infer the purpose of controls, decide the click order, then infer success from a layout change. When a cooperating site declares a capability as a tool, that entire section can shrink to one structured call.

The less replaceable pieces are the browser session, authentication state, real UI verification, cross-browser compatibility, and every site that does not expose WebMCP. In other words, WebMCP may cause an agent to use fewer Playwright actions; it does not make Playwright useless.

I did not run a benchmark claiming that tasks become a certain number of times faster. A model still chooses the WebMCP tool, and Chrome’s own documentation treats evals as necessary work: did the agent choose the right tool, supply the right arguments, and accept an appropriate result? Replacing a click with a tool call does not remove probabilistic behavior.

The practical architecture uses both

For my own product, I would not create a separate set of business rules for WebMCP. I would first collapse the real action into one domain function, then let both the UI and WebMCP tool call it:

const createTicket = (input: TicketInput) =>
    supportService.create(input);

form.addEventListener('submit', async (event) => {
    event.preventDefault();
    await createTicket(readTicketForm(form));
});

document.modelContext.registerTool({
    name: 'create_support_ticket',
    description: 'Create a support ticket',
    inputSchema: ticketSchema,
    execute: createTicket,
});

Then I would test two things with Playwright: a person can complete the visible flow, and the page registers the tool in the correct state, with the call reaching the same authorization, validation, and data-writing code. WebMCP becomes another entrance to a product capability, not a shortcut around UI testing.

The agent can follow a pragmatic order: prefer a tool the site exposes; if no suitable tool exists, fall back to semantic locators such as roles, labels, and test ids; only then use broad DOM exploration. That is how guessing gets pushed back one layer at a time.

A clearer tool does not remove the security problem

A site exposing a tool does not automatically grant the agent more authority. Authentication, authorization, input validation, CSRF protection, rate limits, and confirmation for important actions must still be enforced by the site. A tool description tells the model what something does; it is not a security boundary.

The WebMCP specification includes annotations such as readOnlyHint and untrustedContentHint so an agent can learn that a tool is read-only or returns untrusted content. They are hints, not enforcement. The official security guidance also calls out tool-description poisoning, output prompt injection, and overexposed tools.

The safer pattern is to keep each tool single-purpose, avoid overlapping names, register it only in relevant page states, use same-origin exposure by default, and retain explicit human confirmation for payments, deletion, or data submission. More tools are not always better: they consume agent context and create more opportunities to choose the wrong one.

Should you build WebMCP today?

As of August 2026, WebMCP is a Draft Community Group Report from the W3C Web Machine Learning Community Group. It is not a W3C Standard and is not on the Standards Track. Chrome offers an origin trial beginning with version 149; the API, behavior, and support surface may still change.

I would therefore treat it as a promising new entrance worth a small prototype, not as a universal standard that justifies deleting existing automation. The best early candidates are frequent, multi-step, parameterized actions on your own site—creating a ticket, searching inventory, or completing a booking. Reading an article or following one link may not justify another tool.

For third-party sites, automated regression, cross-browser verification, or any flow that must prove “a person can really complete this,” Playwright remains the better tool. WebMCP explains a website’s capabilities to an agent. Playwright verifies what actually happens in the browser.

I would not delete a single Playwright test today. If I add the first WebMCP tool to one of my products, the next thing I write will still be a Playwright test.