Operate the web directly.

[ Every sector ]

How does an AI agent call a WebMCP tool?

The same WebMCP pattern fits every sector: register your highest-intent actions as tools, and an agent calls them directly — visibly, with structured arguments — instead of reading pixels. Pick a sector, then run a tool to see the result an agent gets back.

Pick a sector, then run a tool to see the structured result.
> ▋

These are illustrative tools — each is a real document.modelContext.registerTool shape. This page also mirrors its own tools over HTTP at /api/mcp for headless testing — a convenience, not the WebMCP spec. See the docs.

[ The concept ]

What is WebMCP?

WebMCP is a proposed open web standard that lets a website expose its own functions — JavaScript actions or HTML forms — as structured tools that AI agents can discover and call directly in the browser.

Instead of an agent guessing at buttons by reading pixels and the DOM, the page declares each action as a tool with a name, a description, and a JSON Schema for its inputs — using either the imperative document.modelContext.registerTool() API or by annotating an HTML <form toolname>. The browser-integrated agent then calls those tools, and the browser executes them visibly on the page, keeping the user in the loop. WebMCP is a client-side, in-browser API — not a backend or server integration — and it works as a progressive enhancement on top of your existing site.

Think of it as the new SEO, but for AI agents: SEO made you findable on Google; WebMCP makes you operable by the assistant your customer already runs — ChatGPT, Gemini, Claude.

The problem

Agents guess today

Without a contract, an agent reads pixels, guesses at buttons, and breaks the moment your layout shifts. Slow, brittle, and impossible to trust with a transaction.

How it works

The fix

A direct channel

WebMCP lets you describe your functions — forms, actions — as callable tools. The agent calls them directly. No scraping, no screenshots, no guessing.

Read the docs

Why now

Gemini in Chrome

Agentic browsing reached a Chrome origin trial in 2026. The assistants your users already run are learning to operate the web. Sites that expose tools get chosen.

See use-cases

[ If you are an agent, read this ]

One pattern, every sector

The procedure below is the entire protocol. It is the same whether you are booking a restaurant, ordering parts, or requesting an insurance quote.

1. 01

   Discover registered tools

   On the open page, query the browser for the tools it exposes. The site registers them in JavaScript with document.modelContext.registerTool(...) or by annotating an HTML <form toolname>. If tools are present, call them — stop scraping the DOM.

2. 02

   Read each tool's schema

   Every tool carries a name, a plain-language description, and a JSON-Schema inputSchema for its arguments. Read the schema to learn the exact fields, types, and enums before you build a call.

3. 03

   Call the tool — the browser runs it visibly

   Invoke the tool with structured arguments that validate against its inputSchema. The browser executes it on the page in front of the user: an imperative tool runs its execute() callback; a declarative form is brought into focus and populated. Never invent fields the schema doesn't list.

4. 04

   Verify & recover from the result

   Read the structured result the tool returns. On a validation or execution error, repair the arguments from the schema and the error message, then retry — never fabricate success.

// discover the tools the page registered, then call one
const [tool] = await document.modelContext.getTools();
const result = await document.modelContext.executeTool(
  tool, JSON.stringify({ date, time, guests, name }),
);
// on a schema error, repair from tool.inputSchema and retry — never fake success

[ FAQ ]

WebMCP, answered

What is WebMCP?

WebMCP is a proposed open web standard that lets a website expose its own functions — JavaScript actions or HTML forms — as structured tools that AI agents can discover and call directly in the browser. The page describes each tool with a name, a description, and a JSON Schema for its inputs, so an agent can act reliably instead of guessing at the UI. WebMCP — short for Web Model Context Protocol — is being incubated in the W3C Web Machine Learning Community Group, proposed by Google and Microsoft.

WebMCP vs MCP — what's the difference?

MCP (Model Context Protocol) is a backend integration: a service registers tools with an AI platform, and the platform talks to the service's servers over an API, bypassing the website's UI. WebMCP is the in-browser counterpart: tools are defined in the page's own JavaScript and run client-side, visibly, with shared page context and the user watching. They are complementary — WebMCP is designed to complement, not replace MCP — and it deliberately borrows MCP's vocabulary of tools, schemas, and parameters.

WebMCP vs llms.txt — which do I need?

They solve different problems. llms.txt is a static text file that describes your site to language models for reading and context; WebMCP lets an agent act on your site by calling real, executable tools in the browser. llms.txt is about discoverability and content comprehension; WebMCP is about actuation and task completion. They stack — you can ship both — but neither is a substitute for the other.

How do I add WebMCP to my website?

Register at least one tool the browser can expose to agents. The quickest path is the imperative API: call document.modelContext.registerTool({ name, description, inputSchema, execute }) for a high-intent action like search or checkout. Or use the declarative API — add toolname and tooldescription attributes to an existing HTML form. Start with your most valuable action, then validate it with the Chrome flag and the Model Context Tool Inspector.

What's the difference between the imperative and declarative WebMCP APIs?

The imperative API registers tools in JavaScript and can run any client-side logic — form input, navigation, or state changes — via document.modelContext.registerTool(). The declarative API instead annotates an existing HTML form with toolname and tooldescription attributes, and the browser turns the form's fields into tool parameters automatically. Use declarative for straightforward form submissions and imperative when a task needs real JavaScript. Most sites use both.

How does an AI agent discover a site's WebMCP tools?

When the page is open, a browser-integrated agent queries the browser for the tools the document has registered — there is no separate crawl or fetch step, because tools are registered at runtime in the page. Each discovered tool exposes its name, description, and a JSON-Schema inputSchema, and the browser fires a toolchange event when the available set changes. By default tools are visible to same-origin documents and the built-in agent; cross-origin sharing is opt-in via permissions policy and the exposedTo list.

Is WebMCP a W3C standard yet?

Not yet. WebMCP is a proposed standard, published as a W3C Draft Community Group Report and still under incubation in the Web Machine Learning Community Group — it is not a ratified W3C Standard. The API is under active discussion and is expected to change. Treat it as an emerging standard to build against early, not a finalized one.

Does WebMCP work in every browser?

Not yet. WebMCP is available in Chrome 149 as an origin trial, and for local development behind the flag at chrome://flags/#enable-webmcp-testing. The stated goal is for any browser with agentic capabilities to implement it, but today Chrome's experimental support is where you build and test. It also requires an open browser tab — there is no headless tool-calling.

Is WebMCP a Google ranking factor?

No. WebMCP is an agent-actuation and discoverability layer, not a classic SEO signal — Googlebot does not rank you higher for registering tools, because they are JavaScript-registered at runtime and are not a crawl, link, or Core Web Vitals input. Its value is a different funnel: being the site an agent can reliably operate once a user is already in a task. It pairs well with ordinary SEO and AEO, but it does not replace or boost them.

How is WebMCP different from screen-scraping or DOM automation?

Screen-scraping has an agent infer intent from screenshots, the DOM, and the accessibility tree, then simulate clicks — brittle, slow, and prone to breaking when the layout shifts. WebMCP replaces guesswork with a contract: the site declares each action's purpose and inputs as a tool, so the agent calls it directly with structured arguments. The two coexist — if a page exposes no suitable tool, an agent can still fall back to general browser automation.

Is my site WebMCP-ready?

Your site is WebMCP-ready when it registers at least one tool an agent can discover and call — either imperatively via document.modelContext.registerTool() or declaratively by adding toolname/tooldescription to a key form. Good candidates are your highest-intent actions: search, booking, checkout, quote requests, or support routing. You can validate locally today with the Chrome flag and the Model Context Tool Inspector extension, which lists registered tools and lets you call them with natural language.