WebMCP explained: what it is, how it differs from MCP and what to do about it

What is WebMCP, and why now?

WebMCP (Web Model Context Protocol) is a browser API that lets you, as a website builder, expose functions of your web application to AI agents. Such a function is called a tool. Every tool gets a name, a plain-language description and a schema that defines what input it expects. The specification (opens in new window) states the goal briefly: let web applications offer JavaScript tools to AI agents.

An example makes it concrete. Say you run a webshop with a filter for size, colour and price. An agent operating that filter without WebMCP takes a screenshot, hunts for the right dropdown, clicks, waits, takes another screenshot. With WebMCP you register a single tool, `filter_products`, with three fields. The agent fills those in and your own code does the rest. The filter on your page moves along with it, so the user sees exactly what happens.

The standard comes out of the W3C's Web Machine Learning Community Group (opens in new window). The original authors worked at Microsoft and Google. The current version of the spec is a Draft Community Group Report dated 9 September 2026, with Brandon Walderman (Microsoft), Khushal Sagar and Dominic Farolino (Google) as editors.

Why this is happening now

Five moments show how fast this moved:

At the I/O announcement, Google showed logos of brands experimenting with WebMCP, including Expedia, Booking.com, Shopify, Etsy, Target, Credit Karma and TurboTax (source (opens in new window)). Those are travel, retail and financial companies: sectors where a customer fills in a form to book, buy or apply for something.

Search interest shows the same spike. According to Ahrefs, people in the Netherlands searched for "webmcp" about 8 times in January 2026. In February, the month of the early preview, that jumped to 1,077.

Source: Ahrefs Keywords Explorer, retrieved 10 September 2026. The flat NL values from June onward are an Ahrefs estimate at low volumes.

What I notice here: the US curve settles after the peak into a stable floor of roughly 2,700 searches a month. The Netherlands drops much further. My reading is that developers in the US actually started building with it, while in the Netherlands it stayed at curiosity. For a board member that mainly buys time: you can now work out calmly which actions you want to hand to agents, before a competitor or a platform makes that choice for you.

WebMCP belongs to a broader shift often called the agentic web: a web where AI agents search, compare and act on people's behalf. How that changes the high street is covered in agentic commerce: how AI agents are turning online retail upside down. Whether you will still need a website of your own is covered in do we still need websites in 2026?.

What is MCP (Model Context Protocol)?

MCP is an open standard for connecting AI applications to external systems. The official documentation (opens in new window) uses a comparison that sticks: think of MCP as a USB-C port for AI applications. One kind of connector, many different devices.

Anthropic introduced MCP on 25 November 2024 (opens in new window). A year later, on 9 December 2025 (opens in new window), Anthropic moved the protocol into the Agentic AI Foundation, a fund within the Linux Foundation it set up together with Block and OpenAI. Google, Microsoft, AWS, Cloudflare and Bloomberg back that foundation. The existing maintainers keep technical control.

How MCP works

MCP has three roles (architecture overview (opens in new window)):

• The host is the AI application you work in, such as Claude, ChatGPT or a code editor.
• The client is the part inside that host that maintains one connection to one server.
• The server is the program that supplies context and actions, for example a connection to your CRM, your files or a booking system.

An MCP server offers three kinds of building blocks. Tools are functions the AI can execute, such as a database query or an API call. Resources are data that serve as context, such as the contents of a file. Prompts are reusable templates for a conversation with the model. A server can run locally on your laptop or remotely over HTTP, in which case it serves many users at once.

The protocol is evolving fast. The 28 July 2026 (opens in new window) specification made the core of MCP stateless: every request describes itself, which makes it easier to run servers behind ordinary infrastructure. The same release tightened authorisation. According to the maintainers, the main SDKs together see nearly half a billion downloads a month.

