For years, automating a web page meant one of two things.

The first was using an API created specifically for machines.

The second was pretending to be a human.

A bot opened the browser, looked for a button, clicked it, typed into a field, waited for a response, and inspected the screen again.

Modern AI agents pushed that second strategy much further through multimodal models, accessibility trees, DOM, Playwright, Chrome DevTools Protocol, and computer use systems.

But the underlying problem remains the same:

most of the web was designed so a human can interpret an interface, not so an agent can discover capabilities in a structured way.

WebMCP tries to change that.

The proposal introduces a browser API through which a page can explicitly declare which operations it offers an agent, which arguments they expect, and which code should run when the agent decides to use one of those capabilities.

Instead of forcing the agent to infer that a blue rectangle means “search orders,” the application could publish a tool called get_order_status.

Instead of visually locating a form, filling five fields, and pressing Submit, the agent could discover a structured operation such as createSupportRequest.

The idea looks small, but it changes the architecture of web automation.

From a human interface to an interface for agents too

A traditional web page primarily exposes a visual interface:

User
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
Buttons, forms, menus, and content

An agent that wants to operate that page has to reconstruct the interface’s intent.

It can do so through vision:

Agent
   ↓
screenshot
   ↓
multimodal model
   ↓
"that looks like the Search button"
   ↓
click

Or through a more structured representation:

Agent
   ↓
DOM / accessibility tree
   ↓
locate element
   ↓
Playwright / CDP
   ↓
click / type / submit

WebMCP adds a third possibility:

Agent
   ↓
discovers tools
   ↓
search_products(...)
add_to_cart(...)
checkout(...)
   ↓
the page itself executes its logic

The application stops being only a collection of visual controls and starts to have a semantic surface for agents.

That is WebMCP’s core thesis.

document.modelContext: the central piece

The WebMCP proposal is incubating in the Web Machine Learning ecosystem and already has experimental implementations in Chromium browsers.

One of its most important interfaces appears under document.modelContext.

Conceptually, a page could register a tool like this:

await document.modelContext.registerTool({
  name: "get_order_status",
  description: "Search orders within a specified period",
  inputSchema: {
    type: "object",
    properties: {
      timeframe: {
        type: "string",
        enum: ["today", "yesterday", "last_7_days"]
      }
    },
    required: ["timeframe"]
  },
  execute: async ({ timeframe }) => {
    return await getOrders(timeframe);
  }
});

The page is declaring three important things:

  1. which capability exists;
  2. which parameters it accepts;
  3. which function should execute.

The agent no longer needs to infer those three things by looking at the screen.

It can work with a representation similar to what models already use for tool calling.

This is especially interesting because the code that actually resolves the action can remain the same JavaScript the application already uses.

There is no need to duplicate the entire business logic in a separate service solely for agents.

Two paths: imperative and declarative APIs

WebMCP explores two main ways to publish capabilities.

1. Imperative API

The first is registering tools from JavaScript.

It is ideal when an application already has clearly defined internal operations.

For example:

registerTool({
  name: "search_flights",
  inputSchema: { ... },
  execute: async (args) => searchFlights(args)
});

The developer explicitly controls the name, description, schema, and execution function.

2. Declarative API

The second idea is even more unusual.

An HTML form can be described so the browser turns it into a capability usable by agents.

A simplified version might look like this:

<form
  toolname="createSupportRequest"
  tooldescription="Send a support request">

  <input name="email" type="email">
  <textarea name="problem"></textarea>

  <button type="submit">Send</button>
</form>

The agent does not need to discover each field separately.

It can reason about something much closer to:

createSupportRequest({
  email: "user@example.com",
  problem: "I cannot access my account"
})

The visual interface still exists, but now it also has an explicit representation for machines.

That creates an important property: humans and agents can interact with the same application without forcing the developer to build two entirely separate products.

WebMCP is not simply “MCP inside the browser”

The name can be confusing.

Model Context Protocol, or MCP, defines a general architecture for connecting models and agents with tools, resources, and other context sources.

In simplified form:

LLM / Agent
     ↓
MCP Host
     ↓
MCP Client
     ↓
JSON-RPC
     ↓
MCP Server
     ↓
API / filesystem / database / service

An MCP server can publish tools and resources without depending on one specific web page.

WebMCP attacks another layer of the problem:

LLM / Agent
     ↓
Browser Agent
     ↓
Browser
     ↓
document.modelContext
     ↓
Web Application

The difference is not cosmetic.

MCP is an integration protocol between components.

WebMCP is a Web API inside the page context.

