What Is WebMCP? The Complete Guide to Web Model Context Protocol (2026)

For thirty years we have built websites for one kind of visitor: a human with eyes, a mouse and a bit of patience. That assumption is quietly breaking. In 2026 a growing share of your "visitors" are AI agents — ChatGPT's agent, Perplexity's Comet, Google's in-browser automation — clicking through your site on a person's behalf to compare, book, buy or fill in a form.

The trouble is that those agents have, until now, had to use your site the way a human does: take a screenshot, squint at it, guess where the button is, and hope the page did not change. It is slow, expensive and brittle. WebMCP is the fix — and it is one of the most important shifts in how the web works since mobile.

This guide is the complete, plain-English version. We will cover what WebMCP actually is, how it differs from the Model Context Protocol you may have heard about, how it works under the bonnet (with real code), who is building it, where browser support stands, whether it is safe, and — the part that matters for your bottom line — why your business should care and what to do now.

Why WebMCP is worth your attention

Google + Microsoft

Browser makers building it together

WebMCP is co-developed by the Chrome and Edge teams and standardised through the W3C Web Machine Learning Community Group.

~89%

Fewer tokens than screenshot agents

A figure reported by early WebMCP implementers comparing structured tool calls with screenshot/DOM control (Webfuse and Zuplo, 2026). Directional, not a guarantee.

No new server

Backend you have to build to support it

WebMCP exposes your existing in-page functions as tools, reusing the user's current login and session — nothing new to host server-side.

---

What is WebMCP?

WebMCP — short for Web Model Context Protocol — is a browser API that lets a website declare its own features as structured "tools" that AI agents can call directly. Rather than an agent interpreting pixels, your page says, in effect: here are the things I can do, here is what each one needs, and here is how to run it.

The official Chrome for Developers documentation describes it as "a proposed web standard to help you build and expose structured tools for AI agents." It works through a new browser interface called navigator.modelContext, and it can expose two kinds of functionality: ordinary JavaScript functions, and standard HTML <form> elements.

The elevator pitch, from a business point of view, is simple: WebMCP turns your website into something agents can use like an API — without you having to build, host or maintain a separate API. The logic that already powers your "Search", "Add to basket" or "Book a call" buttons becomes a tool an agent can call, using the same login the user is already signed in with.

If you have read our explainer on what an AI agent actually is, WebMCP is the missing half of that story. Agents are the brains; WebMCP is the clean set of controls you give them so they stop fumbling around your interface.

---

WebMCP vs MCP: what is the difference?

This is the question almost everyone asks first, because the names are nearly identical. They are related but distinct — and understanding the difference is the fastest way to understand WebMCP.

MCP — the Model Context Protocol — was introduced by Anthropic in late 2024 and has become the de-facto standard for connecting AI models to external tools and data. An MCP "server" is a backend process that exposes capabilities to an agent over a protocol called JSON-RPC. It is brilliant for system-to-system, headless work — think "let Claude query our database" — but it lives on a server you build, host and secure.

WebMCP takes that same idea and moves it into the browser. Your tools live in the web page itself, run as client-side JavaScript, and reuse the session the user is already in. There is no separate server, no second login, and no need to replicate the user's state somewhere else.

WebMCP vs MCP — same vocabulary, different home

MCP (Model Context Protocol)

• Runs on a server — a separate backend process
• Speaks JSON-RPC over stdio or HTTP
• Needs its own authentication, hosting and upkeep
• Best for headless, API-level, system-to-system work
• Created by Anthropic in late 2024

WebMCP (Web Model Context Protocol)

• Runs in the browser — inside the page itself
• A native browser API: navigator.modelContext
• Reuses the user's existing login and session — no new server
• Best for live, user-facing actions on your website
• Co-created by Google, Microsoft and the W3C in 2025–26