Since 26 January 2026 (opens in new window), there is also MCP Apps, an extension Anthropic and OpenAI developed together with the MCP-UI community. It lets a tool return an interactive screen that appears directly in the chat window, for example a premium comparison with buttons. Keep the three terms apart: MCP (the connection), MCP Apps (an interface inside the chat) and WebMCP (tools on your own web page).

MCP servers are powerful, and therefore also an attack surface. How attackers hide malicious instructions in tool descriptions is covered in AI skills are the new phishing.

What is the difference between WebMCP and MCP?

The short answer: MCP puts tools on a server, WebMCP puts tools on a web page. The names look alike because WebMCP borrows MCP's vocabulary — tools, schemas, parameters. It is a separate standard, though. The WebMCP explainer (opens in new window) says so itself: WebMCP draws its inspiration directly from MCP, but is built as a solution that fits the web platform and is safe on the user's end.

Google published its own comparison (opens in new window). Below is that comparison, extended with three points that matter to a decision-maker: sign-in, who builds it, and who governs the standard.

The sign-in difference is the heaviest point for many organisations. With an MCP server you have to arrange who the agent is and what it may do, usually with OAuth. With WebMCP, the tool runs in the session of someone already signed in to your site. The spec (opens in new window) therefore assumes agents inherit the user's identity and sign-in state from the browser. That removes an integration project, and it moves responsibility for what happens closer to the user.

When do you choose which?

Google recommends using both, each for its own job. MCP carries the core logic: fetching data, background tasks, actions that also need to work when nobody is on your site. WebMCP gives an agent in the browser control over your interface at the moment a customer shows up.

A travel company makes the difference clear. Through an MCP server, an assistant in ChatGPT or Claude can check availability, even if the traveller has never visited the site. Through WebMCP, an agent in Chrome can fill in the seat selection on the booking page while the traveller is signed in and watching. The first is about reach beyond your site. The second is about ease of use on your site.

Push that trade-off further and you quickly land on where your agents run and how dependent you are on a single vendor. That question is central to AI vendor lock-in: why the kill switch is your problem.

How does WebMCP work technically?

WebMCP gives you two ways to build tools. The imperative API is JavaScript and gives you full control. The declarative API is a handful of extra HTML attributes on a form you already have. Both are described in the Chrome documentation (opens in new window).

The imperative API: registering a tool in JavaScript

You register a tool via `document.modelContext.registerTool()`. Watch out if you read older tutorials: earlier versions used `navigator.modelContext` as the entry point. The current spec (opens in new window) and the Chrome documentation (opens in new window) use `document.modelContext`.

A tool consists of a name, a description, an input schema in JSON Schema, and an `execute` function that does the work. Below is an example for a premium calculator. The shape follows the Chrome documentation; the calculator function itself is your own existing code.

await document.modelContext.registerTool({
  name: 'calculate_scooter_premium',
  title: 'Calculate scooter insurance premium',
  description:
    'Calculates the monthly premium for scooter insurance based on ' +
    'postcode, year built and coverage. Does not conclude a contract.',
  inputSchema: {
    type: 'object',
    properties: {
      postcode: { type: 'string', description: 'Dutch postcode, e.g. 3401AB' },
      yearBuilt: { type: 'integer', minimum: 1990 },
      coverage: { type: 'string', enum: ['liability', 'liability_limited_casco', 'allrisk'] },
    },
    required: ['postcode', 'yearBuilt', 'coverage'],
  },
  annotations: { readOnlyHint: true },
  execute: async ({ postcode, yearBuilt, coverage }) => {
    const premium = await calculatePremium(postcode, yearBuilt, coverage); // your existing code
    showResultOnPage(premium); // the user sees the same result
    return `Monthly premium: EUR ${premium.toFixed(2)}`;
  },
});

Unregistering a tool works with an `AbortSignal`: you pass `{ signal: controller.signal }` when registering and call `controller.abort()` later. That way you only offer a tool while it makes sense, for example only after sign-in.

Annotations: telling the agent how risky a tool is

The spec has three annotations that help an agent judge how careful to be:

