WebMCP: When AI Agents Start Using Your Website by Talking to It - Not Clicking

It started with a completely routine task. I was running a client's site through PageSpeed Insights - something I probably do dozens of times a week. I was scrolling through the report when a line stopped me cold: agentic browsing.

My first instinct was that it was a typo. My second was "did they add another metric?" But I clicked it anyway. That click took me to Chrome's developer documentation and a page called WebMCP. And what I read there was quietly one of the most significant shifts I've seen in web technology in years.

At Detartech, our work is about visibility - getting websites found in classic search engines (SEO) and increasingly in AI-powered ones (GEO). So the question "how do machines read your site" isn't an academic curiosity for me; it's the core of the business. After reading about WebMCP, I realized that question is evolving. The new question isn't just "how will machines read your site." It's: how will machines use it?

Let me take it from the top. Once this clicks, you see the web differently.

The web's three eras: humans click, bots crawl, agents act

You can slice web history into three broad phases.

The first era was the human era. You opened a site, you read it, you clicked, you added things to carts. The only customer for any design decision was a person. Buttons existed for fingers; text existed for eyes.

The second era belonged to bots. Googlebot arrived, crawled your pages, indexed them, ranked them. The entire discipline we call SEO was born here. We wrote robots.txt files, generated sitemaps, added schema.org markup - all so that bots could understand the page. But they were only reading. They weren't doing anything. Just understanding, then listing.

The third era is knocking on the door: the era of agents. AI agents no longer settle for reading your page - they complete tasks on your behalf. They search for flights, fill out forms, book appointments, process purchases. They imitate the tap-and-type dance that humans perform.

Chrome's documentation gives this a precise name: actuation - an agent simulating mouse clicks and keyboard input as if it were a human user. It can be a single action like clicking a link, or a complex chain of steps like completing a multi-step checkout from scratch.

Sounds great, right? The problem is that this approach is profoundly fragile. And that's exactly where the story gets interesting.

The core problem: agents walk through your site blind

Think about how an AI agent navigates your site today when you've given it no roadmap. It sees the screen, guesses that "this button probably means Add to Cart," clicks it, interprets the result, then guesses the next step.

Every step is an inference. Every inference is a gamble.

You make a small design change - you move a button, rename "Add to Cart" to "Buy Now," add a confirmation step - and the agent's entire script collapses. A human user adapts to those changes in a second. The machine, in the middle of a long inference chain, simply loses the thread.

I think of it like hosting a guest who's never visited before. The old approach is like letting them wander your apartment with no map: "the kitchen is probably that way." Most of the time they find it. But sometimes they walk into the bathroom thinking it's the pantry.

WebMCP exists to end this blind walk.

What is WebMCP?

WebMCP is a proposed web standard that lets websites declare structured tools that AI agents can call directly. The logic is elegant: instead of waiting for an agent to guess what your button does, your site explicitly announces "this feature is called checkout, it takes these inputs, and here's what it returns."

The agent stops staring at the UI trying to infer purpose. The site tells it directly. Guessing is replaced by a contract.

According to Chrome's documentation, WebMCP enables three things:

• Discovery: A standard way for a page to register its capabilities with agents - tools like checkout, filter_results, book_appointment.
• JSON Schemas: Explicit definitions of what each tool takes as input and returns as output. This directly reduces hallucination and misinterpretation, because the model knows exactly what's expected.
• State: A shared understanding of the current page context, so the agent knows in real time what resources are available to act on.

Here's a bridge for those of us who come from an SEO background: when we add structured data via schema.org, we're essentially labeling the page - "this is a product, this is its price, this is the review." WebMCP is the next level of that same idea. Instead of marking things up so machines can understand them, you mark them up so machines can act on them. "Read" becomes "do." The gap between those two words is enormous.

One detail I found genuinely satisfying: WebMCP tools execute visibly on your page. When an agent calls a tool, the action happens inside your interface, in front of the user. Your brand, your design, the human-first experience you built - all of it stays intact. The agent is a guest on your platform, not the other way around.

The code: two ways to implement WebMCP

There are two APIs, and seeing the actual code is where things really land.

1. Imperative API - defining tools in JavaScript

You define tools using standard JavaScript: a name, a description, and an input schema. Since I run an appointment platform (sanalrandevu.com), I'll use a booking tool as the example:

