AI agents are getting better at using websites, but they are still forced to interpret interfaces built for humans. WebMCP proposes something different: let the website tell the agent exactly what it can do.

Imagine asking your browser:

Find out whether Bernado offers Laravel development and book a consultation for Friday afternoon.

Today, an AI agent might have to open the website, inspect the navigation, find the services page, understand which service matches Laravel development, locate the booking form, figure out every field, fill it in, and finally submit it.

That is impressive, but also strangely inefficient.

The agent is essentially pretending to be a human.

WebMCP proposes a different model.

Instead of forcing an agent to understand every button, form and menu, a website can expose structured actions such as:

get_services()
check_availability()
book_consultation()

The agent no longer has to guess what the website can do.

The website tells it.

And that small change could have a major impact on how we build the web.


What exactly is WebMCP?

WebMCP, or Web Model Context Protocol, is a proposed browser standard for exposing parts of a web application's functionality as structured tools that AI agents can discover and call.

Chrome describes three important pieces of the model:

  1. Discovery: pages can tell agents which tools are available.
  2. Structured schemas: tools clearly define what input they expect.
  3. State: tools can operate within the context of the page the user currently has open.

Instead of an agent encountering:

<button>Continue</button>

and trying to determine what "Continue" means, the application could expose something much more explicit:

book_consultation({
service: "Laravel Development",
date: "2026-08-14",
time: "14:00"
})

The difference is subtle but important.

One approach asks AI to interpret an interface.

The other gives AI a defined capability.


WebMCP is not the same thing as MCP

The name can create some confusion.

The broader Model Context Protocol, MCP, is an open standard for connecting AI applications with external tools, data sources and workflows. An MCP server might let an agent query a database, use GitHub, inspect files or call another service.

WebMCP is related philosophically, but Chrome explicitly describes it as MCP-inspired rather than a direct implementation of MCP in JavaScript. It is designed specifically for interactions happening inside a browser and an active webpage.

A useful simplification is:

MCP
AI ↔ external services and backend capabilities

WebMCP
AI ↔ the website currently open in your browser

They are not competitors.

A sophisticated application could eventually use both.


Why do AI agents need this?

Modern websites can be surprisingly difficult for machines.

Consider a booking interface containing:

  1. a calendar widget
  2. several service categories
  3. a location selector
  4. a custom time picker
  5. a multi-step form
  6. a confirmation modal

A human sees the visual hierarchy and understands what to do.

An AI agent has to reconstruct that meaning from the page.

It might inspect the DOM, analyze accessibility information or use visual understanding to decide which element to interact with.

Every additional step creates another opportunity for misunderstanding.

WebMCP changes the relationship.

Instead of:

User
↓
AI agent
↓
Inspect page
↓
Find button
↓
Click
↓
Interpret result
↓
Find form
↓
Fill fields
↓
Submit

you could have:

User
↓
AI agent
↓
Discover available tools
↓
book_consultation(...)
↓
Website executes the action

Chrome's motivation for WebMCP is largely about making these interactions more reliable by replacing repeated interface interpretation with explicit application-defined tools.

That is what makes WebMCP interesting.

It is not primarily about making AI smarter.

It is about making websites less ambiguous to AI.


How a website exposes a tool

WebMCP currently proposes two approaches: Declarative and Imperative APIs.

The declarative approach

For existing HTML forms, developers can annotate the form itself.

A booking form could eventually look roughly like this:


<form
toolname="book_consultation"
tooldescription="Book a consultation for a selected service and date">

<label>
Service
<select name="service">
<option>Laravel Development</option>
<option>Web Design</option>
</select>
</label>

<label>
Date
<input type="date" name="date">
</label>

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

To a human, it remains a normal form.

But the browser can also describe it to an agent as a structured tool.

Chrome's current Declarative API uses attributes such as toolname and tooldescription, while the form fields become tool parameters.

That is an appealing idea because developers do not have to create a completely separate experience for agents.

The human interface remains intact.


The Imperative API is where things get more powerful

Not every useful action corresponds to a form.

Suppose a site needs to expose consultation availability.

A developer could register a JavaScript tool:


await document.modelContext.registerTool({
name: "check_consultation_availability",

description:
"Check available consultation times for a given date.",

inputSchema: {
type: "object",
properties: {
date: {
type: "string"
}
},
required: ["date"]
},

execute: async ({ date }) => {
const response = await fetch(
`/api/consultations/availability?date=${date}`
);

return await response.json();
}
});

An agent can now understand three things without reverse-engineering the interface:

What the tool does

check_consultation_availability

What it requires

date

What happens when it executes

Your existing application logic runs.

Chrome's current Imperative API uses document.modelContext.registerTool() with a tool name, description, input schema and execution handler.

One detail worth watching if you experiment with WebMCP: older examples may use navigator.modelContext. Chrome now marks that interface as deprecated in Chrome 150 and directs developers to document.modelContext instead.