All three default to `false` (spec, ToolAnnotations (opens in new window)). They are hints: you tell the agent what the tool does, the agent decides how to handle it. An agent that sees `consequentialHint` should ask the user for confirmation. The spec cannot enforce that.

The declarative API: a form you already have

If you already have a clean HTML form, a few attributes turn it into a tool. This example comes from the Chrome documentation (opens in new window), adapted to a claims report:

<form toolname="report_claim"
      tooldescription="Reports damage on an existing policy. The customer submits it themselves."
      action="/claims/report">
<label for="policynumber">Policy number</label>   <input type="text" id="policynumber" name="policynumber" required>
<select name="type" required           toolparamdescription="Type of claim: determines which team receives the report.">     <option value="collision">Collision</option>     <option value="theft">Theft</option>     <option value="fire">Fire</option>   </select>
<button type="submit">Submit report</button> </form>

`toolname` and `tooldescription` name the tool. `toolparamdescription` explains what belongs in each field. The agent fills in the fields, but the user presses submit themselves. Only once you add `toolautosubmit` may the agent submit the form itself too.

A few more things matter for developers. When an agent submits the form, `SubmitEvent.agentInvoked` is `true`, and `respondWith()` sends a result or error back to the model. Chrome fires a `toolactivated` event once the fields are filled in and a `toolcancel` event if the user backs out. The CSS pseudo-classes `:tool-form-active` and `:tool-submit-active` let you show that an agent is working with the form.

What happens when an agent calls a tool

Safety lives in the browser

WebMCP only works in a secure context (HTTPS) and in documents that are separated by origin. Its use falls under the `tools` Permissions Policy, which defaults to `self`. An iframe from another domain may only offer tools if you explicitly grant it `allow="tools"` (Chrome documentation (opens in new window)). The spec's `exposedTo` option lets you make a tool visible only to specific origins.

Why tools work better than an agent reading your screen

Agents have been able to operate websites without WebMCP for a while. They take screenshots, read the HTML structure, and simulate clicks and keystrokes. That works, but it's slow and fragile. Move a button and the agent clicks next to it. Give a date picker its own widget and the agent loses its way.

Chrome's origin-trial announcement sums up the difference briefly: an agent no longer has to guess what a button or field is for, because the site states its purpose itself (source (opens in new window)). That has three consequences an organisation notices.

It's faster and makes fewer mistakes. A tool with a schema states exactly what input is valid. A field with a list of three coverage options leaves no room for an invented fourth one.

You also keep control of your own interface. One of the goals in the explainer (opens in new window) is preventing web content from being pushed aside by intermediaries. As long as the action happens on your page, the customer stays with you, sees your own terms and disclaimers, and your own validation runs. How hard platforms are pushing for that position instead is covered in why OpenAI is becoming your competitor.

And the human stays in view. The explainer explicitly lists as a non-goal: fully autonomous workflows without human oversight, and replacing the human interface. The user sees the page move while the agent works.

There's an accessibility angle too. The explainer names "improving accessibility via agents" as a goal. A form that's well labelled for a screen reader is usually also easy to turn into a declarative WebMCP tool. Anyone who has already invested in accessibility as innovation has a head start here.

What does WebMCP mean for your website, SEO and AI visibility?

Anyone working on AI visibility asks whether AI systems find and cite them. WebMCP is about the next step: once the user has arrived, can an agent actually do something on your site? Being found and being usable belong together, but they're different jobs. The first is covered in the AI visibility guide. What an AI Overview does to your traffic is covered in what an AI Overview means for your website.

Is WebMCP a ranking factor?

There's no evidence for that. Google has not said WebMCP counts toward search rankings. Google did add a new category to Lighthouse, Chrome's free audit tool: agentic browsing (opens in new window). It measures how well your site is built for interacting with machines. It doesn't give a score from 0 to 100, but a ratio of passed checks. You need Chrome 150 or newer.

The category contains these audits:

Source: Lighthouse agentic browsing scoring (opens in new window), last updated 5 May 2026.

That list says something about how Google views the web. WebMCP sits alongside llms.txt, accessibility and a stable layout in one row. Together they form a checklist for a site machines can read and operate. Whether that checklist will ever count toward your Google position, Google hasn't said. As a baseline measurement, you can use it today.

How WebMCP relates to llms.txt and schema.org

Three techniques often get lumped together. Each does something different:

Schema.org and llms.txt help an AI system understand what you have. WebMCP helps an agent get something done. A strong site ultimately has all three.

The question your organisation has to answer

A webshop that sets up WebMCP well makes it easy for an agent to search, filter and fill a shopping basket. That sounds like pure upside. It does change who your customer is at the moment of choice: increasingly, it's an agent making a quick comparison. The site with the clearest tools becomes the easiest choice for that agent, and therefore more often the winner of the comparison.

WebMCP in insurance practice

Insurance is a textbook example of work that runs through forms: calculating a premium, requesting a quote, reporting a claim, changing an address, or cancelling a policy. Those are exactly the actions an agent can do something with using WebMCP. They're also actions with legal and financial consequences for the customer.

This breakdown helps decide what you do and don't offer as a tool:

That last row deserves attention. Since 19 June 2026, a consumer who takes out a contract online, including a financial service such as insurance, must be able to withdraw from it through a clearly visible withdrawal function (Directive (EU) 2023/2673 (opens in new window)). What that means for insurers and advisers is covered in withdrawal or cancellation: the new cancel button for insurance and in dark patterns ban and the mandatory cancel button. If you build a cancel button for people, the same flow, with a few attributes, can also become usable for a customer's agent. The reverse obligation then applies too: don't make it harder for an agent to cancel than to sign up.

What I notice on the build side: I'm building an MCP server myself that calculates a scooter insurance premium inside an AI chat. The protocol was the easy part. The hard decision was where the agent stops. In my design, the agent only calculates the premium. The customer then gets a link to the existing quote page on the website and completes the purchase there themselves. That way no new payment flow had to be built, and the customer takes the final step on a page that already exists and is already tested. The same trade-off comes back with WebMCP, just on your own site.

For advisers and intermediaries, something else applies too. If an agent fills in a form on your site, your duty of care toward the customer still stands. An agent that picks coverage based on the lowest premium doesn't know the customer has an expensive e-bike in the shed. For advice-heavy products, the value of WebMCP therefore sits mostly in the early stage — fetching information, pre-filling data — and less in the actual sign-up. That's an assessment based on how advice works today. How to let AI safely process customer data is covered in uploading customer data to AI: what is and isn't allowed.

What risks does WebMCP bring?

WebMCP makes it easier for agents to do things. That applies to good intentions and bad ones alike. The spec (opens in new window) is notably open about this and names five risks:

1. Prompt injection. Malicious instructions in a tool's name, description or parameters that steer the agent's behaviour.
2. Misrepresented intent. A tool that does something other than its description promises, or an agent that misreads the user's intent.
3. Privacy leaks via excessive parameters. A tool that asks for more data than it needs pulls sensitive information out of the agent.
4. Cross-origin boundaries. Tools that bypass the separation between origins.
5. Private browsing. How tools behave in an incognito window, where the user expects nothing to persist.

To grasp the weight of this, you need to know what the spec assumes about agents. They can inherit the user's identity and sign-in state, including payment details and browsing history, and combine information across multiple websites. An agent with that access that reads a manipulated tool description can do a lot of damage.

The spec names four countermeasures. Limit the length of tool descriptions and input, leaving less room for hidden instructions. Work with shared attack test suites, so browsers build comparable defences. Flag untrusted output with `untrustedContentHint`. And flag tools with consequences with `consequentialHint`.

What the spec does not arrange for you

A few things you have to set up yourself:

• Changing tools. Tools can appear and disappear during a visit; the spec even has a `toolchange` event for it. A change to your site can therefore quietly open up new actions for agents without anyone noticing. Decide who approves a new tool, the same as for a new API.
• Logging. The browser doesn't track for you which agent called which tool with which input. If you want to be able to reconstruct that, log it yourself in your own `execute` function or form handler.
• Server-side validation. An agent can send input your interface would normally block. Never trust the schema alone: revalidate everything on your server.

At the boardroom table, my first question on proposals like this is always the same: which action may an agent take on a customer's behalf without that customer confirming again? The answer determines your risk profile more than which technology you pick. For read actions, the answer is generous. For anything involving money, health or a contract, my view for now is: none at all.

How agents behave when they get more freedom than intended is covered in the escape: how AI agents hacked their way out of their cage. Why your organisation needs to be able to read along with what agents do is covered in AI agents: in 5 days, a language of their own you can't read. And the broader security problem of tools you didn't write yourself is covered in AI skills are the new phishing.

Browser support and standardisation: where does it stand?

WebMCP is still experimental in September 2026. You can test it and turn it on in a trial for real visitors, but it's not on by default anywhere. This is the state according to the Community Group's implementation overview (opens in new window):

An origin trial is a trial where a site requests a token. That token turns on an experimental feature for your own visitors, even if they haven't enabled the feature themselves. The browser maker collects feedback this way before deciding whether the feature stays.

The chicken-and-egg problem

A tool only has value once an agent calls it. Google said at I/O that Gemini in Chrome would support WebMCP "soon" (source (opens in new window)). As of 10 September 2026, there was no official confirmation that this is already live for all users. Anyone building now is building for an audience that hasn't arrived yet. That argues for small trials on low-risk pages, and against a large project.

What the W3C status means

The spec is a Draft Community Group Report. A Community Group is an open working group within the W3C anyone can join. Such a report is not yet on the W3C's formal standardisation track, which ends at a so-called Recommendation. That route is long. Names, attributes and behaviour can still change, as the move from `navigator.modelContext` to `document.modelContext` already showed. Plan for maintenance: every Chrome release can shift something.

The six biggest misconceptions about WebMCP

Misconception: WebMCP is a new version of MCP. In reality, WebMCP is a separate standard from the W3C's Web Machine Learning Community Group. It borrows MCP's vocabulary (tools, schemas, parameters), but it's a browser API, governed outside the Agentic AI Foundation that governs MCP.

Misconception: WebMCP lets any AI chatbot use your site. In reality, WebMCP only works for agents running in the browser, in a tab where the user has your site open. A chatbot running on a server never sees your WebMCP tools. For that you need an MCP server or an API.

Misconception: WebMCP helps you rank higher in Google. In reality, Google has never said so. Lighthouse does have an agentic browsing category with WebMCP audits, and that gives you a baseline. No effect on your search ranking has been demonstrated anywhere.

Misconception: an agent can just pay or cancel through WebMCP. In reality, you decide which tools exist. With a declarative form, the user submits by default unless you add `toolautosubmit`. The risk lies in what you expose and how well you validate input.

Misconception: WebMCP replaces your API or MCP server. In reality, Google calls the two complementary. MCP carries the logic and also works when nobody is on your site. WebMCP works during the visit, inside your interface. Replacing backend integrations is even explicitly listed as a non-goal in the explainer.

Misconception: you have to go all-in now or you'll be too late. In reality, WebMCP is a trial in two browsers, with a spec that's still changing. A small test with one read action delivers more right now than a large project that has to redo itself at the next spec change.

How do you tackle WebMCP? (step-by-step plan)

This plan works for an organisation with its own website and a developer or agency building on it.