document.modelContext.registerTool({
  name: 'book_appointment',
  description: 'Books an appointment for the selected service, date, and customer name.',
  inputSchema: {
    type: 'object',
    properties: {
      service:    { type: 'string', enum: ['haircut', 'shave', 'coloring'] },
      date:       { type: 'string', description: 'Appointment date in YYYY-MM-DD format' },
      customerName: { type: 'string' }
    },
    required: ['service', 'date', 'customerName']
  },
  execute: async ({ service, date, customerName }) => {
    const result = await saveAppointment({ service, date, customerName });
    return `Appointment booked: ${customerName} - ${service} - ${date}`;
  }
});

What's happening here: registerTool gives the tool an identity. The description tells the agent what this capability is for. The inputSchema specifies exactly what inputs are required and their allowed values (notice service only accepts specific strings). The execute function defines what actually happens when the tool is called. When an agent receives a task like "book a haircut for this person tomorrow," it doesn't hunt for buttons - it calls this contract directly.

One important note: navigator.modelContext is deprecated as of Chrome 150. The correct interface is now document.modelContext. If you're just getting started, enter through the right door from day one.

2. Declarative API - turning an HTML form into a tool

This is the part that made my SEO brain light up. No JavaScript needed - you just add a few attributes to an existing HTML form, and it becomes a callable agent tool:

<form toolname="sendContactRequest"
      tooldescription="Submits the visitor's contact form."
      action="/contact">

  <label for="name">Full Name</label>
  <input type="text" name="name">

  <label for="email">Email</label>
  <input type="email" name="email">

  <label for="message">Message</label>
  <textarea name="message"></textarea>

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

Once you add toolname and tooldescription, the browser interprets this form as a structured tool. The form fields become the tool's parameters. When an agent calls the tool, the browser brings the form into focus and populates the fields - and the form stays visible to the user. You can add toolautosubmit to automate the final step, or leave the user in control of confirming.

The parallel to structured data is hard to miss. With schema.org, you annotate a page to say "this is a product." With Declarative WebMCP, you annotate a form to say "this is a tool that submits a contact request - here's what it takes." Same muscle, new exercise. For anyone who's spent years helping machines understand web content, this transition isn't a stretch at all.

"Will WebMCP replace MCP?" - No, and this is an important misconception

The Chrome team addressed this directly because it's apparently the first thing developers ask. MCP (Model Context Protocol) and WebMCP are not competing technologies. They serve different layers.

The analogy I liked most from the documentation: think of the difference between a company's customer service call center and a specialist in-store advisor.

• MCP is the backend. Available on any platform, at any time. It handles core data retrieval and business logic. It lives server-side and is always on - like a call center you can reach from anywhere.
• WebMCP is the frontend. It only exists while a user has your site open in a browser tab. It has access to live session data, cookies, and DOM elements - things that only exist in a real browser context. Like the in-store expert: only available while you're in the building.

Here's the comparison that helps me keep these straight:

The ephemeral nature of WebMCP tools is an important design decision: tools only exist when your page is open. The moment a user closes the tab, the agent can't touch your site. Control stays with you and the user - which is exactly the right approach from a security and trust perspective.

The mental model: MCP carries the brain and data, available everywhere, all the time; WebMCP handles the moment when a user is actually on your site and needs an agent to do something precise and fast. The strongest agentic experiences will use both.

What this means for SEO and GEO

Here's what I actually walked away thinking about. Because this isn't just interesting - it's commercially relevant to anyone whose job involves search visibility.

Traditional SEO had one goal: rank. Get to the top of a keyword, earn the click. Then GEO emerged - Generative Engine Optimization - which is about creating content so that AI engines like ChatGPT, Perplexity, and Google's AI Overviews cite you as a source when they generate answers. SEO says "list me"; GEO says "understand me and quote me."

WebMCP is the layer above both: "use me."

Think of it as a ladder:

1. SEO - Machines find you and rank you.
2. GEO - Machines understand you and cite you.
3. Agent-readiness (WebMCP) - Machines complete tasks on your site.

Here's what I believe is coming: people will increasingly delegate tasks to agents. "Book me a table for two at a seafood place within 5km, for tomorrow evening." Then they'll lean back. Which site does the agent use? The one it can navigate reliably. The one with clear, well-labeled forms. The one that declares its tools explicitly. The one that doesn't require the agent to guess at every step.

Remember mobile optimization? There was a moment when "my site looks fine on desktop, that's enough" was a real position. Then Google made mobile usability a ranking signal and those sites disappeared overnight. Agent-readiness feels like a similar inflection point to me - experimental today, but the kind of "experimental" that means "the train is about to leave."

At Detartech, this is exactly why we treat SEO and GEO as parts of the same future, not separate disciplines. Because however machines relate to your website - whether they find it, understand it, or can act on it - that's where your visibility is heading.