That alone tells us something important.

This technology is still moving quickly.


What this could look like on a real website

Consider a professional services website.

Instead of trying to expose every page element to an AI agent, I might expose only a few meaningful operations:

get_services()

Returns the services I offer.

get_service_details()

Returns information about a particular service.

check_consultation_availability()

Checks when a consultation can be scheduled.

request_consultation()

Starts or completes a consultation request.

Now the user could simply say:

“Does Bernardo build Laravel applications? If yes, see whether he's available Friday afternoon.”

An agent might first call:

get_services()

Then:

check_consultation_availability({
service: "Laravel Development",
date: "2026-08-14",
period: "afternoon"
})

The website's visual design does not disappear.

Humans can still browse projects, compare services, read articles and use the normal booking interface.

WebMCP simply creates another doorway into the application.


WebMCP does not replace your API

This is an important distinction.

If I were implementing WebMCP in a Laravel application, I would not move my business logic into WebMCP.

My architecture might still be:

AI Agent
↓
WebMCP Tool
↓
Frontend JavaScript
↓
Laravel API
↓
Service / Controller
↓
Database


Laravel would continue handling things such as:

  1. validation
  2. authentication
  3. authorization
  4. database operations
  5. rate limiting
  6. notifications
  7. booking rules

WebMCP becomes another interface to that functionality.

Your API remains the engine.

WebMCP is closer to giving an agent a clearly labeled steering wheel instead of asking it to figure out which dashboard button controls the car.

Chrome similarly positions MCP and WebMCP as technologies serving different layers rather than replacements for each other.


The most important question: what should an agent be allowed to do?

Making a website easier for agents to operate also creates new security questions.

There is a major difference between:

search_products()

and:

purchase_product()

The first reads information.

The second changes something in the real world.

The difference becomes even more serious with actions such as:

delete_account()
transfer_money()
cancel_booking()
change_password()

WebMCP does not remove the need for authentication, authorization or confirmation.

Chrome's WebMCP security guidance specifically discusses risks such as malicious tool definitions, contaminated tool outputs and prompt injection. WebMCP tools are also constrained by origin and permissions mechanisms in the browser.

For developers, I think a good principle is:

An AI agent should never gain more authority through WebMCP than the user already has through the application.

And for consequential actions, being technically authorized may still not be enough.

A purchase or money transfer may deserve an explicit human confirmation before execution.

WebMCP's current design supports human-in-the-loop workflows and allows sensitive actions to request user interaction.


A new kind of developer experience: designing for agents

We have spent decades thinking about UX, the user experience.

If agents become regular visitors to websites, developers may eventually need to think about something adjacent:

Agent Experience

Not because agents need attractive interfaces.

They need clarity.

A good WebMCP tool should make questions such as these easy to answer:

  1. What exactly does this tool do?
  2. When should it be used?
  3. What parameters does it accept?
  4. Does it read information or change something?
  5. What happens if the request fails?
  6. Is another tool more appropriate?

Chrome's current best-practice guidance already recommends clear, action-oriented names, precise descriptions, focused tools and schemas that minimize unnecessary interpretation by the model.

Consider:

process()

versus:

check_order_status()

One forces the model to guess.

The other communicates intent immediately.

Good API design suddenly has a new audience.


Is WebMCP ready for production?

Not universally.

As of August 2026, WebMCP remains an experimental technology. Chrome provides an origin trial beginning with Chrome 149 and a flag for local development, and its documentation explicitly notes that the API remains under active discussion and may change.

There are also current limitations.

WebMCP is primarily aimed at browser workflows with a human present. Tool discovery currently depends on visiting the site, and complex applications may require additional work to expose their state cleanly to agents.

So I would not rebuild a critical production architecture around WebMCP today.

But I would experiment with it.

A small tool such as:

get_services()

or:

check_availability()

is enough to understand what this new interaction model feels like without making the rest of the application dependent on an experimental API.


The web may be getting a second interface

The web has always evolved around new ways of interacting with information.

First, websites gave humans pages to browse.

APIs gave software structured ways to communicate with services.

AI agents introduce another possibility:

websites that explicitly describe what an intelligent agent can do inside them.

That does not mean buttons, menus or websites disappear.

Humans still want to explore.

We want to look at photographs, compare options, read stories, inspect details and make decisions ourselves.

But sometimes we simply want something done.

“Reschedule my appointment for Friday.”
“Find the order I placed last month.”
“See whether this developer offers Laravel development and request a consultation.”

For those tasks, forcing an AI agent to repeatedly inspect pixels and click its way through an interface may eventually feel strangely primitive.

WebMCP offers another model:

Human interface
+
Agent interface
↓
Same application

It is still early.

Its APIs will evolve, browser support will determine how useful it becomes, and security will need to remain central to the design.

But the idea behind it is difficult to ignore.

The next generation of websites may not only need to be readable, responsive and accessible.

They may also need to be agent-ready.