What Is WebMCP? How to Make Your Website Usable by AI Agents

Quick Answer

WebMCP (Web Model Context Protocol) is an emerging W3C browser standard that lets your website expose tools — structured, callable JavaScript functions — to AI agents. Instead of an agent screenshotting your page and guessing where to click, your site declares “here is what you can do here: search products, check availability, book a slot” with exact parameters. Agents get reliability, you keep control, and the whole thing runs in the user’s browser session with no API keys and no extra server. As of mid-2026 it is live in a Chrome origin trial (Chrome 149–156) via document.modelContext.

---

The Problem WebMCP Solves

AI assistants stopped being chat boxes. ChatGPT, Gemini in Chrome, Copilot in Edge, and Claude can now operate websites for their users: compare products, fill out forms, book appointments, complete checkouts.

Today they do it the hard way. The agent takes a screenshot of the page (or reads the raw DOM), asks a vision model “where is the search box?”, simulates a click, types, screenshots again, and repeats. Every step burns tokens, adds seconds, and can break silently the moment you redesign a button.

It is the same story search engines lived through twenty years ago: crawlers guessing at page meaning until sitemaps and structured data let sites declare it directly. WebMCP is that shift, but for actions instead of content.

---

What WebMCP Actually Is

WebMCP is a browser API — developed openly in the W3C Web Machine Learning group by engineers from Google and Microsoft — that lets a web page register tools an AI agent can call.

A tool is three things:

1. A name and description — plain language the model reads to decide when to use it (“search_products: search the store catalog by keyword, category, and price range”).
2. An input schema — a JSON Schema declaring exactly which parameters the tool accepts, so the agent cannot pass garbage.
3. An execute function — ordinary JavaScript that does the work and returns a result the agent can read.

When a user’s AI assistant lands on your page, the browser hands it your tool list. The agent picks a tool, supplies structured arguments, your JavaScript runs, and the agent gets a structured answer back. No screenshots, no simulated clicks, no guessing.

The critical design choice: tools run in the user’s browser tab, inside the user’s session. If the user is logged in, tools act as that user, with that user’s permissions — nothing more. There is no separate credential for the AI, nothing new to leak.

---

WebMCP vs MCP: Same Idea, Different Home

If you have heard of MCP — Anthropic’s Model Context Protocol, which lets AI models call tools on backend servers — WebMCP will feel familiar. It borrows the concept and moves it client-side.

	MCP	WebMCP
Where tools live	A server you run and host	Your existing web page’s JavaScript
Who connects	AI apps over a network protocol	The browser’s built-in agent, in-page
Auth	API keys, OAuth, server credentials	The user’s existing browser session
Setup cost	Build and operate a server	Add a script to your site
Best for	Backend integrations, developer tools	User-facing tasks on real websites
Status	De facto industry standard	W3C proposal, Chrome origin trial

The two are complementary. A SaaS product might run an MCP server for deep API integrations and register WebMCP tools so browser agents can drive the web app itself.

---

The API: Teaching by Example

Everything hangs off document.modelContext.

Registering your first tool

Say you run a home-services business and want agents to check appointment availability:

await document.modelContext.registerTool({
  name: "check_availability",
  description:
    "Check available appointment slots for a service on a given date. " +
    "Returns up to 5 open time slots.",
  inputSchema: {
    type: "object",
    properties: {
      service: {
        type: "string",
        enum: ["inspection", "repair", "quote"],
        description: "Which service the customer wants",
      },
      date: {
        type: "string",
        description: "Requested date in YYYY-MM-DD format",
      },
    },
    required: ["service", "date"],
  },
  execute: async ({ service, date }) => {
    const res = await fetch(`/api/availability?service=${service}&date=${date}`);
    const slots = await res.json();
    return JSON.stringify(slots);
  },
  annotations: {
    readOnlyHint: true, // reading data, not changing anything
  },
});

Walk through what each part buys you:

• description is prompt engineering. The model chooses tools by reading it, so write it like documentation for a smart intern: what it does, what it returns, when to use it.
• inputSchema is a contract. The enum means the agent physically cannot ask for a service you don’t offer. Every constraint you encode here is a hallucination you prevent.
• execute is just your code. It can call your API, read page state, update the UI — anything the page could already do. Return a string (JSON works well) that the agent reads as the result.
• annotations.readOnlyHint tells the browser this tool is safe to call without side effects. A booking tool would omit it, signaling the agent (and browser UI) that confirmation may be warranted.

A tool that acts

Reading data is half the story. Tools can complete tasks:

await document.modelContext.registerTool({
  name: "book_appointment",
  description:
    "Book a specific appointment slot. Only call after the user has " +
    "confirmed the slot. Returns a booking reference.",
  inputSchema: {
    type: "object",
    properties: {
      slotId: { type: "string", description: "Slot ID from check_availability" },
      name: { type: "string" },
      phone: { type: "string" },
    },
    required: ["slotId", "name", "phone"],
  },
  execute: async ({ slotId, name, phone }) => {
    const res = await fetch("/api/bookings", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ slotId, name, phone }),
    });
    if (!res.ok) return JSON.stringify({ error: "Slot no longer available" });
    const booking = await res.json();
    return JSON.stringify({ confirmed: true, reference: booking.ref });
  },
});