Crucially, they are complementary, not competing. As the team behind the standard explains, WebMCP "derives direct inspiration and shares a common vocabulary with MCP," but is purpose-built for the web. A travel company might run a backend MCP server for its internal systems and use WebMCP on its website so a customer's agent can search and book in a live session. One is the programmatic back door; the other is the front door, opened politely.

---

Why WebMCP exists: the trouble with how agents browse today

To see why two browser giants bothered to build this, look at how an AI agent has to use a website without it. There are really only two options, and both are bad.

The screenshot approach is the one most "computer use" agents rely on today, and it is genuinely expensive: every action involves capturing an image, reasoning over it, and converting an intent into a pixel coordinate. Early WebMCP implementers report that structured tool calls can be in the region of 89% more token-efficient than screenshot-based control — a directional figure rather than a law of physics, but the direction is the point. Tools are cheaper, faster and far more reliable than pictures.

There is a deeper problem, too. A screenshot tells an agent what a page looks like, not what it does. A button that says "Go" could submit a search, delete an account or charge a card. WebMCP replaces that ambiguity with explicit, described, schema-backed actions — which is better for reliability and, as we will see, much better for safety.

---

How WebMCP actually works (with code)

Under the bonnet, WebMCP is refreshingly simple. The flow looks like this:

How a WebMCP tool call works

1. 1

   Register

   Your page calls navigator.modelContext.registerTool() — or annotates an HTML form — declaring a tool with a name, a description and a JSON Schema for its inputs.

2. 2

   Discover

   An AI agent in the browser reads the tools the page has published. It gets a clean menu of what your site can do, instead of a screenshot to decode.

3. 3

   Call

   The agent picks a tool and calls it with structured arguments that match your schema. No hunting around the DOM, no guesswork about which button to press.

4. 4

   Confirm

   For anything sensitive, the browser keeps a human in the loop — a tool can request confirmation before it actually runs.

5. 5

   Execute

   Your own JavaScript runs, using the user's existing login and session. The same code that powers your UI does the work.

6. 6

   Return

   The tool hands back a structured result the agent can use for its next step — and the loop continues until the task is done.

The imperative API: registerTool()

The JavaScript route gives you the most control. You call navigator.modelContext.registerTool() and define the tool's name, description, an input schema, and an execute function that runs when an agent calls it. Here is a realistic example — a product search tool on an ecommerce site:

navigator.modelContext.registerTool({
  name: "search_products",
  description: "Search the store catalogue by keyword and optional category.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "What the shopper is looking for" },
      category: { type: "string", description: "Optional category to filter by" }
    },
    required: ["query"]
  },
  async execute({ query, category }) {
    const results = await store.search(query, category);
    return {
      content: [{ type: "text", text: JSON.stringify(results) }]
    };
  }
});

Notice what is happening: the execute function is just your normal site code. It runs in the browser, with the shopper's session, and returns a structured result. You can register tools as components mount and remove them with navigator.modelContext.unregisterTool() as they unmount — which fits neatly with how modern single-page apps are built.

The declarative API: just annotate your forms

You do not need JavaScript at all for the common cases. The declarative route lets you turn an existing HTML form into a tool by adding a few attributes — toolname, tooldescription and toolparamdescription:

<form toolname="book_table"
      tooldescription="Reserve a table at the restaurant">
  <input name="date" toolparamdescription="Date in YYYY-MM-DD format">
  <input name="party_size" toolparamdescription="Number of guests">
  <button type="submit">Book</button>
</form>

That is the part that should make business owners sit up. If your site already has clean, well-structured forms — search, booking, contact, checkout — you are most of the way to being agent-ready already. As one analysis put it, clean HTML forms are roughly 80% of the way to WebMCP compliance. The browser handles the protocol plumbing; you just describe what each form does.

---

Who is behind WebMCP, and is it a real standard?

WebMCP is not a single company's land-grab. It is an unusually collaborative effort with a genuinely interesting origin story.

From side project to web standard

