What is the difference between WebMCP and MCP?

MCP (Model Context Protocol) connects a model to external tool servers over a separate process, usually running on your machine or a remote host. WebMCP is a browser API: a page calls document.modelContext.registerTool (or declares a tool with a toolname form attribute) so an agent already looking at that page can call the tool directly, with no separate server to run. They solve a similar problem, giving a model something to call, from opposite ends: MCP starts from the tool side, WebMCP starts from the page the user is already on.

Does WebMCP have browser support beyond Chrome?

The only verified support at the time of writing is Chrome, and even there it isn't on by default: you either enable it via chrome://flags/#enable-webmcp-testing for local development or run it under the published origin trial (ID 4163014905550602241). WebMCP is incubating under the W3C Web Machine Learning group, and the spec itself is written for the web platform generally, but we have not verified support in Firefox, Safari, or any other engine, so this checker does not claim it.

Is there a WebMCP Chrome extension?

This checker only tests the native browser API described in Chrome's WebMCP docs: document.modelContext, registerTool, and the declarative form attributes, served directly by the page you point it at. We have not verified any specific browser extension that adds WebMCP support on top of that, so we are not going to name one here. If your workflow depends on an extension rather than the native API, this tool will not see it, because it only reads what the page itself serves.

WebMCP vs Playwright: how do they compare?

Playwright drives a browser from the outside: a separate script opens a page, clicks things, and reads the DOM, with no cooperation required from the site itself. WebMCP is the opposite arrangement, the page opts in and registers tools itself, so an agent that is already viewing the page can call them directly instead of being scripted from outside. Playwright can test or automate any site; WebMCP tools only exist on sites that chose to register them.

What are the WebMCP security considerations?

Three of the seven checks above exist because of this: WebMCP only works in a secure context, so plain http is out entirely. It requires an origin-isolated document (Origin-Agent-Cluster: ?1), which keeps the page in its own process. And it is gated by the tools Permissions Policy directive, the same mechanism that already gates camera or geolocation access, so a page (or an embedding iframe) can explicitly deny tool registration the way it can deny any other capability.

Back to Tools

WebMCP Ready Checker

Paste a URL. The WebMCP ready checker fetches it server-side and runs 7 weighted checks: origin isolation, the tools Permissions Policy directive, document.modelContext registration, and more. Then it scores the result 0-100 with a plain verdict: Ready, Partial, Not ready, or no signals.

Updated September 2, 2026 · By Jim Liu(verified against the Chrome WebMCP docs and the W3C incubation README)

What check #4 looks for

await document.modelContext.registerTool({
  name, description, inputSchema, execute
});

The single biggest check (30 points) is finding this call in your same-origin scripts.

TL;DR

7 weighted checks, one score. Secure context, origin isolation, the tools Permissions Policy directive, the current and declarative tool-registration forms, the older navigator.modelContext namespace, and description quality.
document.modelContext is current. navigator.modelContext still shows up in older docs and blog posts; a hit on it is a warning here, not a hard fail.
80+ is Ready, below 20 is no signals. 50-79 is Partial, 20-49 is Not ready.
It reads, it does not run JavaScript. A SPA that registers tools after hydration can score low here and still work fine in a real browser.

What this WebMCP ready checker actually tests

Each check is worth a fixed weight, and the two ways of registering a tool, the imperative document.modelContext.registerTool call and the declarative form toolname attribute, are treated as alternatives rather than added together, since a page only needs one to work.

Check	Weight	Source
Secure context (https)	10	Chrome WebMCP overview
Origin-isolated document (Origin-Agent-Cluster: ?1)	20	Chrome WebMCP overview
tools Permissions Policy directive not denied	15	Chrome imperative-api docs
document.modelContext.registerTool found	30 (alt.)	Chrome imperative-api docs
Declarative form toolname attribute found	20 (alt.)	Chrome declarative-api docs
No legacy navigator.modelContext (warning only)	15	webmachinelearning/webmcp README
Tool description over 15 characters	10	Chrome imperative-api docs

The checker fetches the page once, then up to 5 same-origin script files it finds in <script src> tags, capped at 512 KB and 5 seconds each, and searches the combined text for the imperative call, the legacy namespace, and a description string. It does not execute anything, so a tool registered by code inside a bundle chunk it did not fetch, or by a script that runs after your page hydrates, will not show up. The Limitations note above the score says the same thing in the result itself, because a low score here should read as "we could not see it from outside", not as a verdict on your code.

One thing this checker deliberately does not look at: an llms.txt file. The two are unrelated. llms.txt is a markdown file some sites publish for AI assistants to read as background text; WebMCP is a browser API that registers a callable tool. A site can have a well-formed llms.txt and zero WebMCP signals, or the reverse. If you want the llms.txt side checked, OpenAI Tools Hub runs a separate llms.txt checker that answers that different question.

