What Is WebMCP? How the Browser-Side Agent Tool Proposal Works

WebMCP is an experimental browser-side proposal that lets a web application expose structured tools to an AI agent. In the current Community Group draft, a page registers tools through document.modelContext. Each tool describes an action, its inputs, and the function that executes inside the page.

That definition needs two boundaries. WebMCP is not a W3C Standard or a direct browser implementation of the Model Context Protocol. It is a distinct web API inspired by the same structured-tool idea. Its API and browser support are still changing.

The problem WebMCP addresses

Agents can already interact with websites through screenshots, accessibility trees, DOM inspection, or separate backend APIs. Each route has tradeoffs:

visual and DOM automation can be brittle when the interface changes;
a backend API may not contain the current state visible in an authenticated browser session;
a separate agent integration creates another surface to secure and maintain.

WebMCP proposes a page-owned contract. The site declares the actions an agent may call, the data each action accepts, and the code that runs. The agent does not have to infer every capability from the rendered interface.

How the current API works

The current draft places the imperative API on document.modelContext:

if ("modelContext" in document) {
  document.modelContext.registerTool({
    name: "search_records",
    title: "Search records",
    description: "Search records visible to the signed-in user.",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string" }
      },
      required: ["query"],
      additionalProperties: false
    },
    annotations: {
      readOnlyHint: true
    },
    async execute({ query }) {
      return searchRecords(query);
    }
  });
}

A useful tool contract includes:

a stable name and human-readable title;
a description that explains when the action applies;
a constrained input schema;
annotations that accurately describe side effects and untrusted output;
an execution function that uses the application’s existing permission checks.

The current specification’s declarative section is unfinished. Older examples using form attributes should not be treated as a stable production API.

WebMCP and MCP solve different integration problems

Anthropic introduced MCP in November 2024 for connections between agents and external tools or data sources. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, while saying the project’s maintainer-led governance model remained unchanged.

WebMCP is page-side. MCP commonly connects an agent to a server-side capability. A product may eventually use either or both, but the shared letters do not make them interchangeable.

Question	MCP	WebMCP
Where is the capability exposed?	An MCP server	A connected browser document
What context is naturally available?	Server and integration context	Current page and signed-in session context
Does the user need the page open?	Not necessarily	Yes
Current maturity	Established open protocol	Experimental Community Group proposal

For the full decision framework, see WebMCP vs. MCP.

Status as of July 11, 2026

The Web Machine Learning Community Group published an updated draft on July 8, 2026. Chrome announced an origin trial for Chrome 149 on June 9, 2026. An origin trial is a time-bounded implementation test, not evidence of cross-browser availability or a final standard.

Before implementing WebMCP:

check the current specification rather than copying an older tutorial;
verify the browser and trial requirements;
feature-detect the API;
keep the page usable when the API is absent;
treat every exposed action as a security boundary.

Security and trust boundaries

Structured tools reduce some ambiguity, but they do not make agent action safe by default. Tool descriptions and results can contain untrusted content. A page must still enforce authentication, authorization, validation, rate limits, and confirmation for consequential actions.

The host also needs a clear answer to a basic question: how will it know the requested action produced the expected result? A successful function return is not always the same as a verified interface state.

How this relates to kn8

kn8 is not built on WebMCP. It uses its own connected-interface runtime. kn8 uses current state and visible targets supplied by a connected host, guides the shopper in the interface already on screen, performs only supported actions, and verifies what changed. WebMCP is useful adjacent education about browser-side tool contracts, not kn8’s product foundation. See kn8 work through a connected storefront task →

Key takeaways

WebMCP is an experimental browser-side proposal, not a W3C Standard.
The current imperative API is exposed through document.modelContext.
It is distinct from MCP, even though both use structured tool concepts.
Browser support, trial status, and API details must be checked immediately before implementation.
Tool exposure does not replace permission checks, failure handling, or result verification.