That means the page can directly reuse:

  • its JavaScript;
  • its current state;
  • the user’s session;
  • cookies and credentials already managed by the browser;
  • the visible interface;
  • the current navigation flow.

Chrome explains that WebMCP and MCP are complementary technologies, not direct substitutes.

A company could run an MCP server for backend integrations while also exposing WebMCP from its web application for operations tied to session and UI state.

The big advantage: reuse the existing session and state

This may be one of the strongest arguments for the model.

Suppose a user is already signed into an application.

The browser already maintains:

identity
cookies
session
navigation state
permissions
preferences
page context

If we build an external MCP integration, we may need to solve part of that authentication again through OAuth, tokens, APIs, or dedicated credentials.

With WebMCP, the tool lives inside the same application context.

We can imagine it like this:

Authenticated user
       ↓
Web application
       ↓
WebMCP tools
       ↓
Authorized agent

The capability does not need to reconstruct user identity from scratch.

For complex applications, that can eliminate a considerable amount of duplicated infrastructure.

Why it can be better than computer use

Computer use systems are impressive because they can operate applications that were never designed for agents.

That is precisely their greatest strength.

But it is also their main limitation.

Imagine an agent wants to book a hotel.

With visual automation it might need to:

1. locate destination
2. click
3. type Miami
4. locate dates
5. choose check-in
6. choose check-out
7. find Search button
8. click
9. wait for navigation
10. interpret results
11. locate filters
12. apply filters
13. select hotel

Every step adds a possible failure point.

A redesign can break the automation.

A popup can block a button.

A translation can change text.

An animation can delay an element.

With a WebMCP surface, part of the flow could become:

search_hotels({
  destination: "Miami",
  check_in: "2026-09-10",
  check_out: "2026-09-13"
})

Then:

filter_results({
  max_price: 250,
  min_rating: 4
})

And finally:

start_booking({ hotel_id: "..." })

That does not mean the interface disappears.

It means the agent no longer depends on it to understand operations the application itself already understands perfectly.

Tools that appear and disappear with state

Cloudflare has experimented with WebMCP inside Browser Run and demonstrates a particularly interesting property: the set of tools can change dynamically according to page state.

That fits much better with how real applications work.

For example:

Home page
   ↓
search_products(...)

After searching:

Results
   ↓
filter_products(...)
compare_products(...)
open_product(...)

After selecting a product:

Detail
   ↓
add_to_cart(...)
select_variant(...)

And inside the cart:

Cart
   ↓
checkout(...)
apply_coupon(...)

The agent interface can evolve alongside the application flow.

That lets the page expose only operations that are valid at each moment.

For an agent, it reduces the space of possible actions and therefore part of the uncertainty in reasoning.

WebMCP does not eliminate Playwright, DOM, or vision

It would be a mistake to interpret WebMCP as the end of traditional browser automation.

The web will not migrate overnight.

For a long time there will be pages without WebMCP support.

Even on a compatible page, some actions may not be published as tools.

A robust web-agent architecture will therefore probably use several layers:

Agent
   ↓
Does a WebMCP tool exist?
   ├── yes → use structured tool
   │
   └── no
        ↓
     DOM / accessibility
        ↓
     Playwright / CDP
        ↓
     vision / computer use as fallback

That hierarchy makes sense.

Use the most deterministic abstraction first and fall back to more heuristic techniques only when necessary.

In other words:

WebMCP can become the fast path; browser automation remains the universal path.

The hard part: security

None of this would be especially important if tools could only query harmless information.

The problem begins when a page exposes operations such as:

send_message
purchase_item
transfer_money
delete_repository
cancel_subscription
submit_application

Now the agent is operating inside an authenticated session and may execute actions with real consequences.

That introduces several risk vectors.

Malicious descriptions

A tool’s names, descriptions, and schemas are part of the context the agent receives.

A hostile page could try to inject instructions designed to manipulate the model.

Contaminated outputs

Even a legitimate tool can return content controlled by third parties.

A comment, review, message, or document could contain prompt injection instructions aimed at the agent.

Authority confusion

The fact that a tool exists does not mean the user has authorized every possible execution.

An agent may discover delete_account, but that should not automatically grant permission to use it.

Irreversible actions

A purchase or transfer should not depend only on the model having interpreted a conversation correctly.

That is why WebMCP designs place so much emphasis on origin restrictions, controlled tool exposure, and human-in-the-loop mechanisms.

Human-in-the-loop as part of the architecture

A useful property is that a tool does not necessarily need to silently complete the whole operation.

