← notes · 2026-10-08 · 7 min read · ai · agents · web

WebMCP: websites now ship an interface for AI agents too

WebMCP, proposed by Google and Microsoft, lets a site expose its own functions to in-browser agents as tools. What it is, how to set it up, where it stands as of October 2026, and why it is worth paying attention to now.

What does an AI agent do today when it searches for a flight on a website? It takes a screenshot or reads the DOM, guesses which box says "From", clicks, waits for the date picker, hits the wrong day, tries again. It imitates an interface built for humans. It is slow, expensive and brittle, and it breaks the day the site's design changes.

WebMCP comes at the problem from the other side: the agent should not guess the interface; the site should tell it what it can do.

What WebMCP is

WebMCP (Web Model Context Protocol) is a proposed browser API that lets a web page expose its own functions to in-browser agents as tools. The site defines a tool: a name, a description of what it does, inputs described with JSON Schema, and the function to run. When the agent lands on the page it sees that list and calls search_flights({ from, to, date }) directly instead of poking at buttons.

It takes its name from Anthropic's MCP and uses the same tool model, but it runs in a different place. With MCP you stand up a separate server and solve authentication separately. With WebMCP the tool lives inside the page and runs with the user's existing session: no extra server, no extra OAuth flow. And the user is at the screen; everything the agent does is visible in the tab.

In short: MCP connects an agent to your services, WebMCP connects it to the user's open tab.

Where it came from, where it stands

August 2025. The proposal came from the Microsoft Edge team, with Google joining as co-author shortly after. Its precursor is Alex Nahas's open-source project MCP-B.
February 2026. First draft report in the W3C Web Machine Learning Community Group, edited by people from Microsoft and Google. A first implementation landed in Chrome 146 behind a flag.
May 2026, Google I/O. An origin trial started with Chrome 149, so site owners can turn the feature on for real users with a token. Google announced that Gemini in Chrome will use WebMCP tools.
June 2026. Experimental support behind a flag in Edge 147.
July 2026. The API moved from navigator.modelContext to document.modelContext; tools belong to the document, not the browser. Chrome 150 deprecates the old location.
August 2026. Cloudflare released a developer preview that adds a WebMCP layer to any site with one setting.
October 2026. The first enterprise announcements are arriving. Orgvue lets customers connect their own agent to an open workspace tab through WebMCP.

To be honest about the picture: WebMCP is not a W3C standard and is not on the standards track; it is a community group draft. Firefox and Safari have not committed to an implementation. Real-world usage is very low, and there is no announcement yet that Gemini in Chrome support is generally available. Still, Chrome and Edge working on the same draft says this has left the lab.

How to do it

There are two ways.

1. The declarative API: existing forms. If you already have an HTML form, a few attributes turn it into a tool. The form becomes the tool's identity and its fields become parameters:

<form toolname="search_flights"
      tooldescription="Searches flights between two cities on a given date."
      action="/search">
  <input name="from" required>
  <input name="to" required>
  <input name="date" type="date" required>
  <button type="submit">Search</button>
</form>

You can tell whether an agent submitted it through agentInvoked on the submit event, and return a result to the model with respondWith().

2. The imperative API: JavaScript. When there is no form, or the job spans several steps, the tool is defined in code:

const mc = document.modelContext ?? navigator.modelContext;

if (mc) {
  await mc.registerTool({
    name: "search_flights",
    description: "Searches flights between two cities on a given date.",
    inputSchema: {
      type: "object",
      properties: {
        from: { type: "string", description: "Departure airport (IATA code)" },
        to: { type: "string", description: "Arrival airport (IATA code)" },
        date: { type: "string", format: "date" },
      },
      required: ["from", "to", "date"],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ from, to, date }) => {
      const results = await searchFlights(from, to, date); // the site's existing function
      return JSON.stringify(results);
    },
  });
}

Things to watch:

Feature-detect, and keep the site working without it. The API has moved twice in a year; document.modelContext ?? navigator.modelContext covers both during the transition.
Annotations are a security contract. readOnlyHint says the tool only reads. consequentialHint is for actions that are hard to undo: payments, bookings, deletions. untrustedContentHint flags outside data in the output, such as user reviews, and warns the agent about prompt injection.
Write the description for the model. One short sentence on when to use the tool, plus an example format for parameters, is enough. Chrome's recommended character limits push you to keep it short anyway.
A tool should never do more than the UI can. The agent acts with the user's session; a tool that unlocks a permission the interface does not offer is a security hole.
Access is same-origin by default. The tools Permissions Policy blocks cross-origin iframes unless you opt in with allow="tools", and exposedTo narrows which origins can see a tool.

To try it, enable chrome://flags/#enable-webmcp-testing in Chrome. DevTools shows registered tools and how their JSON Schema is parsed.

Why pay attention now

Last month I gave every page on this site a Markdown twin and added an llms.txt (the note is here). That work was about the site being readable by AI engines. WebMCP is the next layer: the site being usable by agents.

There was a time when "is the site mobile friendly" decided a business's fate. A similar question is coming: can an agent finish its task on this site? An agent that works by reading the screen is slow and error-prone; an agent that calls tools is fast and predictable. Once agents start choosing on the user's behalf, it is not hard to guess they will prefer the sites where they can get the job done easily.

My expectation: the rest of 2026 will be an experimentation period, and the API will change a few more times. The real turning point comes when an agent with millions of users, like Gemini in Chrome, starts actually calling these tools. When that day comes, the sites that already annotated their forms will be ready.

The cheapest step you can take today is adding toolname and tooldescription to your one or two most important forms. If the browser does not support it, nothing changes; the day it does, your site starts talking to agents.

On this site

After writing this I did the same on this site. In a browser with WebMCP, necatidogrul.dev now offers five tools:

get_profile: who I am, contact details and links
list_ios_apps: my apps on the App Store
list_writing: notes and case studies, filterable by tag
read_writing: the full text of one piece
go_to_section: scrolls the page to a given section

The site has no forms, so I used the imperative API rather than the declarative one. The first four tools carry readOnlyHint and only read; the fifth changes what is on screen but does nothing irreversible. I wrote no new backend: the tools live in one client component and draw on data the site already had. Last month's Markdown twins paid off here, since read_writing returns them directly. In a browser without WebMCP the component does nothing.

I tested it in Chrome 152: getTools() lists all five tools and each returns the expected answer through executeTool(). To try it, enable chrome://flags/#enable-webmcp-testing and type await document.modelContext.getTools() in the console on this page.