WebMCP Explained: Letting AI Agents Use Your Website's Forms (2026)

AI assistants are starting to do things on websites, not just read them: fill in a quote form, search for availability, check a domain name. Today most of them do it the hard way. They look at the page, guess which box is which, and click, which is slow and often wrong.

WebMCP is a proposed web standard that lets your website tell an AI agent in the browser exactly what a form does and what each field means. This guide explains how it works, where it stands in 2026, and how we have applied it to our own quote form and domain checker, including the safety choices a business should make.

What WebMCP is

Google’s documentation describes WebMCP as “a proposed web standard to help you build and expose structured tools for AI agents”. In practice, a web page can declare its own tools, such as “request a quote” or “check availability”, with a name, a description and a clear list of inputs. An AI agent running in the browser can then call that tool directly instead of guessing its way through the page.

The name comes from MCP, the Model Context Protocol, a common way of connecting tools to AI assistants. An MCP server runs on a server. WebMCP brings the same idea into the web page itself, so the browser acts as the go-between.

Where the standard stands

What	Status, as checked on 25 September 2026
The specification	A Draft Community Group Report of the W3C Web Machine Learning Community Group, dated 17 September 2026. It states it is not a W3C Standard and not on the W3C Standards Track.
Who writes it	Editors from Microsoft (Brandon Walderman) and Google (Khushal Sagar and Dominic Farolino).
Where it runs	Chrome, as an origin trial from Chrome 149. A site registers for the trial to switch it on for its visitors.
Testing	A Chrome flag (chrome://flags/#enable-webmcp-testing) and a Model Context Tool Inspector extension for developers.
Other browsers	We found no other browser shipping it.

In short: it is early, it is real, and it can still change. Google’s own documentation says the API is “under active discussion and subject to change”.

Two ways to add it

WebMCP has two APIs:

• The imperative API is JavaScript. A developer registers a tool with a name, a description, an input schema and a function that runs when an agent calls it. It suits web applications with complex actions.
• The declarative API is plain HTML. You add a few attributes to a form you already have, and the browser turns the form into a tool. It suits most business websites, because most business websites already express their actions as forms.

The declarative API, attribute by attribute

On the <form> element:

• toolname names the tool. Google’s advice is to “clearly name the tool, based on its purpose”.
• tooldescription explains what the tool does and why.
• toolautosubmit (optional) lets the form submit itself when an agent calls it. Without it, Google’s documentation is clear: “the user must manually click Submit to complete the task.”

On each field:

• toolparamdescription describes the field to the agent. Without it, the browser falls back to the field’s label or its aria-description, which is one more reason every field should have a proper label.

The browser builds the tool’s inputs from the form itself. Text fields become text inputs, required fields are marked as required, and a dropdown becomes a fixed list of allowed values taken from its options.

A simplified version of our own domain checker looks like this:

<form toolname="check_domain_availability"
      tooldescription="Check whether a domain name is available to register."
      toolautosubmit>
  <input name="domain"
         toolparamdescription="The domain name to check, for example yourbusiness.co.za">
  <button type="submit">Check availability</button>
</form>

Knowing when an agent is involved

WebMCP also tells the page when an agent is at work:

• A submit event carries agentInvoked, which is true when an AI agent triggered it.
• respondWith() lets a form hand its result straight back to the agent, instead of the agent having to read the page afterwards.
• The browser fires a toolactivated event after an agent has filled in a form, and a toolcancel event if the person cancels.
• Two CSS states, :tool-form-active and :tool-submit-active, let you show visually that an agent is filling in the form.

Safety: what an agent should and should not do

This is where most of the thinking should go. Letting software act on a person’s behalf is useful, and it needs limits.

Only auto-submit harmless actions. A lookup that changes nothing, such as a search or an availability check, is safe to auto-submit. Anything that sends a message, books a slot, makes a payment or signs someone up should leave out toolautosubmit, so the person reviews what the agent filled in and presses the button themselves.

Check your spam protection. Many forms use a hidden “honeypot” field that real people never see and bots fill in. Our testing confirmed that an agent sees that field as one of the form’s inputs. On our site a filled honeypot quietly discards the enquiry, so an agent could have lost a genuine lead without anyone knowing. We describe the field as “leave this empty”, and clear it when the browser reports that an agent has filled in the form.

Keep consent with the person. If a form asks for consent, for example to process personal information, that is a decision for the person, not something an agent should tick on their behalf. Leaving out auto-submit keeps them in the loop.

Mark agent-assisted enquiries. When an agent helps fill in our quote form, the enquiry is tagged as agent-assisted, so we can see how often it happens and reply accordingly.

How we have applied it on jwd.co.za

Form	What an agent can do	Auto-submit
Domain checker	Check a domain and receive the result directly, including the registrar and expiry date for a taken name	Yes (read only)
Quote request	Fill in the request with a description for every field	No (person sends)

We also publish our public tools in an AI catalog, so agents can discover them without visiting the page first.

What we found when we tested it (25 September 2026)

We tested both forms on the live site in Google Chrome 153 on Windows, and with Lighthouse 13.5.0 and PageSpeed Insights. Everything below was observed, not assumed. Our first attempt did not work, and why it failed is the most useful part.

First attempt: the token was ignored

We registered for Chrome’s WebMCP origin trial and put the token in a <meta http-equiv="origin-trial"> tag on every page, the way most origin trials are enabled. WebMCP stayed switched off. PageSpeed marked all three of its WebMCP checks “not applicable”, and a third-party checker extension scored the site 0.

How we found the cause: Chrome’s DevTools Protocol can report the status of every origin trial token on a page (Page.getOriginTrials). Ours came back as “WrongOrigin”, although the origin in the token was exactly right. The reason: when we registered, the “third-party” option was ticked. Chrome only accepts a third-party token when a script file served from the token’s origin adds it to the page. The same token in a <meta> tag is rejected.

Why PageSpeed showed “not applicable”: Lighthouse, the engine behind PageSpeed, first checks whether document.modelContext or navigator.modelContext exists. If neither does, it marks all three WebMCP checks “not applicable”, whatever is on the page. With the token rejected, WebMCP never switched on, so there was nothing for it to find.

The fix, and what works now

• Inject the token from a script file on your own domain. We serve a tiny script from www.jwd.co.za that adds the token to the page. Chrome then reports the token as “Success” and the trial as “Enabled”, with no flags and no extensions.
• It must be a normal, blocking script, placed before the forms. With defer or async, the trial was enabled but the form tools were not registered, because the browser had already read the forms. We started by loading it only on the two pages with WebMCP forms. It now loads on every page, because it also registers two read-only tools that work anywhere on the site: one lists our packages and prices, and one checks domain availability. The file is about 2.5 KB and the browser caches it for a year, so the cost per page is small.
• Or register a first-party token. If “third-party” is left unticked when registering, the token should work in a <meta> tag. We have not tested that route ourselves.

After the fix, PageSpeed Insights scored our form pages 6 out of 6 for Agentic Browsing, on mobile and desktop, with the three WebMCP checks passing: tools registered, schemas valid and form coverage.

What the tools do

Chrome builds the tools from the HTML exactly as documented. In Chrome 153 the tools appear on document.modelContext, which offers getTools(), executeTool() and registerTool(). Both of our forms appeared with the names, descriptions and field descriptions we wrote. Required fields were marked required, and each dropdown became a fixed list of its options.

The domain checker returned its answer straight to the agent. When the tool was run with “jwd.co.za”, the agent received the result as data (taken, the registrar and the expiry date), and the page showed the same result. That is respondWith() doing its job.

The quote form waited for a person. When an agent filled in the quote form, the name, email, service and message fields were filled, the toolactivated event fired, and the tool then waited. Nothing was sent, because the form has no toolautosubmit.

Hidden spam-trap fields are exposed to agents. This is the finding most worth knowing. Our honeypot field, hidden from people with CSS, appeared in the tool’s inputs like any other field, and when our test agent supplied a value for it, the form accepted it. Whether a real AI agent would choose to fill it depends on the agent, but nothing stops it. On most websites a filled honeypot silently discards the enquiry. Our guard cleared it when toolactivated fired and tagged the enquiry as agent-assisted, which is exactly what happened. If your forms use a honeypot, check this before you add WebMCP.

Documentation and browser differ. Several guides, and at least one checker extension, look for navigator.modelContext. In Chrome 153 the object is on document. Our token script also points navigator.modelContext at the same object, so tools written either way find it. Test against the browser, not the article.

How it relates to ai-catalog.json and llms.txt

These three do different jobs:

• llms.txt helps language models read your content. See our llms.txt guide.
• ai-catalog.json helps agents discover the tools you offer, from anywhere. See our ai-catalog.json guide.
• WebMCP helps an agent use a tool correctly while it is on your page.

Google’s PageSpeed Insights now groups all three in an “Agentic Browsing” category, including three WebMCP checks: form coverage, registered tools and schema validity. Most sites see those as not applicable for now.

Should your business add WebMCP now?

If your site’s main actions are forms, such as quote requests, bookings, availability searches or product finders, the declarative API costs very little to add and does nothing to ordinary visitors. It is a sensible thing to prepare, especially on a new build.

Keep expectations honest. It is a draft standard in one browser’s trial, and it is not a search ranking factor. What it can do is make your forms easier for the AI assistants of the near future to use correctly, and that is worth getting right early. Our agent-ready website checklist puts it in context with everything else a website needs.

If you would like your forms made agent-ready, request a quote and tell us what your forms do.

Frequently Asked Questions

What is WebMCP?

WebMCP is a proposed web standard that lets a website describe its own tools, such as forms and actions, to AI agents running in the browser. The agent can then use the tool directly instead of guessing its way through the page.

Is WebMCP an official web standard?

Not yet. As of 25 September 2026 it is a Draft Community Group Report of the W3C Web Machine Learning Community Group, and it states that it is not on the W3C Standards Track. Chrome runs it as an origin trial from Chrome 149.

Do I need to know JavaScript to add WebMCP?

Not for the declarative API. You add toolname, tooldescription and toolparamdescription attributes to your existing HTML forms. The JavaScript API is for more complex web applications.

Will an AI agent submit my contact form without the person knowing?

Only if you add toolautosubmit. Without it, the agent fills in the form and the person must press Submit. For any form that sends a message, books or pays, leave auto-submit off.

Does WebMCP help my Google ranking?

There is no evidence that it does. It is about letting AI agents use your website correctly, not about where your pages rank.