1. 1

   Jan 2025 — MCP-B

   Amazon engineer Alex Nahas builds MCP-B, a way for browser agents to call tools inside an authenticated tab — reusing the browser's own login instead of building new auth. It runs entirely client-side via a Chrome extension and postMessage.

2. 2

   Aug 2025 — The proposal

   Microsoft's Edge team, led by Patrick Brosset, publishes a WebMCP proposal. Google's Chrome team had been exploring the same idea with its own 'script tools'. The efforts converge.

3. 3

   Sep 2025 — W3C

   WebMCP moves into the W3C Web Machine Learning Community Group, with Google, Microsoft and Nahas collaborating on a single, open specification.

4. 4

   Feb 2026 — Chrome preview

   WebMCP ships as an early preview in Chrome 146 behind a flag, alongside a W3C draft community group report.

5. 5

   May 2026 — Origin trial

   At Google I/O 2026, WebMCP enters a Chrome 149 origin trial — letting real sites switch it on for real users without asking them to change browser settings.

So is WebMCP an official standard? Not in the formal sense — not yet. It is a draft developed by the W3C Web Machine Learning Community Group, with named authors from Microsoft (Brandon Walderman, Leo Lee, Andrew Nolan, Patrick Brosset and Dominic Farolino, among others) and Google (David Bokan, Khushal Sagar, Hannah Van Opstal). A Community Group draft is a serious, public, multi-vendor effort — but it is not the same as a ratified W3C Recommendation. The API will keep changing. The right posture is to treat WebMCP as an emerging standard you prepare for, not a finished one you bet the business on.

For the full backstory, Alex Nahas's interview with Arcade and Patrick Brosset's updates and clarifications are both worth reading from the people building it.

---

Which browsers support WebMCP?

This is moving quickly, so treat the snapshot below as exactly that — accurate at the time of writing in mid-2026, and worth re-checking against the Chrome origin-trial announcement before you plan around it.

The practical takeaway: WebMCP is real and testable today, but it is early. Build with it as a progressive enhancement — a layer that improves the experience for agents in browsers that support it, while your normal site keeps working perfectly for everyone else. Nothing about adding WebMCP tools should break the experience for a human visitor.

---

Is WebMCP safe? Security and the human in the loop

Handing AI agents the ability to do things on your site sounds alarming, and it should be taken seriously. The good news is that WebMCP was designed with that fear front of mind — and in most respects it is safer than the screenshot-clicking alternative, because it replaces broad, blunt access with a defined, governable set of actions.

Here are the risks that actually matter, and how the model addresses them:

WebMCP security: the real risks

What to design for when you expose tools to agents. Colour shows severity — the reds need a human in the loop.

High Medium Low

Prompt injection via page content

Likelihood · HighImpact · High

Malicious text on a page (or in a connected document) tries to trick the agent into calling tools it should not. OWASP's number-one LLM risk. WebMCP narrows the blast radius but does not remove it.

Over-permissioned write tools

Likelihood · MediumImpact · High

Exposing destructive actions — delete, pay, transfer — without confirmation. Gate every write behind human-in-the-loop approval.

The 'lethal trifecta'

Likelihood · MediumImpact · High

Private data, untrusted content and an exfiltration path open at once across tabs. Keep the three from ever combining.

Cross-origin tool exposure

Likelihood · MediumImpact · Medium

Tools leaking to origins you did not intend. WebMCP defaults to same-origin; expose deliberately via permissions policy.

Over-sharing through read tools

Likelihood · MediumImpact · Medium

A read-only tool returning more user data than intended. Scope returns tightly and treat tool output as visible to the agent.

No human review on sensitive flows

Likelihood · MediumImpact · High

Letting agents complete payments or account changes unattended. Require confirmation for anything that matters.

