Browser Use adds WebMCP, giving agents a shortcut past the DOM

Why it matters

WebMCP gives browser agents direct, typed actions instead of forcing them to decode every interface. Browser Use's adoption could push the proposed API into real automation workloads while keeping a fallback for the rest of the web.

Browser Use said on X on September 6th that it had added native support for WebMCP, giving its browser agents a structured way to invoke actions that websites explicitly expose to software.

https://twitter.com/gregpr07/status/2096664804631142578

The release puts co-founders Gregor Zunic (@gregpr07) and Magnus Muller (@mamagnus00) behind one of the earliest browser-agent frameworks to adopt the proposed interface. WebMCP can replace some of the page inspection, element selection and screen driving that make browser automation expensive and prone to breaking.

The timing follows the publication on September 4th of an updated WebMCP community draft. The specification remains experimental: it is a W3C Community Group report rather than a W3C standard or a document on the standards track.

A structured path through the web

WebMCP allows a web application to register JavaScript functions as tools through document.modelContext. Each tool can include a name, a natural-language description and a structured input schema. An agent can inspect those tools and execute one directly instead of inferring an action from pixels, text labels or the page's document structure.

A commerce site, for example, could expose an add_to_cart tool with a product identifier as its input. A browser agent would call that function rather than search the page for the correct button, decide whether it is clickable and reproduce the interaction through a mouse event.

That distinction addresses a central weakness in browser agents. Websites were designed for people, and their interfaces change constantly. Agents typically compensate by processing screenshots, accessibility trees or simplified representations of the DOM, then choosing where to click or type. Small layout changes, ambiguous controls and dynamic page elements can derail the sequence.

Browser Use already handles those conventional pages through its open-source browser automation framework, which can navigate sites, fill forms, extract information and complete multi-step tasks. Native WebMCP support adds a faster path when a site has published callable tools. Browser Use can continue using ordinary browser controls where WebMCP is unavailable, avoiding a dependency on broad adoption by website operators.

The founders' infrastructure bet

Zunic and Muller built Browser Use after meeting at a hacker house connected to ETH Zurich. Their initial prototype began as a short experiment in whether large language models could operate websites, and the founders released the project as open source in late 2024. Browser Use joined Y Combinator's Winter 2025 batch, and its GitHub repository now displays roughly 99,000 stars.

In March 2025, Browser Use said it raised a $17M seed round led by Felicis, with A Capital, Nexus Venture Partners, Y Combinator, Paul Graham, Liquid 2 Ventures, SV Angel and Pioneer Fund participating. The financing backed a thesis that browser control would become basic infrastructure for agents operating across software that lacks a usable API.

WebMCP changes the shape of that problem. If adoption grows, browser-agent providers will spend less effort reverse-engineering interfaces on participating sites. Website operators gain a defined surface for agent traffic, including control over which actions are exposed and the inputs those actions accept.

Browser Use still has a reason to support both approaches. WebMCP works only when a site implements it, while Browser Use's appeal has rested on operating the existing web without requiring site owners to rewrite their applications. The integration lets Zunic and Muller pursue the emerging standard without abandoning the messy pages that created demand for Browser Use in the first place.

The security boundary moves into the tool

Structured actions remove ambiguity from clicking, but they also give websites a direct channel into an agent's decision process. The WebMCP draft identifies prompt injection in tool descriptions and outputs, misrepresentation of an action's consequences, excessive collection of user data and violations of same-origin boundaries among the protocol's security risks.

Those concerns carry added weight inside authenticated browser sessions. The draft assumes agents may inherit a user's identity, session state and access to sensitive data across websites. A tool that is easy to call can also be easy to call incorrectly unless the browser agent preserves origin information, distinguishes read-only actions from consequential ones and asks for approval before sensitive operations.

Browser Use's support turns WebMCP from a specification for site developers into an action surface available to another widely used automation framework. Its value will depend on how many sites expose useful tools and whether agents can treat those tools as untrusted capabilities rather than authoritative instructions.