What is WebMCP, and how to track which websites adopt it

WebMCP is a proposed browser API through which a web page offers its own actions, such as a booking or a quote request, to AI agents as named tools. This post explains what it is, who develops it and how far the work has come, shows both of its forms in code, and sets it beside the Model Context Protocol. It then turns to the reader who follows companies rather than builds websites: after it you can recognise WebMCP in a site's markup and scripts, date its adoption, and say what the adoption suggests about the company behind the site.

What WebMCP is

A WebMCP tool has four parts: a name, a description in plain language, an input schema written in JSON Schema, and the code that carries it out. An agent working in the browser reads the tools a page has registered and calls one with structured arguments, in place of reading the screen and clicking through the interface. The explainer in the project's repository states the aim as agents that work on a site through well-defined tools in the page rather than through simulated clicks, and lists among its goals tasks that a person hands to an agent while keeping sight and control of the page.

The specification is published by the Web Machine Learning Community Group at the W3C. Its published draft names four editors, two from Microsoft and two from Google, and the explainer credits authors at both companies and gives its first publication as 13 August 2025. Chrome's WebMCP documentation covers both forms of the API and the trial in which Chrome runs it.

Three primary pages state how mature it is, and they agree.

Read together, the three place WebMCP at the incubation stage: a draft with two browser makers behind it and a trial running in Chrome, without standing as a W3C standard. For a reader of company data that stage matters, because a company that ships WebMCP today ships it ahead of any standard.

The two forms: declarative and imperative

Chrome's early preview announcement of 10 February 2026 introduced two APIs: a declarative one built on HTML forms for routine actions, and an imperative one in JavaScript for more dynamic work. Both remain, with different standing. The published draft specifies the imperative API. The declarative form is described in a separate explainer in the same repository, which the README places outside the specification for now, and Chrome documents both for its trial.

The declarative form: attributes on an HTML form

Chrome's declarative API page turns an ordinary form into a tool with a handful of attributes.

• toolname on the form names the tool, and tooldescription says what it does. Removing either attribute unregisters the tool.
• toolautosubmit on the form lets the agent submit it. Without it, the browser fills in the fields and the person presses the submit button.
• toolparamdescription on a field describes that input. Without it the browser uses the field's label. The field's existing name becomes the property name in the tool's schema.

When an agent calls the tool, the browser focuses the form and fills it in while it stays in view. The submit event carries an agentInvoked flag, so the page can tell an agent's submission from a person's, and a page that calls preventDefault can return a result to the agent with respondWith instead of navigating away.

For Acme Robotics, an invented maker of welding cells, a quote form offered to agents could read as follows. The example is illustrative.

<form toolname="request_quote"
      tooldescription="Request a price quote for an Acme Robotics welding cell."
      action="/quotes" method="post">
  <label for="model">Model</label>
  <select id="model" name="model" required
          toolparamdescription="The welding cell to quote: AR-200 for light gauge, AR-400 for heavy gauge.">
    <option value="AR-200">AR-200</option>
    <option value="AR-400">AR-400</option>
  </select>
  <label for="units">Units</label>
  <input id="units" name="units" type="number" min="1" required>
  <label for="country">Country of installation</label>
  <input id="country" name="country" type="text" required>
  <button type="submit">Request quote</button>
</form>

The form leaves out toolautosubmit, so an agent prepares the request and the person sends it. For a quote that commits a sales team to a reply, that is the usual choice.

The imperative form: a tool registered in JavaScript

Chrome's imperative API page and the published draft define the object as document.modelContext, with three methods: registerTool adds a tool, getTools lists the tools open to the calling document, and executeTool runs one. A tool is withdrawn by aborting the signal passed when it was registered. Optional annotations tell the agent what kind of tool it is: readOnlyHint for one that changes nothing, consequentialHint for one with real-world or irreversible effects, so that an agent or browser can ask the person to confirm first, and untrustedContentHint for output that carries content the author does not control. Registration inside a cross-origin frame needs the tools permission delegated by the page that embeds it.

The same company could offer demonstration bookings in script. The example is illustrative.

const demos = new AbortController();

await document.modelContext.registerTool({
  name: 'book_demo',
  description: 'Book a live demonstration of an Acme Robotics welding cell.',
  inputSchema: {
    type: 'object',
    properties: {
      model: { type: 'string', enum: ['AR-200', 'AR-400'] },
      date: { type: 'string', description: 'Preferred date, as YYYY-MM-DD.' },
      city: { type: 'string', description: 'City of the plant to visit.' },
    },
    required: ['model', 'date'],
  },
  annotations: { consequentialHint: true },
  execute: async ({ model, date, city }) => {
    const slot = await reserveDemo({ model, date, city });
    return `Demonstration of ${model} booked for ${slot.date}, reference ${slot.id}.`;
  },
}, { signal: demos.signal });

// When the demonstration calendar is full, withdraw the tool.
demos.abort();

The object has moved once. Early drafts placed it on navigator, and in May 2026 the editors moved it to the document on the advice of the W3C Technical Architecture Group, so that tools belong to the page that registers them (issue 173 in the repository). A later change to the repository's examples records that the provideContext method of the early drafts is gone from the specification. Scripts written for the early preview, and many guides, still show navigator.modelContext, so anyone reading a site's code should look for both names.

How WebMCP differs from the Model Context Protocol