Notice the description says “only call after the user has confirmed.” Instructions to the agent belong in descriptions — they are part of your interface now, the same way button labels are part of your UI.

Registering a full toolset at once

For a set of tools that should live and die together, the spec also offers provideContext, which replaces the page’s whole tool list in one call — useful when tools depend on app state (a checkout tool that only exists when the cart has items):

document.modelContext.provideContext({
  tools: [checkAvailabilityTool, bookAppointmentTool, cancelBookingTool],
});

Re-run it when state changes and the agent’s menu updates with your UI.

The declarative option: annotated forms

You do not have to write JavaScript at all for simple cases. WebMCP’s declarative API lets you annotate a standard HTML form so the browser exposes it as a tool automatically — your existing quote-request form becomes agent-callable with a few attributes. For most marketing sites, this will be the 80% path once the API stabilizes.

---

Browser Support in Mid-2026

Browser	Status
Chrome	Origin trial, Chrome 149–156; local testing via chrome://flags/#enable-webmcp-testing
Edge	Not shipped; expected to follow quickly (Chromium-based, and Microsoft co-authors the spec)
Firefox	Engaged in W3C discussion, no commitment
Safari	Engaged in W3C discussion, no commitment

An origin trial means this is past the toy stage: you register your domain with Chrome’s origin trial program and your WebMCP tools work for real visitors in production, no flags required on their end. It also means the API can still change or be withdrawn — build behind a feature check:

if (document.modelContext?.registerTool) {
  registerOurTools();
}

Your site works exactly as before for every browser without support. WebMCP is purely additive.

---

Why This Matters for Your Business

We have written before about how AI chatbots are replacing the search results page for local and small businesses. AEO and GEO were about being the answer. Agentic browsing is the next step: the assistant does not just recommend a plumber, it books one.

When that becomes normal consumer behavior, the practical question is: whose site does the agent succeed on?

	Site without tools	Site with WebMCP tools
How the agent operates	Screenshots + simulated clicks	Direct, typed function calls
Speed	Seconds per step	Milliseconds per call
Reliability	Breaks on redesigns, popups, A/B tests	Stable contract, independent of layout
Cost to the agent	High (vision models, many tokens)	Low (one tool call)
Your control	None — agent guesses at your UI	Total — you define exactly what is exposed
Analytics	Agent traffic looks like weird bot sessions	Tool calls are cleanly measurable

That last two rows are the underrated part. WebMCP is not just making life easier for agents — it hands you the steering wheel. You decide that agents can search and book but not delete accounts. You can log every tool call and finally see what AI-driven visitors actually do.

---

Security: The Questions Everyone Asks

Can the agent go rogue on my site? It can only call tools you registered, with the arguments your schema allows. Everything else on your site is exactly as reachable (or unreachable) as it was before.

Can it act as someone else? No. Tools run in the current user’s session. An agent booking an appointment does it as the logged-in user, subject to every server-side permission check you already have.

What about malicious content tricking the agent? This is the real frontier — prompt injection. The spec includes an untrustedContentHint annotation so you can flag tools whose output contains user-generated content, and browsers are building human-in-the-loop confirmation for consequential actions. Treat tool results like any untrusted input: your server-side validation still matters, same as it always did.

One rule of thumb: never expose a tool whose damage you would not accept from a confused user clicking around your UI. The agent has no powers a user does not — but it clicks much faster.

---

Should You Implement WebMCP Now?

Honest answer by situation:

• You run a content/marketing site for a small business: No urgency. Keep your structured data and AEO fundamentals sharp — that is what feeds AI answers today. Put WebMCP on the 6–12 month watchlist; the declarative forms API will likely be your entry point.
• You run e-commerce or take bookings online: Worth a prototype this quarter. Register for the origin trial, expose search and availability as read-only tools, and start collecting data on agent traffic before your competitors know it exists.
• You build for the web professionally: Learn it now. The API is small (you have seen most of it in this post), the origin trial is open, and “I have shipped agentic tooling” is about to be a differentiator.

The pattern to remember from every previous platform shift — mobile, HTTPS, Core Web Vitals, structured data: the sites that adopted while it was optional set the baseline everyone else got measured against.

---

Summary

• WebMCP lets your website register tools — typed JavaScript functions — that AI agents call directly, replacing screenshot-and-click guesswork
• The API is document.modelContext.registerTool() (the older navigator.modelContext is deprecated) with a name, description, JSON Schema inputs, and an execute function
• It is MCP’s tool-calling model moved into the browser: no server, no API keys, runs in the user’s own session
• Live now as a Chrome origin trial (Chrome 149–156); Edge expected next, Firefox and Safari engaged but uncommitted
• Structured data makes you visible to AI; WebMCP makes you operable by AI — they are complementary, not competing
• Expose read-only tools first, encode business rules in your schemas, and never register a tool you would not trust a confused user with
• E-commerce and booking-driven sites should prototype now; content sites can watch and wait

---