document.modelContext vs the older navigator.modelContext

The WebMCP repository README states it plainly: "WebMCP introduces an imperative API on the web platform under document.modelContext." That is the namespace Chrome's own docs use for the current imperative and declarative APIs, and it is what this checker treats as a pass.

navigator.modelContext is not gone from the record: it still appears in the repo's docs/proposal.md and in issue #101, and more than one third-party writeup (including at least one competing checker's reference page) documents only that form. We could not verify a removal date for it, so this checker does not claim one. Hitting navigator.modelContext in your code gets a warning here, worth mentioning and worth migrating, but it does not zero out the rest of the score.

Example runs

These are real runs of the checker above, not invented numbers, and the middle one is an honest edge case: GitHub happens to embed a page's rendered code blocks inside an inline hydration script, so the checker's script-only scan for registerTool picks up documentation prose rather than a real tool registration. That is exactly the kind of false positive the Limitations note above is warning you about: a static scan reads what is technically there, not what a human would call "this site supports WebMCP."

developer.chrome.com/docs/ai/webmcp

Not ready

Secure, allows the tools directive, and does not carry the legacy namespace, but the API call lives in a rendered code block, not a script tag, so the checker cannot see it and origin isolation is off.

github.com/webmachinelearning/webmcp

Partial

The registerTool call shows up because GitHub embeds the page's code blocks in an inline hydration script, close enough together to match. That is a real false positive: it is documentation prose, not a real integration.

example.com

Not ready

Secure and allows the tools directive by default, but a static page with no script and no tool registration of any kind.

Frequently asked questions

What is the difference between WebMCP and MCP?: MCP (Model Context Protocol) connects a model to external tool servers over a separate process, usually running on your machine or a remote host. WebMCP is a browser API: a page calls document.modelContext.registerTool (or declares a tool with a toolname form attribute) so an agent already looking at that page can call the tool directly, with no separate server to run. They solve a similar problem, giving a model something to call, from opposite ends: MCP starts from the tool side, WebMCP starts from the page the user is already on.
Does WebMCP have browser support beyond Chrome?: The only verified support at the time of writing is Chrome, and even there it isn't on by default: you either enable it via chrome://flags/#enable-webmcp-testing for local development or run it under the published origin trial (ID 4163014905550602241). WebMCP is incubating under the W3C Web Machine Learning group, and the spec itself is written for the web platform generally, but we have not verified support in Firefox, Safari, or any other engine, so this checker does not claim it.
Is there a WebMCP Chrome extension?: This checker only tests the native browser API described in Chrome's WebMCP docs: document.modelContext, registerTool, and the declarative form attributes, served directly by the page you point it at. We have not verified any specific browser extension that adds WebMCP support on top of that, so we are not going to name one here. If your workflow depends on an extension rather than the native API, this tool will not see it, because it only reads what the page itself serves.
WebMCP vs Playwright: how do they compare?: Playwright drives a browser from the outside: a separate script opens a page, clicks things, and reads the DOM, with no cooperation required from the site itself. WebMCP is the opposite arrangement, the page opts in and registers tools itself, so an agent that is already viewing the page can call them directly instead of being scripted from outside. Playwright can test or automate any site; WebMCP tools only exist on sites that chose to register them.
What is WebMCP?: WebMCP is a browser API, incubating at the W3C under the Web Machine Learning group, that lets a web page register tools an AI agent can call while looking at that page. The imperative form is document.modelContext.registerTool({ name, description, inputSchema, execute }); the declarative form marks up a form with a toolname attribute instead. It only works in a secure context (https) and in an origin-isolated document, and it is gated behind a tools Permissions Policy directive.
What are the WebMCP security considerations?: Three of the seven checks above exist because of this: WebMCP only works in a secure context, so plain http is out entirely. It requires an origin-isolated document (Origin-Agent-Cluster: ?1), which keeps the page in its own process. And it is gated by the tools Permissions Policy directive, the same mechanism that already gates camera or geolocation access, so a page (or an embedding iframe) can explicitly deny tool registration the way it can deny any other capability.

More MCP setup guides on OpenAI Tools Hub

MCP server boilerplate generator: scaffold a starter server Claude Code MCP config generator (~/.claude.json)Chrome DevTools MCP setup: config generator MCP vs A2A protocol: when to use each

Related reading: WebMCP: Chrome turns websites into AI agent tools covers the announcement and why it matters. Check specific version and rollout claims against the current Chrome docs, since that is a fast-moving spec.

Registering a tool and want the config side sorted too?

Scaffold an MCP server

About the author

Jim Liu

Jim Liu runs the OpenAI Tools Hub review portfolio and reads browser API specs and Chrome release docs directly rather than relying on secondhand summaries. The checks above are read from the Chrome WebMCP docs and the W3C incubation README, not from a blog post about them. More about how this site tests things.