What is WebMCP?

A website can describe what it can do

WebMCP, short for Web Model Context Protocol, is a proposed web standard for exposing structured tools from a web page to AI agents. A tool describes a task, the inputs it accepts, and the page functionality that performs it.

Think of a shopping site. An agent can inspect buttons and fields to work out how to search. With WebMCP, the page can instead offer a named product-search tool with explicit inputs. The site still supplies the business logic and its normal interface remains useful to people.

How WebMCP works

1. The page registers a toolA name, description, input schema, and implementation explain its purpose.
2. An agent discovers itA compatible browser or client exposes the available tools in the current page context.
3. The agent supplies inputsFor a search, that might be a phrase and a maximum price.
4. The website performs the taskIts own code returns a result and can update the interface when appropriate.

The Chrome Labs appointment demo illustrates this with availability lookup, booking, and cancellation. Those are distinct capabilities rather than one vague “do anything” command.

How is this different from MCP?

WebMCP focuses on a running web page and its client-side behaviour. A backend MCP integration exposes server-side tools through a separate connection. These approaches can complement each other, but they are not interchangeable transports.

For example, a page tool can reuse the logic behind a filter panel and keep the user’s visible page in sync. A backend tool may access a service without sharing that live interface context. WebMCP is not an AI model, a hosted chatbot, or automatic support for every agent.

Two ways to expose a tool

1. JavaScript: define the behaviour

The imperative API registers a tool with document.modelContext.registerTool. Here is an original, self-contained sample using the same catalog and filtering rule as the simulation. It returns JSON text and validates inputs in the implementation.

const products = [
  { id: 'p1', name: 'Canvas backpack', price: 45 },
  { id: 'p2', name: 'Travel backpack', price: 79 },
  { id: 'p3', name: 'Cotton tote', price: 18 }
];

function searchProducts({ query, maxPrice }) {
  if (typeof query !== 'string' || !query.trim() ||
      typeof maxPrice !== 'number' || !Number.isFinite(maxPrice) ||
      maxPrice < 0) {
    throw new Error('Provide a search phrase and a non-negative price.');
  }
  const matches = products.filter(product =>
    product.name.toLowerCase().includes(query.trim().toLowerCase()) &&
    product.price <= maxPrice
  );
  return { currency: 'USD', count: matches.length, products: matches };
}

if (document.modelContext?.registerTool) {
  await document.modelContext.registerTool({
    name: 'search_products',
    description: 'Search this sample catalog by name and maximum USD price. Does not buy or reserve products.',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', minLength: 1 },
        maxPrice: { type: 'number', minimum: 0 }
      },
      required: ['query', 'maxPrice'],
      additionalProperties: false
    },
    annotations: { readOnlyHint: true },
    execute: async (input) => JSON.stringify(searchProducts(input))
  });
}
// Use inside a module script on a page with native WebMCP enabled.
// Keep the ordinary search UI calling searchProducts as a fallback.

The schema describes allowed arguments; it does not replace application validation. readOnlyHint describes this sample’s behaviour. The browser API also supports tool discovery and execution; registration alone does not run the function.

2. HTML: annotate an existing form

The declarative API adds toolname and tooldescription to a form. Named fields become parameters, and labels or parameter descriptions help explain them.

<form action="/search" method="get"
  toolname="search_catalog"
  tooldescription="Search the catalog by product name.">
  <label for="query">Product name</label>
  <input id="query" name="query" type="text" required
    toolparamdescription="The product name to search for.">
  <button type="submit">Search</button>
</form>

This example needs your site’s real /search endpoint. It is an alternative form-based search, not a second implementation to paste alongside the JavaScript sample. Its normal form remains usable without WebMCP support; do not assume a form submission is side-effect free.

Browser support is still evolving

As reviewed on October 3, 2026, Chrome’s documentation describes an origin trial starting in Chrome 149 and a local testing flag at chrome://flags/#enable-webmcp-testing. WebMCP is still under development; it is not universally available in browsers or agent clients.

Feature-detect the API, retain a useful ordinary UI, and consult the current documentation before shipping. Availability also depends on the page context and permissions. Cross-origin frames need explicit permission arrangements.

Tools need clear boundaries

Keep reading tasks separate from purchases, bookings, deletions, and other consequential changes. Describe side effects honestly, require appropriate user confirmation, and keep authentication and authorization checks in your application.

Tool metadata is not a security guarantee. Inputs still need validation, and outputs containing user-generated or external text should be treated as untrusted. Structured tools do not remove prompt-injection risks.

What our checker tells you

Workbench reviews one public page’s source and discovers registered tools in a fresh browser session. It shows schemas and coverage limits. It does not execute tools, sign in, or certify that a tool works safely. Results are snapshots.

A website can have useful tools on another page or after interaction. A missing tool in one check does not establish that the entire website lacks WebMCP.