The protections built into the standard are sensible defaults rather than magic. WebMCP only runs in secure (HTTPS) contexts. Tools default to the same origin — to expose them to a cross-origin <iframe> you must explicitly add an allow="tools" permissions policy, and developers can scope tools to specific trusted origins. And the spec is explicit about keeping a human in the loop: an agent can be made to request user confirmation before a sensitive tool runs, so "agent decides, no one notices" is not the default.

That said, be clear-eyed. Prompt injection remains the hardest unsolved problem in this whole field, and the so-called "lethal trifecta" — the combination of private data, untrusted content and a way to send data out — applies to any browser agent. WebMCP reduces the attack surface by limiting agents to explicit tool calls instead of full DOM access, but if you expose powerful write tools you must design the guardrails. This is the same lesson we cover in our guide to custom AI development risks: an AI that can act is an AI that can be attacked, so treat security as a design requirement, not a launch-day afterthought.

---

Why your business should care: the agentic web is arriving

Here is the strategic point, and it is the reason this is not just a developer curiosity. Your customers are increasingly arriving with an agent in tow. Chrome has shipped in-browser automation, OpenAI's Atlas and Perplexity's Comet put agentic browsing in front of millions of people, and the major SaaS platforms a business already pays for have all added agentic features. The web is quietly gaining a second class of user.

In that world, the sites that are easy for agents to use win, and the ones that are hard get skipped. If an agent is comparing three suppliers and only one exposes a clean "get a quote" tool while the other two force it to wrestle with a screenshot, you can guess which one ends up in the answer. This is the same dynamic that mobile created fifteen years ago: the sites that adapted early compounded the advantage, and the ones that waited spent years catching up.

Should your business act on WebMCP now?

What kind of site do you run?

An ecommerce store, booking flow, SaaS dashboard or lead-gen form

↓

Yes — start now

These are exactly the high-intent actions agents want to complete. Annotate them as tools and you are an early mover in your category.

A content or brochure site with few interactive actions

↓

Get the foundations ready

Prioritise schema, llms.txt and AI-search visibility first; layer tools in as your interactions grow.

A regulated or high-risk flow (payments, health, legal)

↓

Pilot carefully, human-in-the-loop

Adopt, but gate every write action behind confirmation and review before you expose it to agents.

There is a commercial subtlety worth naming. For a long time, businesses worried that AI would disintermediate their website — that agents would scrape the data and the customer would never see the brand. WebMCP points the other way. By giving agents a tool that runs inside your experience, with your logic and your rules, you keep control of the interaction instead of being scraped around. It is the difference between an agent guessing at your site and an agent being formally introduced to it.

---

WebMCP and SEO: does it replace search optimisation?

No — and this is the most common misunderstanding, so it is worth being precise. WebMCP does not make an agent choose you. It makes you easy to act on once it already has. Those are two different jobs.

The decision to use your site in the first place still runs on everything we already obsess over: classic search rankings, structured data, authority, reviews, and increasingly whether you are cited inside AI answers — the discipline we call generative engine optimisation (GEO). As Semrush's analysis of WebMCP put it bluntly, "you can't be agent-ready without strong SEO foundations." Tools are the last mile, not the whole journey.

So think of it as a stack. SEO and GEO get you recommended; structured data helps machines understand you; WebMCP makes you executable. Here is how the pieces weigh up when you assess whether your site is genuinely ready for the agentic web:

Is your site agent-ready?

How much each factor moves the needle on agent-readiness. The top of the list is where most sites should start.

• Clean, semantic HTML forms90/100

  The fastest on-ramp — declarative WebMCP turns well-built forms into tools with a few attributes.

• Structured data / schema markup85/100

  Helps agents (and AI search) understand what your pages and products actually are. See our schema guide.

• AI-search visibility and citations80/100

  Agents tend to act where you are already recommended. This is the GEO layer.

• Stable, predictable URLs and states72/100

  Agents need actions that do not move or break between visits.

• An llms.txt and crawlable content68/100

  Machine-readable signposting of what matters on your site.

