WebMCP beta
W3C Community Group draft · scored as criterion F2
WebMCP (Web Model Context Protocol) is a proposed browser API that lets a page hand an in-browser AI agent a set of structured, callable tools — search, filter, submit a support request — instead of making that agent read pixels and guess which button to click. It is developed in the W3C Web Machine Learning Community Group, with Google and Microsoft engineers among its authors. AgentFit checks whether a documentation site actually ships WebMCP and scores it as criterion F2.
What WebMCP actually is today
Be precise about the status, because most write-ups are not: WebMCP is a
Community Group draft report — not a W3C Recommendation,
not a shipped web platform feature. Chrome exposes it behind an opt-in
origin trial (Chrome 149, since May 2026, and behind a flag in Canary
before that). Firefox and Safari have no implementation. The API surface is
still moving: a March 2026 revision removed the provideContext
and clearContext methods outright. Anything built against it
today is an experiment with a migration ahead of it.
That is also why WebMCP is worth exactly 1 point out of 100 in our rubric. It is a real, checkable signal that a team is thinking about agents — not a baseline expectation, and not a reason to reorganise your documentation.
The two ways to adopt it
Declarative — annotated HTML forms
Add toolname and tooldescription to a form you
already have (optionally toolparamdescription /
toolparamtitle per field, and the boolean
toolautosubmit). No JavaScript, and it degrades to an ordinary
form in every browser that has never heard of WebMCP:
<form toolname="search_docs"
tooldescription="Search the API documentation"
toolautosubmit>
<input name="q" toolparamdescription="Search query" required>
<button type="submit">Search</button>
</form>
This is what agentfit.dev itself ships: the audit box on our homepage is a
real form carrying toolname="audit", so an agent already in the
tab can invoke it directly.
Imperative — JavaScript
Register tools at runtime with a JSON Schema and an execute handler:
navigator.modelContext.registerTool({
name: 'search_docs',
description: 'Search the documentation',
inputSchema: { type: 'object', properties: { q: { type: 'string' } }, required: ['q'] },
execute: async ({ q }) => { /* ... */ },
});
How AgentFit detects it — and why we scan the DOM, not the page source
AgentFit audits documentation sites, and documentation sites are
exactly the sites that print navigator.modelContext inside a
tutorial. A naive substring search over the raw HTML body would flag every
page that merely explains the API as a page that
implements it — including this one. So detection runs against the
parsed DOM:
- Declarative — an attribute-exists selector for an
element carrying both
toolnameandtooldescription, with a non-emptytoolname(an empty value is scaffolding, not a tool). A live attribute cannot be created by typing it inside a code block: the parser treats the block's contents as text, so this path is structurally immune to the false positive. - Imperative — only the text content of
<script>elements, never<pre><code>. A primary token (navigator.modelContext, or the'modelContext' in navigatorfeature test) is required to claim detection.registerTool()alone is demoted to a corroborating token, because unrelated server-side MCP SDKs use that method name. - Polyfill —
@mcp-borwebmcp-polyfillin a<script src>or an inline script.
When the declarative API is detected, every candidate tool form is then
checked against Chrome's form rules — a missing toolname or
tooldescription, a required input with no name, an
optional parameter with no description — and the violations are reported in
the audit diagnostics.
Limits, stated plainly. We do not execute the page's
JavaScript and we do not download external bundles, so imperative
registration that lives only inside a shipped .js file is
invisible to us. We scan the homepage and one sampled documentation page,
not the whole site.
WebMCP versus a remote MCP server
They are siblings, not alternatives, and most teams that need one do not need the other.
| WebMCP | Remote MCP server | |
|---|---|---|
| Where it runs | In the user's browser tab | On your infrastructure |
| Lifetime | Ephemeral — while the page is open | Persistent HTTPS endpoint |
| Authentication | The user's existing session | OAuth 2.1, audience-bound tokens |
| Transport | In-page JS API | JSON-RPC over Streamable HTTP |
| Discovery | Page markup | .well-known metadata |
| Who can call it | An agent driving that browser | Any MCP client |
| Spec status | CG draft, origin trial | Published, versioned revisions |
| AgentFit criterion | F2 — 1 point | F3 — 3 points |
Checking the server side instead? See MCP server check.
How rare is it, actually
Corpus snapshot of 27 July 2026, measured under rubric v3 and currently being re-measured under v4. The counts below are surface detections, which v4 did not change; the site scores they sit alongside did.
Across the 5,827 sites with a valid AgentFit run as of 27 July 2026, WebMCP was detected on 7 — about 0.12%. Our own documentation is no longer in that count, or in the population: since issue #21 the domains we own are out of every corpus statistic. One of the seven is still not adoption — a browser-vendor demo of the polyfill. That leaves six production sites — developer.nylas.com, phish.in, razorpay.com, render.com, telnyx.com and www.rainviewer.com. For comparison, a remote MCP server was found on 2.08% of the same population.
WebMCP is also the only agent surface in this audit that no documentation
platform provisions for its customers. Mintlify ships an MCP server card to
190 of its 203 sites in the corpus; GitBook ships auth.md to
225 of 234; ReadMe advertises an MCP server for 75 of 276. Every WebMCP
deployment we have seen was hand-built. Whatever those seven sites are
doing, somebody decided to do it.
Five of the seven use the imperative JavaScript API only; two carry declarative tool markup, and one of those two is the polyfill demo. F2 does not distinguish the three paths — any detected surface scores the same point. The declarative form is simply the one an outside auditor can verify from static HTML without executing the page.
How it is scored
- 1 point — WebMCP detected, in any of the three forms.
- 0 points — homepage scanned, nothing found.
- 0 points, reported as an error — no scannable DOM (the homepage did not return parseable HTML). That is a fact about our probe, not about your site, and it is reported differently from a genuine absence.
F2 sits in category F. Agent capability (4 points of 100) alongside F3. Full rubric: 28 criteria, six categories.
Adding WebMCP to your docs
- Pick the one or two actions an agent would actually want: search, a code sample in a given language, "open this endpoint in the API explorer".
- Annotate the form you already have. Give every input a
nameand atoolparamdescription— that description is the agent's only documentation for the field. - Write the
tooldescriptionfor a reader who cannot see the page. "Search the API documentation" beats "Search". - Add
toolautosubmitonly where an accidental invocation is cheap and reversible. Never to anything that charges, deletes or notifies somebody. Our own homepage form is autosubmit: it starts a free audit and spends one rate-limit slot, which is roughly the upper bound of what we think belongs behind it. - Re-audit and confirm F2 turned green.
FAQ
Is WebMCP a web standard?
No. It is a W3C Community Group draft report, available in Chrome as an opt-in origin trial and unimplemented in Firefox and Safari. Treat it as an experiment, not a baseline expectation.
Do I need WebMCP if I already run an MCP server?
No. An MCP server serves any client from your backend over OAuth; WebMCP serves an agent that is already in the user's tab, using that user's session. They solve different problems and AgentFit scores them separately, as F3 and F2.
Will AgentFit flag my page just for documenting WebMCP?
No. Detection reads live DOM attributes and the text content of script elements. Code shown inside a fenced code block is text to the HTML parser, so a page that merely explains the API cannot be misreported as implementing it — this page included.
I ship WebMCP but AgentFit did not detect it. Why?
Most likely the registration lives in an external JavaScript bundle: we do not execute page scripts and we do not fetch bundles. Inline the registration, or ship an annotated form. Also check that the page we scanned carries the tools — we look at the homepage and one sampled documentation page.
Does WebMCP expose my site to prompt injection?
It changes the shape of the risk rather than removing it. Tools run with the user's live session, so scope them narrowly, keep toolautosubmit off anything with side effects, and validate on the server exactly as you would for a form a human submits.
How many sites actually ship WebMCP?
Seven of the 5,827 sites with a valid AgentFit run as of 27 July 2026 — about 0.12%. One of those is not adoption: a browser-vendor demo of the polyfill. A remote MCP server was found on 2.08% of the same population.
Is it worth doing for a documentation site?
For one search form, yes — it is an afternoon's work and it degrades gracefully. As a reason to rebuild your docs, no. It is 1 point of 100, and that is deliberate.
Free, no sign-up, about 30 seconds. You get all 28 criteria with HTTP evidence and a shareable report link.