WebMCP: the standard your site needs (that you've never heard of)

WebMCP is a Chrome-proposed web standard, currently in origin trial as of Chrome 149, that lets a website declare structured tools (like searchProducts or bookAppointment) that AI agents can discover and call directly through a new navigator.modelContext browser API. An origin trial is Chrome's early-access program for testing a feature with real users before it's final, and navigator.modelContext is a new browser hook your site's code can plug into. If your site doesn't declare tools, agents fall back to scraping your UI and guessing. Your competitors who declare them get the booking.

I've been calling this the missing layer of the web for about six months. Schema.org tells an AI what your business is. WebMCP tells an AI what your business does. Those are two completely different optimization problems, and almost no one is talking about the second one.

Per Chrome's developer documentation, WebMCP is "a proposed web standard letting websites explicitly declare structured tools that AI agents can discover and invoke." The spec lives at github.com/webmachinelearning/webmcp. The Chrome status tracker is at chromestatus.com/feature/5117755740913664. This is real, it is shipping, and it is not optional for any business that takes bookings, sells products, or has a search bar.

> WebMCP exposes a single browser API: navigator.modelContext. Sites register named tools with JSON Schema inputs and outputs. Agents call those tools instead of scraping the page. Chrome 149 origin trial. Available now under chrome://flags/#enable-webmcp-testing.

What WebMCP actually does

The core idea is small. A website calls navigator.modelContext.registerTool(...) and hands the browser a tool definition: a name, a JSON Schema describing inputs, a JSON Schema describing outputs, and a JavaScript handler that does the work. The browser exposes those tools to any agent that visits the page, whether that's Chrome with Gemini Spark, Claude with the browser MCP plugin, or anything else that speaks the protocol.

Here's a minimal example, the kind of thing you'd put on a boutique retail site:

navigator.modelContext.registerTool({
  name: "searchProducts",
  description: "Search the store catalog by query, price range, and category.",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string" },
      maxPrice: { type: "number" },
      category: { type: "string" }
    },
    required: ["query"]
  },
  handler: async ({ query, maxPrice, category }) => {
    return await storeAPI.search({ query, maxPrice, category });
  }
});

When an agent lands on that page, sent there by AI Mode, by a Spark agent acting on a user's behalf, or by Antigravity orchestrating a multi-step task, it discovers searchProducts and calls it directly. There's no DOM parsing (no reading the raw HTML structure of the page) and no "click the third button, then wait for the modal." Just a typed API call with predictable outputs.

That is the entire pitch, and it changes how websites talk to machines.

Why this matters more than meta tags

For twenty years, the optimization story has been: write good content, mark it up with semantic HTML, sprinkle in structured data, and Googlebot will index you. The contract was make my content readable, and agents rewrite it into make my actions invokable.

A 2026 agent doing a task (book a haircut, order specialty flour, find a cabinet maker in Calgary) does not read your hero headline or skim your About page, it looks for tools. If you have them, it uses them. If you don't, it tries to scrape your UI, fails roughly half the time, and the user ends up on a competitor's site that did the work.

We're seeing this in early client audits. Sites with clean WebMCP declarations get reliable agent task completion. Sites without them get inconsistent results that depend on whether the model's vision-based UI scraping happened to land on a recognizable button that day. The first group converts agent traffic. The second group leaks it.

This is why we're already adding WebMCP audits to every transactional site we ship at Space & Story, and why our boutique retail playbook and restaurant playbook now include tool declarations as a launch requirement, not a nice-to-have.

What's eligible to declare

Anything a user can do on your site can be declared as a tool. The practical list, ordered by impact:

• Search and filter: searchProducts, filterListings, findStylist. These are the easiest wins because agents constantly need them.
• Bookings and reservations: bookTable, reserveAppointment, requestQuote. The single highest-value declaration for any service business. An agent that can hit bookTable directly converts 5 to 10x better than one that has to navigate a JavaScript-heavy reservation widget.
• Cart and purchase: addToCart, checkout, applyDiscountCode. These overlap with the Universal Commerce Protocol; WebMCP is the general-purpose layer and UCP is the commerce-specialized one, and the two can coexist.
• Comparison and configuration: compareProducts, configureBuild, requestSamples. Useful for any site where the user is exploring.
• Account actions: updatePreferences, subscribeToList. Lower-priority but increasingly relevant for personalized agent flows.

A useful rule: if a user can do it through your UI, declare it as a tool. If they can't, don't.

How it relates to schema.org

This is the question that comes up in every kickoff call, so I'll be blunt. Schema.org and WebMCP are complementary. Schema.org covers the facts about your business, and WebMCP covers the actions a user can take.

A restaurant's schema.org markup says: we are a restaurant, our hours are 5 to 10 PM, our menu is at this URL, our address is here. A restaurant's WebMCP declarations say: you can search the menu, you can check table availability, you can book a reservation, you can pre-order takeout.

An agent uses both, schema to understand the restaurant and WebMCP to act on it. Ship one without the other and you've solved half the problem.

Browser and origin-trial status

Per Chrome's documentation, WebMCP is "available now under flag" for local development at chrome://flags/#enable-webmcp-testing. The Chrome 149 origin trial is the path to real-user testing. The Model Context Tool Inspector, a Chrome extension that lets you see exactly what tools an agent discovers when it lands on your site, is on the Chrome Web Store and is the single most useful debugging tool I've used this year.

Stable release isn't yet committed, and that's a feature rather than a bug. The right time to ship WebMCP is during the origin trial, while agent traffic is still a small slice of your total visits. By the time it's stable, the sites that already have it are the destinations agents prefer.

What we recommend to clients today

Three things, in priority order.

First, declare the tool that maps to your single most-valuable user action: bookTable for a restaurant, bookAppointment for a clinic, searchProducts or addToCart for a boutique. One tool, well-typed, with a clean JSON Schema, gets you 80% of the agent-traffic benefit.

Second, install the Model Context Tool Inspector Chrome extension and verify your tool is discoverable. The default model in the inspector is Gemini 3 Flash Preview, which matches what most agents will actually use. If the inspector can't find your tool, no agent will.

Third, treat tool quality as an SEO discipline, because the tool name, the schema, and the output format all matter. Two clinics in the same city, both with WebMCP, will get differentiated agent traffic based on which clinic's tools are easier to call. This is the new positioning surface, and it is being graded right now by every agent that visits your site.

What you don't need to do

You don't need to add WebMCP to every page. You don't need a tool for every nav link, you don't need to wait for stable release before shipping, and you don't need to rebuild your CMS (your content management system, the platform your site runs on, like WordPress or Shopify). The API is designed to be additive: drop a few registerTool calls into your existing JavaScript, ship, and you're done.

You also don't need to wait for a global directory of WebMCP-enabled sites, because there isn't one. Per Chrome's own documentation, "clients and browsers must visit a site directly to know if it has callable tools." That means traditional SEO, the work that gets you into AI Mode's source set in the first place, still matters as the entry point. WebMCP is what happens after the agent arrives.

Sources

• WebMCP overview, Chrome developer documentation, Google Chrome
• WebMCP best practices, Google Chrome
• WebMCP Imperative API, Google Chrome
• WebMCP Declarative API, Google Chrome
• WebMCP spec / explainer, W3C Web Machine Learning
• Chrome Status: WebMCP, Google Chrome
• I/O 2026 keynote: the agentic Gemini era, Sundar Pichai