The Model Context Protocol is an open-source standard that lets AI applications reach data, tools and workflows outside themselves. In its architecture, an AI application acting as host opens one client connection per server, and a server is a program that runs locally over standard input and output or remotely over Streamable HTTP, offering tools, resources and prompts in JSON-RPC 2.0 messages. WebMCP borrows the vocabulary. Its explainer describes a page that uses it as an in-page MCP server whose tools run in client-side code, and presents it as an addition to backend protocols such as MCP rather than a substitute for them.

The explainer lists fully autonomous use, where no browser interface is present, among its non-goals. That is the practical line between the two. A company can run an MCP server for agents that work away from its site, such as an assistant pulling data through an account, and offer WebMCP tools for an agent working beside a person on the site itself. The guide to serving company data to AI agents over Model Context Protocol shows the server side.

Which browsers support WebMCP

Each row below is stated as the browser maker's own page states it.

An origin trial lets a site switch a feature on for its own visitors: the site registers, receives a token and serves it in a meta tag or a response header, and the feature then works without the visitor touching a flag. Chrome's guide warns that a feature can change as feedback comes in, and WebMCP has already changed: the object moved from navigator to document, and provideContext was dropped. Chrome Platform Status lists no release milestone, so outside the origin trial and local testing, Chrome leaves the API off.

For a reader of company data, the code in a page is the evidence, whatever browser a visitor uses. A form with a tool name or a script that registers a tool is visible in the page whether or not the visitor's browser runs it.

What adopting WebMCP says about a company

A WebMCP tool is a small piece of work with a large signal behind it. Someone at the company chose which actions an agent may take, named them, described them and decided how much the agent may do alone. Four readings follow.

1. A decision made ahead of the standard. The draft is at incubation and Chrome runs a trial, and the API has already changed shape. A company that ships WebMCP has chosen to build on a moving target, which usually means a front-end team that follows Chrome's trials and the browser platform closely.
2. Where it expects agents to act. Chrome's early preview announcement names customer support, ecommerce checkout and travel booking as the uses in view. Tool names show which of these a company has in mind: a tool that requests a quote or books a demonstration points at a sales flow prepared for agent-driven buyers, a support form points at service, and a site search tool points at discovery.
3. How far it lets an agent go. A form without toolautosubmit, or a tool marked consequential, keeps the person in the loop. An auto-submitting form hands the whole step to the agent. The choice shows how the company weighs speed against control.
4. What the signal leaves open. A tool can come from a plugin or a platform the site runs as well as from the company's own engineers, so read the tool names and the script that registers them before reading engineering depth into an adoption. A detection shows presence on the website: it says nothing of how often agents call the tools or what they bring in.

Taken with the company's other signals, an adoption adds weight to a view of investment in AI. The overview of AI readiness signals from company websites sets WebMCP beside the crawler rules, content signals and llms.txt files of the same websites.

How to find WebMCP adopters in company data

The evidence sits in two places in a website: the markup, where a form carries a toolname attribute, and the scripts, where a call registers a tool with the browser's model context under either object name. For one site, viewing the page source and its scripts shows both, and Chrome's DevTools has a WebMCP pane in its Application panel that lists the tools detected on the open tab, declarative and imperative.

Across many companies, technographic data does the reading. In the marketing stack dataset, Technology Stack lists the entry WebMCP tools for AI agents, in the category Artificial intelligence, among 6,298 recognised technologies in 69 categories. Each row carries its first-seen and last-seen dates and the kind of evidence that showed it. Technology Changes holds a dated event for every addition and every removal, and the first reading of a website sets a baseline that is never counted as a change, so every addition event marks an adoption observed to happen.

Two queries on a sample give the current adopters and the dated changes.

select company, domain, first_seen_at, last_seen_at, seen_via
from company_technologies
where technology_name = 'WebMCP tools for AI agents'
  and missing_since is null
order by first_seen_at;

select company, change, observed_at
from company_tech_events
where technology_name = 'WebMCP tools for AI agents'
  and change in ('added', 'removed')
order by observed_at;

The signal follows the code, and so does its limit. A tool lives in a form or a script on a particular page, and a site may offer one only after sign-in or deep in a booking flow. Tools also come and go with the state of the page, since a site can withdraw one at any moment. Read a present entry as a tool offered, and a missing one as no tool seen.

For the account view, the intent dataset gives a weekly score on the topic AI and machine learning in Intent Scores, each with the dated evidence behind it. For the market view, the weekly Market Series carry the technologies added and removed and the prevalence of each technology per 100 websites of a same-store cohort, WebMCP among them. The methodology describes this group of entries in section 5.1, and its neighbours have their own guides: what llms.txt is and blocking AI crawlers in robots.txt.

Example: dating Acme Robotics' adoption

The example is illustrative: Acme Robotics is invented, and its dates show how to read the record.

The working:

• The adoption falls between the last observation before 7 October and 7 October itself. The event dates it to that window.
• Had the form been in place on 23 September, the entry would carry the baseline's first-seen date and no event, and the adoption could be dated only as before 23 September.
• The entry records that the site offers tools to agents. The page shows which: opening it finds the quote form, a declarative tool, and its name and description say what an agent may do there.

For a team selling agent-ready commerce or support software, the October event is the trigger. For an analyst tracking AI investment across a sector, it is one dated observation to set against the company's hiring and announcements.

Frequently asked questions

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.