A concrete scenario

Let's make this tangible. Say you run a restaurant, a booking service, or an e-commerce store.

A user tells their assistant: "Find me a window table for two at a nice place downtown, Saturday evening, and book it." The agent gets to work. If the restaurant's site has a well-defined book_table tool - with date, party size, and seating preference as clear parameters - the agent books it in seconds, with no errors. If it doesn't, the agent stumbles around guessing which field does what, possibly books the wrong date, possibly gives up and moves to the next result.

In the second scenario, you lose the customer. And you never see it happen, because the visitor wasn't a person - it was an agent, and it left silently.

Appointments, reservations, orders, support requests - these are the bread and butter of most small business websites. This isn't a Silicon Valley thought experiment. It's directly relevant to your contact form, your cart, your booking calendar.

Being honest about the limitations

If you've read this far, you know I'm not writing hype. So here's the other side, because anyone who doesn't mention it is selling something.

This is still early-stage. WebMCP is currently available as an origin trial starting in Chrome 149. The standard isn't finalized and may change. For local testing, enable the chrome://flags/#enable-webmcp-testing flag - but don't treat this as production infrastructure yet.

A visible browser tab is required. Because tool calls are handled in JavaScript, there must be an open browser tab with a live interface. Headless agent calls are not supported. Background, server-side operations are what MCP is for.

Complex interfaces require more work. If your site has a deeply nested, stateful UI, exposing that state cleanly to agents may require meaningful refactoring - not just a few HTML attributes.

Discovery has limits. Right now, a client or browser has to actually visit your site to know that callable tools exist there. There's no central registry an agent can query from the outside.

I mention these not to discourage, but because the timing of when you adopt something matters as much as whether you adopt it.

What I'm doing, and what I'd suggest

After finishing this research, here's how I'm thinking about it for my own products:

I'll audit the critical flows in my apps from an agent's perspective - contact forms, booking flows, checkout steps - and ask whether a machine could complete them reliably without guessing. Then I'll start thinking in terms of "tools": what are the meaningful actions on this site, and can I declare them in a way an agent would understand without ambiguity? The Declarative API seems like the lowest-friction entry point - you're mostly adding attributes to HTML you already have.

For you: you don't need to rebuild anything today. But three things are worth doing now. First, build your HTML forms with clean, semantic name and label structure - this serves accessibility, SEO, and agent-readiness simultaneously. Second, start thinking about your key site actions as callable tools rather than visual interfaces. Third, keep one eye on this standard as it develops. It's moving fast.

This whole story started with one line in a performance report. Sometimes the door to what's coming is hiding in the most routine part of your day - you just have to be curious enough to walk through it.

The web is changing again. And this time, what's changing isn't how machines read your pages. It's how they use them.

Frequently Asked Questions

What is WebMCP?
WebMCP is a proposed browser standard that lets websites declare structured tools for AI agents to call directly. Instead of an agent guessing the purpose of UI elements, the site explicitly announces its capabilities - what each tool does, what inputs it accepts, and what it returns. This makes agent interactions dramatically more reliable and less prone to error.

What is the difference between WebMCP and MCP?
MCP (Model Context Protocol) lives on the backend - it's server-side, persistent, and accessible from any platform at any time. WebMCP lives on the frontend - it's browser-bound, ephemeral, and only active while a user has your site open. They address different layers and are designed to be used together, not instead of each other.

What is agentic browsing?
Agentic browsing refers to an AI agent navigating websites and completing tasks on behalf of a user - filling out forms, making bookings, processing purchases. The agent either simulates human interactions (actuation) or, with standards like WebMCP, calls explicitly declared tools to accomplish these tasks more reliably.

How does WebMCP affect SEO and GEO?
SEO gets machines to rank you; GEO gets AI engines to cite you. WebMCP adds a third layer - getting agents to use your site to complete tasks. As AI agents become more involved in how people interact with the web, sites with clear, agent-readable tools will have a structural advantage in both visibility and conversion.

How do I try WebMCP?
WebMCP is available as an origin trial in Chrome 149 and later. For local testing, enable the chrome://flags/#enable-webmcp-testing flag and relaunch Chrome. You can define tools using JavaScript (Imperative API) or by adding attributes directly to HTML forms (Declarative API) - no JavaScript required for the latter.

Will WebMCP replace MCP?
No - this is a common misunderstanding. WebMCP is not an extension or replacement for MCP; they serve fundamentally different purposes. MCP handles persistent, platform-agnostic backend logic; WebMCP handles real-time, browser-integrated frontend interactions. The strongest agent experiences use both together.