Chrome 146 WebMCP Early Preview: Browser Support and the Current API

February 21, 2026
Understand the historical Chrome 146 preview, check the current document.modelContext API, and verify discovery and invocation in your browser.
Chrome 146 WebMCP Early Preview: Browser Support and the Current API
chrome 146
webmcp
google
browser
devtrial

Updated October 11, 2026. This page keeps its original Chrome 146 URL so existing links continue to work. The initial preview is historical context; the examples below describe the current draft, not a promise that every Chrome 146 or newer installation supports it.

What the early preview established

Google's February 10 announcement introduced declarative and imperative approaches and an early preview program. Availability for prototyping does not mean universal browser support or an automatically available agent.

Since the original article, the interface has changed. Read the current editor's draft and test the exact browser configuration you use. This site's October 10 acceptance record reports native discovery in Chrome 154 with WebMCP enabled; that is a tested configuration, not a release-wide compatibility statement.

Check the browser before copying code

In a secure context, inspect:

console.log({
  secureContext: window.isSecureContext,
  modelContextAvailable: Boolean(document.modelContext)
});

If the interface is absent, preserve the normal website workflow and check the preview instructions for that build. Enabling an experimental feature is a development configuration, not a prerequisite you can assume all visitors meet. HTTPS and local development secure contexts should be tested separately.

Current and historical API names

Earlier examples may useCurrent draft uses
navigator.modelContextdocument.modelContext
handler or callbackexecute
listTools()getTools()
unregisterTool()A registration AbortSignal for cleanup

This table is a migration aid, not a claim that every past build exposed all of those methods. Check capability before calling a method; implementations may lag the draft.

Register a small tool first

Use a read-only example with no external service, then verify that the normal page still works when the API is unavailable.

async function registerPageTools() {
  const context = document.modelContext;
  if (!context) return; // Keep the normal page available.
  const registration = new AbortController();
  await context.registerTool({
    name: "getPageHeading",
    description: "Read the first h1 or h2 heading on this page. No data is changed.",
    inputSchema: {
      type: "object",
      properties: {
        level: { type: "string", enum: ["h1", "h2"], description: "Heading level to read" }
      },
      additionalProperties: false
    },
    annotations: { readOnlyHint: true, untrustedContentHint: false, consequentialHint: false },
    execute: async ({ level = "h1" }) => {
      if (!["h1", "h2"].includes(level)) throw new Error("Invalid heading level");
      return { heading: document.querySelector(level)?.textContent?.trim() || "" };
    }
  }, { signal: registration.signal });
  window.addEventListener("pagehide", () => registration.abort(), { once: true });
}
void registerPageTools();

For real applications, validate values inside the callback and keep server permissions intact. Abort registrations when the owning view is removed. The annotation guide explains how to describe effects accurately.

Separate discovery from execution

Where supported by the tested implementation, discover registered tools with:

async function findHeadingTool() {
  const context = document.modelContext;
  if (!context || typeof context.getTools !== "function") return null;
  return (await context.getTools()).find(tool => tool.name === "getPageHeading") || null;
}
void findHeadingTool().then(console.log);

Finding a tool confirms discovery in that environment. Test invocation separately with a compatible client, using the same registered name and valid inputs. Record the browser build, feature configuration and result. An agent integration is distinct from the page API: having one does not automatically supply the other.

What the website scanner can tell you

WebMCP Verify observes registration and related page signals without calling your tools. A simulated capture is labeled separately from a native capture. It is not proof that the scanned browser supports native WebMCP, or that an agent can finish the workflow.

Use the score guide to interpret skipped checks and rule versions. Avoid comparing historical scores with current scores without considering the ruleset.

Practical browser test checklist

  1. Confirm a secure context and actual API availability.
  2. Register one harmless tool and confirm its discovered definition.
  3. Invoke it in a supported client; inspect the returned value and errors.
  4. Check invalid inputs and lifecycle cleanup.
  5. Disable the feature and verify that human interactions still work.

For the form alternative, see what WebMCP is and how to implement it. There is no announced universal support date in these sources, and no reason to turn a preview article into a promise about search rankings.

Chrome 146 WebMCP Early Preview: Browser Support and the Current API | WebMCP Verify