It can prepare an action and stop before the irreversible point.

For example:

Agent
   ↓
prepare_booking(...)
   ↓
the page shows a summary
   ↓
user confirms
   ↓
complete_booking(...)

This combination can be much more reasonable than the two traditional extremes:

100% manual

versus

100% autonomous

For sensitive operations, the agent can handle the mechanical work and leave the final gate to the user.

It is a pattern we will probably see repeatedly in serious agentic systems.

Origin restrictions

Web pages have spent decades developing an origin-based security model.

WebMCP tries to build on that infrastructure instead of inventing an entirely separate universe.

Design considerations include restrictions for top-level documents, same-origin iframes, and explicit exposure for cross-origin contexts.

That matters because an arbitrary iframe should not automatically receive access to all of a page’s agentic capabilities.

The security question expands from:

Can JavaScript execute this operation?

To something broader:

Which agent can discover this tool, who can invoke it, and what confirmation is required before it produces real effects?

It is not a consolidated standard yet

This is where enthusiasm needs to be tempered.

WebMCP is still an experimental technology.

In August 2026 there are implementations and experiments in Chromium, including work in Chrome and Edge, but it is not a universal API supported interoperably by every browser.

WebKit has raised objections through its standards process, and Mozilla has also evaluated the proposal.

That means several things can still change:

  • API names;
  • permission models;
  • tool lifecycle details;
  • security mechanisms;
  • agent integration;
  • the final scope of the specification.

For developers, WebMCP should currently be treated as a technology for experimentation and learning, not as a dependency we can assume exists across the entire web.

A possible evolution of web automation

We can roughly arrange web agents into three generations.

First generation: computer use

LLM
 ↓
screenshot
 ↓
vision
 ↓
mouse / keyboard

Very general, but relatively fragile.

Second generation: structured browser automation

LLM
 ↓
DOM / accessibility tree
 ↓
Playwright / CDP

More deterministic, but still requires interpreting structure built for humans.

Third generation: agent-native web

LLM
 ↓
discover_tools()
 ↓
search()
checkout()
create_issue()
send_message()

Here the application explicitly recognizes that it may have agentic consumers in addition to human users.

WebMCP tries to build that third layer directly into the web platform.

The interesting part is not eliminating the interface, but adding another one

For years people have argued that AI assistants could make traditional applications disappear.

WebMCP suggests a different evolution.

The human interface can remain:

HTML
CSS
forms
buttons
visualizations

But next to it appears a semantic interface:

tools
schemas
actions
state
confirmations

We can think of a future application with two complementary surfaces:

                Web application
                     │
          ┌──────────┴──────────┐
          │                     │
      Human UI             Agent API
          │                     │
 HTML / CSS / UX        WebMCP tools

Both operate on the same business logic.

That can be much more efficient than maintaining a website, a public API, a special integration for every assistant, and several independent automation layers.

MCP + WebMCP + browser automation

The most interesting architecture will probably not choose just one technology.

It will combine them.

A modern agent could work like this:

                        Agent
                          │
             ┌────────────┼────────────┐
             │            │            │
            MCP        WebMCP      Browser Use
             │            │            │
        backend APIs   live page    UI fallback
             │            │            │
             └────────────┴────────────┘
                          │
                    digital world

MCP can provide stable access to backend services and data.

WebMCP can provide operations tied to the current page’s session and state.

Playwright, DOM, and computer use can cover everything that does not expose an explicit agent interface.

Instead of competing, these layers can form a hierarchy of tools.

The idea is similar to what happens in agent harnesses: the better the infrastructure around the model, the less work the LLM has to solve through fragile reasoning. At Capital de Tokens we have already analyzed this shift in Codex as a platform and agent harness and DeepSeek Harness.

WebMCP takes that same logic into the browser.

The web starts assuming agents are users too

That may be the most important interpretation.

For decades, the web optimized its platform around humans navigating pages.

Agents arrived later and started operating on top of that infrastructure through vision, scraping, DOM, and automation.

WebMCP reverses the relationship.

The application can begin to state explicitly:

These are my capabilities.
These are their parameters.
This is the valid state.
This is the function you should execute.
And here you need human confirmation.

If that model achieves enough adoption, web automation can stop looking like a robot moving a mouse and start looking much more like an operating system of services discoverable by agents.

We are still far from the whole web working this way.

But the direction matters.

WebMCP is not trying to teach the agent to look at a page better. It is trying to let the page itself speak the language of agents.

And if the web truly becomes agentic, that distinction could become enormous.

Technical sources