1. Pick the five tasks customers do most often on your site. Think search, filtering, calculating a premium or price, checking a status, filling in a form. Check your analytics for which pages and forms get used most. Don't start with what's technically fun.
2. Sort them by consequence. Put every task into one of three buckets: read-only, changes something, or involves money or a contract. Decide per bucket who presses the final button.
3. Start with one read action as an imperative tool. A calculator or search function with `readOnlyHint: true` is a safe first step. Reuse your existing code inside the `execute` function and show the result on the page too.
4. Annotate your most important form declaratively, without autosubmit. Add `toolname`, `tooldescription` and, where needed, `toolparamdescription`. The user keeps submitting it themselves.
5. Test locally and measure. Turn on `chrome://flags/#enable-webmcp-testing`, use the Model Context Tool Inspector extension from the Chrome Web Store, and run the Lighthouse agentic browsing category (Chrome 150 or newer).
6. Set up governance before you go live. Who approves new tools? Where do you log calls made by agents? How do you validate input server-side? Which tools get `consequentialHint`?
7. Join the origin trial, or wait deliberately. Only sign up once steps 1 through 6 are in place. Plan a short check at every new Chrome version, because the spec is still changing.

WebMCP and the rules

WebMCP is a technique. Which rules apply depends on what you do with it. For Dutch organisations, three frameworks matter. What follows is an assessment: have it checked legally for your own situation.

The GDPR. The principle of data minimisation (Article 5(1)(c) GDPR (opens in new window)) lines up with the risk the spec itself names: tools that ask for more parameters than needed. So ask a tool for only what that one action needs. A premium calculator needs a postcode, not the birthdate of the whole family.

The EU AI Act. A website that only offers tools does not, by itself, place an AI system on the market. The obligations in the AI Act sit primarily with whoever offers or deploys an AI system — in the first place the maker and user of the agent. If you deploy an agent yourself to help customers on your site, that's different. Whether the AI Act applies to your organisation is something you can work out via the EU AI Act guide or with the AI Act Impact Scanner.

Consumer and sector rules. The withdrawal function from Directive (EU) 2023/2673 has applied since 19 June 2026 to contracts consumers conclude online, including financial services such as insurance. An agent changes nothing about your disclosure duties, your duty of care, or the ban on misleading interfaces. If an agent fills in a form a human never saw, that can raise questions about what the customer actually knew at the moment of signing. That's one more reason to have the human confirm contracts themselves.

Setting up the governance framework around AI is covered in the AI governance guide.

Frequently asked questions

Go deeper

This guide is the hub. The pieces below work out the sub-questions in more depth.

Agents, websites and platforms

• Agentic commerce: how AI agents are turning online retail upside down: what changes when an agent searches, compares and buys on the customer's behalf.
• Do we still need websites in 2026?: what role your own site keeps now a language model can take out insurance for you.
• Why OpenAI is becoming your competitor: how platforms pull functions toward themselves, and where your niche stays protected.
• AI visibility: the sister guide on being found and cited by ChatGPT, Gemini and Google AI Overviews.
• What an AI Overview means for your website: the effect of AI answers on your search traffic.

Safety and oversight of agents

• AI skills are the new phishing: tool poisoning and the risks of MCP servers you didn't write yourself.
• The escape: how AI agents hacked their way out of their cage: what happens when agents get more room than intended.
• AI agents: in 5 days, a language of their own you can't read: why readability and external logging must be mandatory for agents.
• Uploading customer data to AI: what is and isn't allowed: letting AI process customer data safely.
• AI vendor lock-in: why the kill switch is your problem: why where your agents run is a governance decision.

Insurance, forms and accessibility

• Withdrawal or cancellation: the new cancel button: what the rules since 19 June 2026 ask of insurers and advisers.
• Dark patterns ban and the mandatory cancel button: why cancelling should be as easy as signing up.
• Accessibility as innovation: well-labelled forms help people with a disability and AI agents at the same time.

Frameworks

• EU AI Act and AI governance: the guides on rules and governance around AI.

About Marc Diks

Marc Diks has worked in online marketing and digital financial services for more than 25 years, much of it in insurance. He sits at board level leading AI strategy, and builds AI applications himself, including MCP servers, without a formal coding background. More about his background on the about page.