• HTTPS and a sane permissions setup60/100

  WebMCP only runs in secure contexts and respects same-origin boundaries by default.

If that list reads like a to-do list you have not started, the good news is that the foundational work pays off no matter how fast WebMCP itself matures. Our guides to schema markup, llms.txt and getting cited in ChatGPT are the right place to begin — and you can measure your AI search visibility so you know where you stand before agents start arriving in numbers. (Our free AI visibility checker is a fast way to get a baseline.)

---

How to get your website agent-ready: a practical roadmap

You do not need to boil the ocean. WebMCP rewards a staged approach — start with the cheap, high-leverage wins, then go deeper where it pays.

Three levels of WebMCP adoption

Most businesses should start at the top and earn their way down as agentic traffic grows.

Start here

Declarative quick win

A few hours

Lowest effort

Annotate the forms you already have — search, booking, contact, checkout — so agents can use them.

• Add toolname and tooldescription to key forms
• No new backend required
• Pure progressive enhancement

Custom imperative tools

Days to weeks

Medium effort

Expose richer actions with JavaScript — filtered search, account actions, multi-step flows.

• registerTool() for bespoke tools
• JSON Schema inputs and structured returns
• Human-in-the-loop on every write

Full agentic commerce

Weeks and ongoing

Strategic

Treat agents as a first-class channel: tools plus structured data plus measurement.

• WebMCP plus schema, and backend MCP where it fits
• Agent analytics and guardrails
• Designed for agentic checkout

And here is the short checklist we would actually work through with a client:

Your WebMCP readiness checklist

• ✓Audit your highest-intent actions — search, booking, lead form, checkout — and make sure each is a clean, semantic HTML form
• ✓Add declarative tool annotations (toolname, tooldescription) to those forms first — it is the cheapest possible win
• ✓Identify two or three richer actions worth exposing as custom registerTool() tools, and write clear descriptions and input schemas for them
• ✓Put a human-in-the-loop confirmation on anything that spends money, changes data or sends a message
• ✓Keep everything same-origin and over HTTPS; only expose cross-origin tools deliberately
• ✓Shore up the foundations in parallel — schema markup, llms.txt, and AI-search visibility — because tools only matter once agents choose you
• ✓Treat it as progressive enhancement: your site must work perfectly for humans whether or not the browser supports WebMCP
• ✓Re-check the spec before you ship — it is a fast-moving draft, not a finished standard

---

Frequently asked questions

WebMCP — common questions

What is WebMCP?

WebMCP (Web Model Context Protocol) is a proposed web standard that lets a website expose its own features — JavaScript functions or HTML forms — as structured 'tools' that AI agents can call directly in the browser. Instead of an agent screenshotting your page and guessing where to click, your site hands it a clean menu of actions, each with a name, a description and a defined set of inputs. It is built around a new browser API called navigator.modelContext, and is being standardised through the W3C Web Machine Learning Community Group by Google and Microsoft.

What is the difference between WebMCP and MCP?

MCP (the Model Context Protocol, created by Anthropic in late 2024) is a server-side standard: you run a backend process that exposes tools to AI agents over JSON-RPC, with its own hosting and authentication. WebMCP does the same job inside the browser. Your tools live in the web page itself, run as ordinary client-side JavaScript, and reuse the user's existing login and session — no new server to build or host. They share a common vocabulary (tools, schemas, parameters) and are complementary rather than competing: many businesses will use backend MCP for system-to-system work and WebMCP for live, user-facing actions on their site.

Who created WebMCP?

WebMCP grew out of three converging efforts. Alex Nahas, then an engineer at Amazon, built a precursor called MCP-B in early 2025 to let browser agents use tools inside an authenticated tab. Around the same time, Microsoft's Edge team (notably Patrick Brosset) published a WebMCP proposal and Google's Chrome team was exploring the same idea. The three converged into a single proposal now developed in the open through the W3C Web Machine Learning Community Group, with named contributors from both Microsoft and Google.

