WebMCP is a proposed web standard, driven by Google and Microsoft inside the W3C, that lets a website describe its forms and functions as tools an AI agent running in the browser can call. Instead of an agent guessing which button to click by staring at pixels, the page tells it: this form requests a software audit, here is what each field means, fill it in and hand control back to the human. As of September 2026 it ships in Chrome behind an origin trial, the only agent consuming it is Gemini in Chrome, and it does nothing for your Google rankings. We added it to wearefabbrik.com anyway. This post explains what it is, what we changed, and how to decide whether your site needs it yet.
What is WebMCP, in plain terms?
Model Context Protocol (MCP) is the standard that lets an AI model call a backend service through a defined set of tools. WebMCP takes that idea and moves it into the page. A website becomes an in-page MCP server: it exposes client-side actions, the browser mediates access, and an agent that the user has invited (today, the one built into Chrome) can discover and call those actions while the user watches.
There are two ways to expose a tool, and the WebMCP explainer describes both.
The declarative API is a handful of HTML attributes on a form you already have:
<form toolname="request-free-software-audit"
tooldescription="Request a free software audit from WeAreFabbrik. A senior engineer reviews the codebase and replies within 24 hours.">
<input name="name" toolparamdescription="The user's full name" required>
<input name="email" toolparamdescription="The user's work email address" required>
<textarea name="details"
toolparamdescription="Tech stack, rough size and age of the codebase, and what worries the user most"></textarea>
<button type="submit">Request my free audit</button>
</form>
The browser turns that into a tool definition with a JSON schema derived from the form controls. No JavaScript, no build step. If you leave off the toolautosubmit attribute, the agent fills the form and then focuses the submit button so the human checks it and clicks. That default matters, and we kept it.
The imperative API is for anything that isn't a form. You register a tool from JavaScript with a name, a description, an input schema, and an execute function:
await document.modelContext.registerTool({
name: "check-availability",
description: "Check whether a 30-minute intro call slot is free",
inputSchema: {
type: "object",
properties: { date: { type: "string", description: "ISO date" } },
required: ["date"]
},
async execute({ date }) {
const slots = await fetchSlots(date);
return { content: [{ type: "text", text: JSON.stringify(slots) }] };
}
});
If that looks like an MCP server definition, that is the point. The same mental model, running in the tab.
Where does WebMCP stand in September 2026?
Honest status, because most of the coverage right now is written by people selling WebMCP checkers.
| Question | Status |
|---|---|
| Which browsers implement it? | Chrome only. Shipped as an early preview in Chrome 146 in February 2026, now in a public origin trial. Edge has it behind a flag. |
| Is the API stable? | No. The entry point moved from navigator.modelContext to document.modelContext over the summer. The old name is a deprecated alias. |
| Firefox and Safari? | Participating in the spec discussion. No shipping commitment from either. |
| Which agents can call the tools? | In practice, Gemini in Chrome. Extensions can too, but no mainstream assistant outside Chrome reads WebMCP tools today. |
| Does it need a server change? | No. It is entirely client-side. |
The Chrome team's announcement frames it as early preview, and the state-of-WebMCP writeups from July put the origin trial at Chrome 149 through 156. Treat the details as moving. Treat the direction as settled: browsers are going to give agents a structured way to use pages, and this is the proposal with two browser vendors behind it.
Does WebMCP help SEO or AI search visibility?
No, and this is the part worth being clear about because it is where the hype goes wrong.
WebMCP is a runtime browser API. Googlebot does not execute it. ChatGPT, Perplexity, and Claude do not see it when they cite your site. It has no effect on whether your page ranks, gets pulled into an AI Overview, or gets quoted by a chat assistant. Those outcomes still depend on the boring things: clear content, structured data, a sane robots.txt, an llms.txt if you want to be helpful to crawlers, and pages that render without a client-side round trip.
What WebMCP changes is what happens after a human has already landed on your page with an agent in tow. It turns "find the contact form and fill it in for me" from a screen-scraping guess into a defined tool call with a schema. That is a conversion and accessibility feature, not a discovery feature. If someone tells you WebMCP will get you cited by AI, they are confusing two different layers of the stack.
What did we actually change on wearefabbrik.com?
We have two forms that matter: the contact form and the free software audit request. Everything else on the site is content, and agents already read content fine. So the whole change was about forty lines, and three of them taught us something.
We used the declarative API only. Both forms got a toolname, a tooldescription, and a toolparamdescription on every field. We did not add toolautosubmit. An agent can fill in the audit request on your behalf, but you click send. For a lead form that is the right trade: the cost of an agent hallucinating a budget field and firing it off is higher than the cost of one extra click.
We told the agent about the honeypot. Like most forms, ours have an invisible anti-spam field that must stay empty. A human never sees it. An agent reading the form's schema does. Without guidance it might helpfully fill it in, the server would silently drop the submission as spam, and everyone would think it worked. So the hidden field now carries toolparamdescription="Anti-spam field. Must be left empty.". If you run a honeypot and add WebMCP, do the same or remove the field from the tool.
We read the form from the DOM at submit time. Our site is React with controlled inputs, meaning field values live in component state and update through change events. An agent filling controls programmatically may not fire those events the way a keyboard does. Rather than bet on how a given browser dispatches them, the submit handler now reads the current values straight out of the form element and merges them over state. It is a one-line FormData read that also makes the form more robust to browser autofill and password managers, which have the same problem.
We answer the agent. The declarative API adds a respondWith() method to the submit event, so the page can hand a structured result back to the agent that invoked it. Ours returns a short text: "Audit request received. WeAreFabbrik replies within 24 hours to set up repository access." Or the failure case, which tells the agent to have the user email us directly. It is feature-detected, so in every other browser it is a no-op.
We tagged agent submissions in analytics. The submit event also carries an agentInvoked flag. We pass it through to our conversion event, so if agent-driven leads ever become a real number we will see it rather than guess.
You can verify the whole thing without a Chrome build. The site is statically prerendered, so the attributes are in the HTML:
curl -s https://wearefabbrik.com/free-audit | grep -o 'toolname="[^"]*"'
Does a business website need WebMCP right now?
Here is the decision as we would give it to a client, split by what kind of site you run.
You have transactional forms or a booking flow. Add the declarative attributes now. The cost is an afternoon, there is no runtime cost, it fails silently in every browser that lacks it, and you get to be one of the first sites in your category an agent can actually use. Keep toolautosubmit off anything that creates a commitment. Describe your honeypot. Read from the DOM on submit.
You run a brochure site with a contact form. Do it if you have a developer who can make the change in an hour. Do not pay an agency a retainer for it. The lead form is the only thing worth exposing.
You sell to buyers who live in Chrome and use Gemini. That is a real audience already, and it will grow as the origin trial widens. If your customers are IT-adjacent or in marketing, a noticeable share of them are in it.
You have no forms and no dynamic actions. Skip it. There is nothing to expose. Spend the afternoon on structured data and page speed instead, because those still move discovery.
For German-speaking clients asking about an "agentenfähige Website": the answer is the same. The formal approach for making a site usable by agents is WebMCP, the German search term for it does not exist yet, and the work is small enough that the decision should be about whether you have forms, not about budget.
What would change our recommendation?
Three things, and we will update this post when any of them happens.
- A second browser ships it. Firefox or Safari implementing
document.modelContextmoves this from a Chrome feature to a web feature. - A non-Chrome agent starts consuming it. If Claude, ChatGPT, or an enterprise agent platform reads WebMCP tools from a live tab, the audience stops being tied to one browser.
- The imperative API stabilises. Once the rename churn settles, exposing richer actions such as availability lookups or quote calculators becomes worth the maintenance.
Until then WebMCP is a cheap, low-risk bet on where the platform is going. That is exactly the kind of bet a small studio should make early, because being early is the only advantage a small studio has. It is also the kind of change we look for in the free software audit: small, well-understood moves that put a codebase ahead of where the platform is heading, rather than big rewrites chasing a headline. An agent can now fill that request in for you. You still get to press the button.