Every WebMCP Tutorial Shows the Wrong Object. The Spec Says document

WebMCP is the proposal for letting a web page hand its own functionality to an AI agent as callable tools, rather than making the agent guess by reading the DOM. It came out of Google and Microsoft, and the write-ups all show the same snippet:

navigator.modelContext.registerTool(/* … */);

Read the specification and that object does not exist. Tools belong to a Document, so the API is document.modelContext. The move happened during drafting and most of the published material predates it.

Key takeaways#

• The API is document.modelContext. Anything showing navigator is out of date.
• Three methods: registerTool(), getTools(), executeTool().
• Status is a Draft Community Group Report, dated 26 August 2026. That is not a W3C standard.
• It is behind a flag in Chrome. Firefox and Safari are in the conversation without committed timelines.
• This is worth understanding now and not worth shipping to production yet.

What problem is it solving?#

An agent operating a website today does it the way a person would, by reading the rendered page and clicking things. That works until the markup changes, and it is slow, brittle and impossible for the site to reason about.

WebMCP inverts it. The page declares what it can do, and the agent calls those declarations directly:

document.modelContext.registerTool(
  {
    name: 'search-products',
    description: 'Search the catalogue by keyword',
    inputSchema: {
      type: 'object',
      properties: { query: { type: 'string' } },
      required: ['query'],
    },
  },
  {/* options */},
);

The shape will be familiar if you have written server-side MCP tools: a name, a description the model reads to decide when to call it, and a JSON Schema for the input. The difference is where it runs. A server MCP tool is a separate process with its own auth; a WebMCP tool runs in the page, inside the session the user already has.

That last point is the interesting one, and it cuts both ways. The agent inherits the user's existing login rather than needing an API key, because it is acting inside the tab. No credential to provision, no separate permission model to build.

It also means the blast radius is whatever that session can do. A server-side integration is scoped by the token you issued it. An in-page tool is scoped by the cookie the user already has, which on a banking or admin site is considerably more.

The three methods#

registerTool(tool, options) exposes one tool from the current document.

getTools(options) returns the tools currently visible to the caller.

executeTool(tool, inputObject, options) invokes a registered tool on its origin document.

Registration is per-document, which is the reasoning behind moving off navigator. A Navigator is per-window and outlives navigation; tools describe this page, and they should disappear when it does. Putting them on Document makes the lifetime correct by construction.

What "Draft Community Group Report" actually means#

Less than most coverage implies, and it is worth being precise because the terms look similar.

A W3C Community Group is open to anyone. It can publish reports, and those reports are not on the W3C Recommendation track. A Draft Community Group Report is roughly: interested parties, including browser engineers, agree this is worth working on and here is the current shape. It carries no commitment from any browser to ship it, and no guarantee the API will look the same next month.

The Recommendation track — Working Draft, Candidate Recommendation, Recommendation — is a different pipeline with different obligations. WebMCP is not on it yet.

For calibration, plenty of Community Group reports never reach it. Some become Working Group items and ship; others are quietly abandoned when the browsers that were interested move on. Membership in a Community Group is a statement of interest, not of intent to implement, and that distinction is doing most of the work in the sentence "Google and Microsoft are behind it".

The navigator to document change is the practical demonstration. That is a breaking change to the primary entry point, made after the proposal was public and widely written about. Expect more.

Should I add this to my site?#

Not to production. The honest position for most teams is to read the spec, understand the model, and wait.

Three reasons. The API surface has already moved once and is still a draft. It is flag-gated rather than generally available, so nothing you build reaches real users. And there is no agreed answer yet to the question that decides whether any of this is safe: what stops a hostile page registering a tool that misrepresents what it does, and what stops an agent calling a destructive tool because the description said it was harmless.

If you want to experiment, do it behind a feature check and treat it as throwaway:

if (document.modelContext) {
  // draft API — expect this to break
}

What you can do today instead#

The durable version of "make this site legible to machines" is not new, and it is not flag-gated.

Structured data is the mechanism that already works. Schema.org markup describes what a page is and what it offers in a vocabulary that crawlers and, increasingly, agents consume. The schema markup generator produces JSON-LD for the common types, and unlike WebMCP it has years of consumer support behind it.

The adjacent question of which crawlers may read your content at all is worth settling separately, and it is a different mechanism from the one most people reach for — see llms.txt vs robots.txt.

Between those two you have described your content and stated your terms, which is most of the value people are hoping WebMCP will deliver, available now and stable.

The short version#

WebMCP is a real proposal solving a real problem, at an early stage that the coverage is overstating. Use document.modelContext, not navigator. Treat a Draft Community Group Report as a signal of direction rather than a shipping date, keep any experiment behind a feature check, and get your structured data right in the meantime, because that part already works.

Sources: WebMCP specification, W3C Web Machine Learning Community Group