Is WebMCP an official standard?

Not yet, in the formal sense. As of mid-2026 WebMCP is a draft developed by the W3C Web Machine Learning Community Group — the same group behind other browser AI APIs — not a ratified W3C Recommendation. It is real and shipping in early form (a Chrome flag and a Chrome 149 origin trial), but the API is still evolving. Treat it as an emerging standard worth preparing for, not a finished one to bet your whole stack on.

Which browsers support WebMCP?

Chrome leads: WebMCP arrived as an early preview in Chrome 146 behind a flag (chrome://flags), and moved into a public origin trial in Chrome 149 so sites can switch it on for real users without asking them to change settings. Microsoft Edge, which shares Chrome's engine, has signalled support from its team. Firefox and Safari had not committed to implementations at the time of writing. Because it is behind flags and trials, you should treat WebMCP as experimental and progressively enhance with it, not depend on it.

How do I add WebMCP to my website?

There are two routes. The declarative route adds attributes such as toolname and tooldescription to your existing HTML forms, so the browser exposes them as tools automatically — often a few hours of work for a site with clean forms. The imperative route uses JavaScript: you call navigator.modelContext.registerTool() to define richer tools with a JSON Schema for their inputs and a function that runs when an agent calls them. Most teams start declaratively with their highest-intent forms (search, booking, contact, checkout) and add imperative tools where they need more control.

Is WebMCP safe?

It is designed to be safer than the alternative. Letting an agent roam your DOM and take screenshots gives it broad, blunt access; WebMCP narrows that to a defined set of explicit tool calls, runs only in secure (HTTPS) contexts, defaults to the same origin, and keeps a human in the loop for sensitive actions. It does not remove every risk — prompt injection, over-permissioned write tools and data exposure still need careful design — but it gives developers far more control over what an agent can and cannot do than screenshot-based automation ever did.

Does WebMCP replace SEO?

No. WebMCP is the layer that lets agents act on your site once they have decided to use it — it does not make them choose you in the first place. That decision still depends on classic search visibility, structured data and being cited in AI answers (generative engine optimisation). Think of it as a stack: strong SEO and GEO get you recommended; WebMCP makes you easy to act on. You need the foundations before the tools are worth much.

Is WebMCP the same as web scraping?

No — in many ways it is the opposite. Scraping is an agent taking data and actions from your site without your involvement, by parsing HTML it was never handed deliberately. WebMCP is you choosing what to expose, on your terms, with schemas, permissions and human-in-the-loop controls. It replaces fragile, adversarial scraping and screenshot-clicking with a cooperative, reliable interface that you design and govern.

---

The bottom line

WebMCP is an early but serious attempt to fix something genuinely broken: the way AI agents have had to fumble through websites built only for human eyes. By letting your site hand agents a clean, described, governable set of tools — through the new navigator.modelContext API, built by Google and Microsoft and standardised at the W3C — it makes the web programmable, reliable and safer for automation in a way screenshots and scraping never could be.

It is not finished, and it is not a silver bullet. The API is still changing, browser support is early, and it does not replace the SEO and GEO work that gets you chosen in the first place. But the direction is unmistakable, the cost of starting is low, and — as with mobile and responsive design — the businesses that prepare early will compound an advantage over the ones that wait. If your site already has clean forms, you are closer than you think.

The smart move in 2026 is not to rebuild everything for agents overnight. It is to get your foundations right, annotate your highest-intent actions, and be ready when the agentic web arrives in numbers — which, on the current trajectory, will be sooner than most businesses expect.

---

Qwestyon is a UK agency that helps businesses get found and get chosen in the age of AI — from generative engine optimisation to building custom AI agents and agentic solutions. If this guide was useful, share it with someone whose website is about to start getting visitors that do not have eyes. To talk through what WebMCP means for your business, start a conversation.