WebMCP and MCP
WebMCP vs MCP: what it is and how to check your site
WebMCP lets a web page offer its own functions to an AI agent that works in the browser. MCP lets an AI assistant call tools on a server. Here are both in plain English, small examples that follow the current drafts, and a free check of the WebMCP hints a website declares.
Quick answer
WebMCP is a proposed web standard. A page tells an AI agent in the browser which “tools” it offers (a name, a description, the inputs it accepts) so the agent can use the page properly instead of guessing where to click. It is still a Draft Community Group Report, with an origin trial in Chrome. MCP (Model Context Protocol) is the established server-side idea: tools that an assistant can call from anywhere, with no browser tab involved.
Our check reads static hints only. It does not test registered tools in a real browser, so a result here is a pointer, not a proof.
- Check a website
- What WebMCP is
- WebMCP vs MCP
- Declarative example
- Imperative example
- What the check sees
- Test in a real browser
- Sources
Check which WebMCP hints a website declares
Use this free WebMCP checker on any public website, yours or someone else’s. It is the WebMCP part of the check that runs with every Check Website on our home page.
The limit: this check sees static hints only. It does not test registered tools in a real browser. Static HTML hints are not proof that a browser agent can find or use a tool.
What WebMCP is
An AI agent that works inside a browser normally has to read the page and guess: which box is the search field, which button sends it? WebMCP removes the guessing. The page publishes tools, small functions with a name, a plain-language description and a list of inputs. The agent calls the tool instead of clicking around, and the person can watch the page react.
A page can offer tools in two ways:
- Imperative (JavaScript). The page calls
document.modelContext.registerTool()with aname, adescription, aninputSchema(a JSON Schema that describes the inputs) and an asyncexecutefunction that does the work. - Declarative (HTML). A normal
<form>becomes a tool when you addtoolnameandtooldescriptionto it andtoolparamdescriptionto its fields. The optionaltoolautosubmitattribute lets the browser submit the form when an agent calls the tool. Withouttoolparamdescription, the browser falls back to the field’s label text.
Status, as we read it on 2026-10-07. The specification is a Draft Community Group Report of the Web Machine Learning Community Group (the version we read is dated 2 October 2026), not a finished standard. Chrome’s documentation says the API is in an origin trial from Chrome 149, and for local tests names the flag chrome://flags/#enable-webmcp-testing. The declarative part is still a to-do section in the draft; its details live in the Declarative API explainer and in Chrome’s documentation. Names and behaviour can change. We do not promise support in every browser, a listing anywhere or a better search ranking.
WebMCP vs MCP
Both give AI agents tools with names, descriptions and inputs. They live in different places. The table follows Chrome’s own comparison.
| Topic | MCP | WebMCP |
|---|---|---|
| Runs where | On a server. Tools are available to agents anywhere, at any time. | In the browser tab, only on your website. |
| Lifetime | A persistent server. | Short-lived: bound to the open tab. |
| Interface | Headless: no web page is involved. | Built into the browser and aware of the page (the DOM, its elements). |
| Best for | Background actions and your core logic. | Letting an agent use a live web page. |
| We check | Announcements only: an MCP Server Card, an AI Catalog and an API catalog. We never call the endpoint. | Static hints only: form attributes and an inline registerTool mention. No script runs. |
Which one do you need? If assistants should call your data or actions from anywhere, that is MCP: see our own remote MCP endpoint as an example. If you want an agent in the browser to use your live page, that is WebMCP. Chrome’s documentation suggests combining them: core logic in MCP, a contextual page UI in WebMCP. Many websites need neither. A page with real text in its HTML is already readable for agents.
Small example: a form as a tool (declarative)
<form toolname="search_products"
tooldescription="Search the product catalogue by keyword."
action="/search" method="get">
<label for="q">Search words</label>
<input id="q" name="q" type="text"
toolparamdescription="Search words, for example red shoes.">
<button type="submit">Search</button>
</form>
toolautosubmit only if a tool call should submit the form without the person pressing the button.Small example: a function as a tool (imperative)
// Inside an async function or a module script.
// Only some browsers have WebMCP today, so detect it first.
if (document.modelContext && typeof document.modelContext.registerTool === 'function') {
await document.modelContext.registerTool({
name: 'search_products',
description: 'Search the product catalogue by keyword. Returns up to 10 products.',
inputSchema: {
type: 'object',
properties: { query: { type: 'string', description: 'Search words, for example red shoes.' } },
required: ['query']
},
execute: async ({ query }) => {
const answer = await fetch('/api/search?q=' + encodeURIComponent(query));
return await answer.text();
}
});
}
name, description, inputSchema and execute are required. Our own site describes how it uses both ways in the WebMCP section of the agents page.What our check sees, and what it cannot
The form above runs the WebMCP part of our agent readability check (check D3). It reads the homepage HTML (the first 1 MiB), within the same ten-second, nine-file budget as every agent check. No script of the website runs and nothing is stored.
It can see
A <form> with toolname and tooldescription, and whether every named field has a toolparamdescription. An inline script that mentions modelContext and registerTool.
Verdicts: found when a form is complete; partly declared when a description is missing or only an inline script hints at a tool; not found when there is no static hint.
It cannot see
Tools that an external script registers, or that appear after the page has run. Whether registration works. Whether an agent would pick a tool. Other pages than the homepage. Whether a browser supports WebMCP at all.
Declared, not verified in a browser. A “not found” says nothing against a site that registers tools from an external script.
In our score, WebMCP is worth 8 of the 100 points (group D, with llms.txt and MCP discovery). The CheckWebsiteNow Agent Readability Score is our own transparent score, not an official standard, and there is no official WebMCP score. Every check counts with its weight, and a part we could not measure never counts as passed. How the score works. A busy or limit message comes from us and says nothing about the website: we allow ten agent checks a minute per client.
How to test WebMCP in a real browser
- Use a browser that has WebMCP switched on. In Chrome that means the origin trial or the local flag named in Chrome’s documentation. Other browsers may not have it yet.
- List what the page registered. The draft describes a
getTools()method ondocument.modelContextfor discovery, and Chrome’s documentation lists it too. Call it from the developer console on your own page. - Run Lighthouse. Lighthouse 13.5 (released 18 September 2026) added WebMCP audits such as
webmcp-registered-toolsandwebmcp-form-coverage. They run in a real browser. Ours does not, so use both when WebMCP matters to you.
Sources
- WebMCP specification draft (Draft Community Group Report, 2 October 2026; read on 2026-10-07).
- WebMCP explainer on GitHub, Web Machine Learning Community Group.
- Chrome documentation: WebMCP, with the Imperative API, the Declarative API and the page WebMCP versus MCP (read on 2026-10-07).
- Lighthouse 13.5.0 release notes (18 September 2026).
- On this site: agents, MCP and the score, the API guide and the OpenAPI description of
POST /api/v1/agent-check.